Lucene KoreanAnalyzer : 사전써치 인터페이스

오늘 고작 사전써치 인터페이스를 만들었다.

1. 각 사전마다 커넥션은 하나 (싱글톤 패턴)
2. 각 품사 사전 싱글톤 객체를 통해서 사전에 접근할 수 있다.(각 사전파일의 메모리 로딩 여부가 저장되어 있다. <- 나중에 구현할 예정)
3. 품사 사전에 대한 쿼리 정보를 잘못 입력했을 경우를 대비한 예외처리 기능들
4. 그리고 테스트 모듈들

별 기능에 대한 구현은 없었지만 나름대로 만든 12개 품사사전에 대한 각각의 클래스를 만들고 기능을 만들었다.
고생을 좀 하긴 했지만 OOP의 장점을 다시 한번 느낄 수 있었다. 그리고 자바는 역시 설계에 중점을 둘 수 밖에 없는 언어라는점 또한 느꼈구.

예상대로 역시나 버클리 DB 자체의 DB파일 내부를 검색하는건 지양해야겠다는 것이다. 별 테스트는 안해봤지만 확실히 느린거 같기는 했다.(캐싱이라든지 옵션을 조절하면 어느정도 되겠지만 일단 테스트 보류)

그래서 각 사전파일의 메모리 로딩 여부를 옵션으로 빼고 자바 기본라이브러리에 있는 해싱을 이용해서 메모리에 몽땅 로딩을 해서 써치하는걸 구현해 봐야 겠다.

ps.아쉬~~~ 도서관에 와서 코딩이라니… ㅡㅡ;
늦었다 집에 가야지. 오늘따라 도서관에 왜이리 사람들이 많은지.. 쩝

0 0 votes
Article Rating
Subscribe
Notify of
guest

5 Comments
Oldest
Newest Most Voted
Inline Feedbacks
View all comments
typos

ㅎㅎ 쉬는날에 고생이군. 오피스텔에 왔었으면 같이 놀았을텐데^^. 아무래도 버클리db를 계속 서치한다는건 무리라 보임. 자바 해싱의 경우라 해도 사전을 읽어서 해싱함수에다 루핑돌면서 쏟아붙는 시간도 걸리질 않을까? 그렇다면 차라리 사전자체를 루씬으로 구현해서 RAMDirectory를 이용해봄은 어떤가 싶은데. 아마도 RAMDirectory로 해결하면 사전자체를 한방에 램으로 올리지 않을까?^^

고감자

루씬은 사전써치로만 쓰기에는 너무 무겁다는 느낌입니다.

김정은

사전을 Trie 로 구성해보는것도 좋을듯
검색엔진 nutch 쪽 소스를 보니 Trie 를 잘 만들어 놓은게 있는듯 합니다.
package org.apache.nutch.util;
를 참조해보세요 ^^ 혹시 도움되실까봐 댓글 달아 드립니다.. 나중에 이부분 저도 분석하고 불로그에 올릴 생각입니다..

고감자

네.. 알겠습니다.

근데 버클리DB가 성능에 이상이 없다는 말씀을 주변에서 하셔서 그냥 당분간은 이 구조로 할거 같습니다.

최종욱

Hash쪽보다는 Tree쪽도 속도 괜찮더군요. 유사단어 찾기도 훨 편하고… 🙂