루씬 검색 샘플 사이트를 돌리다.
http://www.blogreader.co.kr/

우여곡절끝에 샘플을 돌리면서 하나씩 짚어가려고 합니다.

검색서버가 있는 IDC와 데이터(DB)가 있는 IDC가 서로 상이하여 DB로 부터 데이터를 내리는데 애를 먹고 있다가 겨우 DB IDC에 있는 서버하나를 마련하여 좀 수월하게 돌리게 되었습니다.

파일이 많다보니 파일내리는것도 며칠동안 고생하다가 이제좀 한숨을 쉽니다.

현재 파일 내리는 모듈과 인덱시 모듈을 따로 하여 내려진 파일을 주기적으로 인덱싱하는 incremental 인덱싱 방법을 이용하여 사용중입니다.
이미지도 없고 랭킹도 없어 볼품없지만 어차피 루씬이 어떻게 돌아가는지 보기 위함이니 너그러이 이해해 주시길...

테스트중 몇가지 고려해야 할점을 발견하였습니다.
- Index의 Optimze로 추정되는 시간에 Searcher를 실행시 가끔 .fnm파일 에러가 난다. writer와 searcher 사이에서 세그멘트의 시차때문이라 생각됨.
- 단일어가 아니라 여러개의 텀을 가지고 검색시 랭킹알고리즘이 오차의 가능성이 많음.
일반적으로 두개의 키워드를 검색시 두개의 키워드를 가진 문서가 하나의 키워드를 가진 문서보다 우선순위가 됨에도 불구하여 결과는 그렇지 못함. 이것은 카운팅을 고려하지 않고 단순히 각 텀의 점수를 합산하는 계산법의 문제로 보임.
- 여전히 논란중인 것이겠지만 짧은 문서가 긴문서보다 점수가 상당히 높은 결과...

머 어쨓거나 시작이 반이라 했으니 천천히 찾아지겠지요...
이제 눈좀 붙이고.. 자고 일어나면 하나의 테스트 결과가 나오겠군요..

Testing...
서버 2cpu 1G메모리 SCSI하드
JVM max512
대상 8.1일 이후의 블로그 수집글....
Incremental Indexing
RAMDirectory + FSDirectory의 혼합
복합파일인덱스

by typos | 2006/08/08 03:15 | 루씬 접목기 | 트랙백 | 덧글(11)
트랙백 주소 : http://lucene.egloos.com/tb/1386956
☞ 내 이글루에 이 글과 관련된 글 쓰기 (트랙백 보내기) [도움말]
Commented by 고감자 at 2006/08/08 10:28
드뎌 돌리셨군요. ^^

몇건정도 인가요? 저에게 살짝~~~ ^^;
Commented by typos at 2006/08/08 11:42
하루 25만여건이니까 25만 * 7일 하면 전체 170여만건 되지 않을까 싶은데. 다른 서버에 일부러 파일을 내리고 그걸 카피해서 쓰고 있는데 오히려 카피시간이 더 걸리니^^ 하여간 오늘중으로 다 돌아갈듯 싶으니.. 인덱스속도보다 내리는 속도가 더 느림..
Commented by Gerald at 2006/08/08 16:56
축하드립니다 ^^ 저는 언제... 요렇게 까지 마무리를 할지 모르겠군요.. 9월이나 10월부터 본격적으로 뛰어 들까 합니다.
Commented by conv2 at 2006/08/08 18:00
벌써 공개하셨군요. 축하드립니다.

fnm 파일 에러에 대해서는 저도 처음 봤습니다. 어떻게 된 일인지 궁금하군요.
생각나는 게 있지만, 일단 Optimize 호출 시점에 대해서는 고려할 필요가 있을 거 같습니다.

한글에 대해 bi-gram 색인하셨더군요. 언제쯤 형태소 분석기와 붙이게 될까요? ^^;
Commented by typos at 2006/08/09 00:56
근데 제일먼저 apache 오타 찾으셨군요.. 꿈보다 해몽인 A Patch Lucene...^^
Commented by Breeze at 2006/08/09 15:16
축하합니다. 멋지군요 ^.^/
Commented by 이종완 at 2006/09/06 15:57
[질문]한글 문제에 대한 질문입니다.

죄송합니다. 질문한가지 하고싶습니다. 현재 linux cent os상에서 lucene을 이용하여, POI와 PDFBOX를 결합하여 검색엔진을 손보고 있습니다. 모든 것이 완료된 상태에서 linux상에서 한글 검색이 되지 않습니다. 윈도우에서는 아무 문제 없으나 linux에서만 문제이군요..

i18n 화일과 result.jsp화일의 queryString = new String(request.getParameter("query").getBytes("ISO-8859-1")..등등.. 정말 별 짓 다 해보았습니다.
혹시 해결책을 아시면.. 답변 좀 부탁드릴게요.. 이제 정말 알고싶습니다.
Commented by typos at 2006/09/06 16:18
전 리눅스를 쓰지 않아서 리눅스의 문제인지는 모르겠고요. queryString을 화면에 뿌려보셔서 깨지는게 아닌지 확인해보시는게 , 만약 그렇다면 tomcat한글설정에 관해 찾아보시면 될거 같고요. 아니라면 색인툴박스(http://www.getopt.org/luke/)로 한글이 제대로 인덱스 되었는지 확인해 보심이..
Commented by 마린보이 at 2006/12/06 15:31
<안녕하세요 질문드립니다>
저는 서버구성을 색인/검색/검색결과표시를 전부다 데몬에서 처리할려고 했거든요. 가령 웹브라우져의 쿼리를 받아서 데몬에서 검색하고 결과 html 화면을 구성해서 보여줄려고 생각했는데 이렇게 하면 UI수정이 상당히 번거로울거 같아요.

www.blogreader.co.kr 의 경우 IIS 에서 검색결과 화면단을 처리하고 실제 (증분)색인/검색은 lucene 데몬에서 rmi 나 분산서버 형식으로 사용하신건가요?

서비스 화면때문에 typos 님 처럼 웹서버와 검색/색인데몬을 함께 사용해야 좋은가요 그렇다면 웹서버에서 소켓으로 데몬에 요청 -> 데몬에서 검색결과를 스트링형태의 구조체로 웹서버 리턴 -> 웹서버에서 구조체 파싱 화면을 구성하는 방식이 되는건가요

아니라면 jsp 컨테이너가 있다면 거기서 화면구성,검색,색인 다 할수도 있겠지만 저는 데몬형식으로 구성하고 싶어서요
Commented by typos at 2006/12/07 01:48
기호에 따라 구성하시면 되겠지만 경험상 같이 다 쑤셔넣는것도 유지보수에 괴로운 일입니다. 현재 구성은 쿼리-웹서버-http-검색웹데몬-rmi multisearcher-Searcher(Searchable) 이렇게 검색이 구성되어 있고요. 인덱싱의 경우는 contents gateway(xml) -tcp/ip- indexer server - indexer 이 구조로 각 서버에서 인덱싱합니다.(각 서버의 Search Server는 Indexer Server를 바라보고 있어야 증분색인이 반영됩니다.) rmi는 rpc로 바꿀까 생각합니다. 소켓이 가장 이상적인 형태이긴 하지만 merge하는 부분이 까다롭고 귀찮아서 소켓은 유보하고. 사실 대용량과 많은 접속자수를 처리 하시려면 검색웹데몬쪽에 cache를 사용하셔야 합니다. 이경우 lucene의 cache를 사용하셔도 되지만 searcher나 reader의 경우 snapshot이 적용되기 대문에 리얼타임 인덱싱시에 검색을 반영하는 제약이 있습니다.(rmi 보다 더 많은 제약조건이 따르죠.)
Commented by typos at 2006/12/07 01:50
참고로 모든 데이터를 주고 받는것은 xml 형식으로 처리합니다.

:         :

:

비공개 덧글

< 이전페이지 다음페이지 >