IndexDeletionPolicy에 대한 내용을 보기전에 IndexCommit에 대한 학습예제를 조금 

작성해보았습니다.

lucene 소스에 있는 IndexCommit 테스트케이스에는 두개의 IndexCommit에 대한 비교만

들어가 있네요.. 실제 commit시에 어떠한 값을 가지고 있는지 확인해보고 싶어서 아래와 같이

출력만하는 학습테스트 클래스를 작성하였습니다.



결과를 보시면..

1. commit이 일어날때마다 generation을 계속 증가합니다.

2. commit이 일어날때마다 segmentcount 역시 증가합니다.

3. segmentcount의 경우 위 예제에서의 결과만으로 보면, 문서를 하나씩 indexWriter에 add 후 commit을 하였기 때문에 문서 하나가 하나의 세그먼트에 들어갔고, 그 결과 "java" term으로 삭제하고 commit을 했을 때 generation을 4로 증가하였지만, segmentcount는 문서 하나가 삭제 되면서 2로 줄어든것이 확인 가능합니다.

만약, document1,2를 한번에 add 후 commit을 하였다면 위 결과는 조금 다를 것입니다. 그 코드는 밑에 다시 붙여넣을게요..

4. segmentFileName역시 segment_N의 형태로 나타납니다.

5. commit후 남아있는 파일 리스트를 fileName으로 받아올 수 있습니다.

6. isDeleted의 값은 이 테스트에서는 어디에 사용되고 무엇을 뜻하는지 잘 알 수 없네요..



위 3번에서 말씀드린 예제를 보시면..



위와 같이 나오네요... "java" term으로 삭제시에 segementCount가 2로 유지되는것을 보실 수 있습니다.


이 내용을 바탕으로 IndexDeletionPolicy 부분을 좀 살펴봐야겠습니다.


Posted by 용식

예전에 루씬으로 색인한 인덱스파일로부터 Term Freq를 뽑는 포스팅을 한적이 있는데요..


http://devyongsik.tistory.com/577

http://devyongsik.tistory.com/578


그 당시에는 인덱스리더로부터 TermVector를 하나 들고와서 TermVector로부터 Terms 객체를 얻어서

getSumTotalTermFreq()를 실행했었고 이 값이 -1이 나왔었습니다. 이건 전체 Term의 Freq의 합이죠..


IndexReader ir = IndexReader.open(dir);

Terms terms1 = ir.getTermVector(0, "f");


System.out.println(terms1.getSumTotalTermFreq());


당시 루씬 메일링 리스트에 질문을 해서 위와 같은 케이스에서의 -1은 정상이라는 답변도 받았었습니다.


이번에 페이스북에서 '김호연'님하고 같이 이야기를 하다가 알게된 사이트에서

http://sujitpal.blogspot.kr/2012/12/analyzing-enron-data-frequency.html


MultiFields로부터 TermFreq를 얻는 방법이 있어서, 이것을 자바로 변환해보았습니다.


결과를 보시면 전체 색인된 document로부터 같은 필드명을 갖는 필드에 대한 모든 Term Freq 정보를 가져올 수 있네요. 위에서 -1이 나오던 getSumTotalTermFreq도 해당 필드에서 추출된 전체 Term의 Freq의 합으로 잘 나옵니다.


위 예에서는 13.. 왠지 전체 필드에 대한 Term을 가지고 위와 비슷한 작업을 할 수 있을것도 같은데요.. 흠..


Posted by 용식