Lucene 썸네일형 리스트형 Nutch를 한글 검색엔진으로 활용 Lucene으로 검색 사이트를 구축하기엔 시간과 노력이 많이 필요할 것 같아서 이미 어느정도 패키지로 만들어진 Nutch를 활용해서 검색사이트를 만들어보려고 했다. 그러나 내 의도와 반대의 결과가 나왔다. 거의 1주일 동안 Nutch를 살펴본 결과 Nutch로 한글 검색 사이트를 만드는 것보다 차라리 따로 검색 사이트를 만드는 것이 시간과 노력이 덜 든다. 우선적으로 한글 웹페이지 색인하는 것에는 성공했다. 그러나 검색이 문제였다. 검색할때 org.apache.nutch.analysis 패키지의 NutchAnalysis 클래스의 parse()함수에서 너무 복잡하게 처리한다. 그래서 이 부분을 위해서 따로 공부를 더 하거나 내 마음에 맞는 함수를 만들어줘야하는데 이 작업이 생각처럼 쉽지 않다. 따라서 Nu.. 더보기 다중파일 vs 복합파일 K2로 색인을 만들면 6만 5천개 단위로 segment를 만들게 된다. 이 숫자는 정해져 있기 때문에 바꿀수는 없다. Lucene의 경우 사용자가 지정한 수치에 따라서 segment가 만들어진다. K2와 Lucene 모두 데이터가 늘어나면 색인 파일 갯수도 비례해서 늘어나게 된다. 만약 6억건의 데이터라면 어떻게 될까? K2는 1만개의 파일을 열어야지 검색할 수 있다. 파일 오픈하는데 소요되는 비용이 검색비용보다 더 클수도 있다. 이런 문제를 Lucene에서는 복합파일구조로 해결했다. 논리적으로 기존과 같은 구조이지만 모든 파티션 파일을 하나에 넣는 것이다. 이런 방식이 효율적일 것 같다. 기본적으로 복합파일 구조이나 만약 다중파일구조를 쓰고 싶다면 소스코드에 setUseCompoundFile(false.. 더보기 RAMDirectory 얼마나 효과적인가? 10만개의 파일을 Default 셋팅으로 색인하면 10분걸리는데 RAMDirectory를 사용하면 5분 걸린다. 생각보다 빨리 끝나지 않는다. 10분중에서 줄어든 부분은 5분이다. 이 부분은 색인시 merge할때 그리고 색인된 결과를 저장할때 소요되는 시간이다. 그럼 나머지 5분은 원본 파일을 읽어들이고 bigram으로 키워드 분리하고 소팅하는 시간이다. 이렇게 보면 시간이 많이 단축되었다고 볼 수 있다. 더보기 이전 1 다음