달력

102018  이전 다음

  •  
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • 10
  • 11
  • 12
  • 13
  • 14
  • 15
  • 16
  • 17
  • 18
  • 19
  • 20
  • 21
  • 22
  • 23
  • 24
  • 25
  • 26
  • 27
  • 28
  • 29
  • 30
  • 31
  •  
  •  
  •  
저번시간에 DocumentWriter에 이어서 이번에는  SearchWriter, SortWriter, GroupWriter 알아보려 한다.

우선 SearchWriter에 초기화 부분은 아래와 같다.
field(schema.xml)에서 index가 설정되어 있는 갯수 만큼 루프를 돈다.
해당 필드 indexing 할때 사용할 class는
Object t = IRSettings.classLoader.loadObject(handlerName); 에서 가져와 tokenizers에 저장한다.
마지막을 색인하는동안에도 검색은 되어야 하므로 임시파일에 기록한다.(tmpOutput)

인자 설명 : indexFieldNum은 schema.xml에서 index의 번호(sample에서는 title필드가 0),
docNo는 현재 색인하고 있는 문서 번호
field는 색인할 필드의 정보 (sample에서는 title, tag, body가 입력으로 들어온다)



SearchWriter에서 사용되는 Class들의 관계도를 나름 그려보았다.   Tokenizer에서 KoreanTokenizer도 있고 EnglishTokenizer도 있다. 
색인할때 어떻게 색인어를 추출할지는 Tokenizer를 상속 받아서 구현하면 된다는 얘기다.
아래는 KoreaTokenizer의 Sequence Diagram을 그려보았다.




TypeTokenizer에서는 이전 문자와의 관계(영어,숫자,한글 같은...)를 따져서 token을 해주고 KoreanNounExtractor에서 명사 추출을 한다.
그래서 추출된 단어가 색인어로 들어간다(MemoryPosting)  
MemoryPosting을 보면 ......"어? 이거 어디서 봤는데?" 라는 느낌이 온다.
그렇다....DocumentWriter에서 본 구조가 나온다. 
이번에는 gif파일로 그려보았다. 나같이 초급개발자가 소스 볼때 조금이나마 시간 절약을 위해..

int[] bucket, int[] keypos, int[] nextIdx, char[] keyarray가 있습니다.





key값을 hash Function 통해 나온 값이 bucket 배열의 index가 되고, 해당 값에는 keypos의 index를 가지고 있다.
keypos의 index는 차례대로 증가되는데 그 값을 bucket이 가지는 것이다.

그럼 keypos에는 어떤값이 있냐~~ 하면 keyarray에서 사용가능한 마지막 index가 저장되어있다.
처음에는 keyarray에 아무것도 저장이 안되어있으니까, 0을 가리킬것이고, 그곳에 abc를 저장하면
다음 keypos에는 3이 저장된다.

keyarray의 데이타를 얻기위해 자신의 keypos값(여기서는 keypos[0])과 다음 keypos값(여기서는 keypos[1])을 이용해서 keyarray에서 데이타를 가져올수있다.    

keyarray에는 해당 key값을 기록하고 value는 keypos 길이만큼의 value Array가 있어서 keypos의 index와 

동일한 index에 value를 저장합니다.
(말로는 참........힘드네요백문이 불여일견;; )


근데 여기서 nextIdx라는 게 있는데 존재하는 이유는 아래 그림과 같다.  collision~!!!!



keypos크기만큼 할당된 nextIdx가 충돌시 다음 keypos의 Idx를 가리키게 된다.

위 그림을 예로 들어 설명하겠다.
현재 3개 데이타가 들어온 상태에서 4번째 데이타가 들어왔는데, 두번째와 (그냥 눈으로 보기에) 겹친다.
그럼 당연히 해당 keypos에는 값이 있다.
그럼 동일한 데이타가 들어와서 중복된건지, 다른 데이타인데, hash function으로 나온 값이 중복된걸수도있는데,
이 판단은 keyarray에 있는 데이타와 들어온 데이타를 비교함으로 그 여부를 판단한다.

아까 keypos의 index는 차례대로 증가한다고 했는데, 충돌이 나면 nextIdx는 증가되고 있는
keypos의 index가 저장된다. ;;   nextIdx[0] 에  증가되고있는 keypos의 index가 저장되는겁니다~!!!
(이것도 말로하니까 어려운데 그림으로 설명하죠~!!)





그 다음은 SortFieldWriter이다.
schema.xml에서 sort설정을 한 field가 적용되는건데, 숫자는 상관없지만 문자열의 경우는 size까지 정해줘야한다.
다른데서 이 데이타를 어떻게 하는지는 모르겠는데 SortFieldWriter에서는  filed data를 정해진 size만큼 파일에 기록한다.


GroupFieldWriter에서도 hash을 이용한 저장구조를 사용한다. 
조금 다른점은 부분색인일 경우  PrimaryKeyIndexReader을 이용해서 groupNo를 check한다.
그리고 hash 구조가 field별로 따로 저장이 된다는 점이다. :  )

hash를 이용한 구조 :  keypos에서는 실제 데이타가 저장되어있는 position이 저장 되어있고,
keypos의 index와 동일하게 문서번호나 그룹번호가 저장되어 있다고 생각하면 편할것 같다.


어떻게 어떻게 구렁이 담넘어가듯이 하다보니 FullIndex가 끝이 났다.
다음에는 Search를 보려고 한다. 다음주부터는 본격적으로 회사일이  주어진다고 하는데 언제가 될지는......
Search가 끝나면 사전 적용하는 부분을 볼까 생각중이다.

더 많이 노력해서, 더 많은 사람에게 개발 지식을 전파 했으면 좋겠다. 오픈프로젝트 활동이나, 블로그 포스팅이나, 하고싶은건 많다~ ㅋㅋ




Posted by 오산돌구