crescent의 색인관리 페이지를 루씬 4.4로 바꾸면서
한구님께서 만드셨던 부분을 거의 다 손을 댔는데.. 그중 각 필드의 term 개수를 추출하는 부분에서 이상한 현상이 보였다.
Long 혹은 Integer 타입의 필드에서 term이 이상하게 추출되는 것이었는데..
현상은 두가지로 나타나고 있었다.
1. 색인된 숫자가 깨져서 보임
2. 색인된 숫자보다 더 많은 term이 색인되어있음
테스트 코드를 만들어서 다시 확인을 해봐도 동일한 현상이었다.
stackoverflow에도 같은 현상으로 질문이 올라온 것도 찾았다.
위 코드는 모두 수정을 한 내용인데..
일단,1번 문제는 색인된 Term을 BytesRef라는 이름의 클래스를 사용해 뽑아내면서 색인된 숫자에 대해서는
NumericUtils.prefixCodedToInt 혹은 ToLong 메서드를 사용해야 정상적인 숫자를 볼 수 있는듯하고... (lucene user group에 질문 올리고 답변 받음.. 근데 왜 이래야하는지는... 아직 잘 모르겠음..;;;)
2번 문제는 루씬에서 숫자형식의 필드를 색인하는 방법에서 발생하는 차이인것으로 보인다.
위 stackoverlfow에도 있는 글에서도..
Within Lucene, each numeric value is indexed as a trie structure, where each term is logically assigned to larger and larger pre-defined brackets (which are simply lower-precision representations of the value). The step size between each successive bracket is called the precisionStep, measured in bits. Smaller precisionStep values result in larger number of brackets, which consumes more disk space in the index but may result in faster range search performance.
위 내용이 핵심인듯하다. 기본적으로 int가 32bit인데반해, 루씬에서의 NumberType Field의 기본적인 precisionStep이 4로 발생하는 문제였던것 같다. 그래서, 위 소스에서 precisionStep을 32로 셋팅을 해서 돌려보면 색인한 value만 딱 나오는 것이 확인된다.
루씬 document에서도 (2.9 기준이긴 하지만..)
range쿼리를 사용하지 않을거라면 precisionStep을 Integer.MAX_VALUE로 설정해도 괜찮다고 되어있다.
If you only need to sort by numeric value, and never run range querying/filtering, you can index using a precisionStep of Integer.MAX_VALUE. This will minimize disk space consumed.
하지만.. 굳이 numbertype field를 쓰면서.. rangeQuery를 안 쓰는 경우가 많지는 않을듯...
암튼.. 이 내용을 바탕으로 다시 수정해봐야겠다.