InstantiatedIndex 잘 알고 사용하자 ㅜㅜ

Lucene 2.4가 나오면서 2.4에서의 변화중에 InstantiatedIndex가 나오면서

기존의 RamDirectory Index보다 성능이 향상되었다고 소개한바 있다....

정말 너무너무 반가운 소식이였다.... 얼마전까지 말이다 ㅜㅜ

이런!!!! 이럴수가.... 잘 알고 사용해야 한다. 정말이다.... ㅜㅜ

예~전 lucene에서 indexing할때 Ramdirecory index와 같이 쓰면 좋다라는

식으로 책이나 블로그에 소개가 됐었다...

예를 들면 File Base Index에 직접 쓰는게 아니라 아무래도 속도가 좋은

RamDirectory에 먼저 indexing후 FileIndex에 쓰는 방식을 쓰면 속도가

향상된다고 했지만 2.? 버전에서 방식이 바뀌어 자동으로 이런식으로 인덱싱을

한다고 해서 굳이 RamDirectory로 한번 indexing하는 방식이 필요 없어졌었다

RamDirectory가 사용성이 모호해져서 그런지 향상된 InstantiatedIndex를 내놓았다..

내가 사용한 결과 InstantiatedIndex는 버그가 있었다.

가장 먼저 찾은 버그는 update버그이다. update를 하면 내부적으로 delete후 insert하는

로직을 가졌지만 InstantiatedIndex는 update가 되지 않았다. 그래서 코드에서 delete후

insert 해줬다. 대충 예상해보자면 Ram방식에서는 commit을 해주지 않고 바로

insert하면 적용이 안되는 것이 당연하다(?)ㅋ  버그 리포트가 있겠지

크게 불편하지 않아서 패스~ ㅋㅋ

검색서벌르 만들면서 정말 하고싶었던 플젝을 진행하게 되었는데 Lucene이 도와주질

않다니 ㅜㅜ 아직 정확한 문제점도 찾지 못해서 이후 찾게되면 다시 포스팅 하겠지만

InstantiatedIndex를 사용하면 writer와 reader를 생성가능한데 total doc count를

알 수 있는데 delete를 하더라도 doc count는 줄어들지 않는다 -_-;;

뭐 그냥 카운트니깐라고 생각하고 가볍게 생각했지만 실제 데이터를 지우지 않는 것이

아닌가 하는 의심을 가지게 한다... 아놔...

메모리설정에 문제를 격고 많은 메모리를 설정했지만 어떠한 문제인지 모르지만

엄청나게 인덱싱과 검색이 느려지는 현상이 발생했다.

InstantiatedIndex는 optimize 메소드도 지원하지 않는것이 수상쩍다 ㅜㅜ

아무튼 다시보고 사용하자 InstantiatedIndex !!!

그나마 위로가 되는건 우리 검색 선생님께서 답을 내 주지 않으실까 한다(부담주는거 아니에요~) ㅋㄷㅋㄷ