앞서 쓴... 색인속도향상에 대한 글에
검색 속도 향상에 대한 글도 링크가 걸려 있길래... 같이..
http://wiki.apache.org/lucene-java/ImproveSearchingSpeed
지금 안 보면.. 또 안 읽어볼거 같아서 -_-;
보면서 느낀게... 몇몇 항목은 빠른 색인 속도를 위한 항목과 상반되는 것들이 있다. 내용에도 그러한 것들은 적당한 수치를 찾아내라고 되어 있다.
필터의 사용과 HitCollector 그리고 필드캐쉬의 사용은 적극 고려해봐야 겠다.
검색 속도 향상에 대한 글도 링크가 걸려 있길래... 같이..
http://wiki.apache.org/lucene-java/ImproveSearchingSpeed
지금 안 보면.. 또 안 읽어볼거 같아서 -_-;
1. 정말 검색 속도 개선이 필요한지 점검해보라.
-> 많은 아이디어들이 간단하게 적용 할 수 있는거지만, 다른 것들은 당신의 프로그램에 복잡함을 증가 시킬 수 있다.
2. 루씬의 최종버젼인지 확인
3. 로컬 파일 시스템을 사용하라.
4. 더 좋은 하드웨어, 특히 더 빠른 IO 시스템
5. 하드웨어에 RAM을 추가하거나, JVM의 heap 메모리를 증가시켜라.
6. IndexSearcher를 싱글턴 패턴으로..
7. 성능측정시에 첫번째 쿼리는 무시하라.
-> 첫번째 쿼리를 실행하기 위해 searcher는 캐쉬 초기화등을 위해 어느정도의 성능을 희생한다. 다르게 얘기하면 만약 같은 쿼리를 계속 날리면, 정확한 측정이 되지 않을 것이다. (OS단의 캐쉬)
8. IndexSearcher를 re-open하는 것은 꼭 필요 할 때만..
-> index가 바뀌었을때 그것을 반영하기 위해서는 반드시 IndexSearcher를 re-open해야 한다. 그러나 이것은 많은 오버해드를 가져온다. (특히 인덱스 파일이 크다면..). sarcher를 warm up 할 수 있는 방안을 찾아보자.
9. 검색을 수행하기전 인덱스를 optimize하라.
-> 최적화되어있는 인덱스는 검색을 위한 세그먼트가 단 1나이고 이것은 많은 세그먼트가 있는 것보다 빠른 속도를 제공한다. 특히 인덱스 파일 크기가 클 경우에.. 만약 당신의 어플리케이션이 업데이트가 자주 일어나지 않는다면 인덱스 파일을 만들고, 최적화하고 검색을 하면된다. 만일 업데이트가 자주 있고, searcher를 자주 리프레쉬 해야 한다면, 최적화는 많은 부하를 가져 올 것이고, 아마도 mergeFactor를 줄이는 것이 나을 것이다.
10. mergeFactor를 줄여라.
-> 작은 mergeFactor는 작은 세그먼트와 빠른 검색을 의미한다. 하지만 이것은 색인스피드의 감소를 가져온다.
11. 필드와 텀 벡터의 사용을 제한하라.
-> stored field와 텀 벡터를 조회하는 것은 많은 비용을 요구한다. 각각의 document를 조회하기 위해서는 , 루씬은 다른 여러 파일들을 탐색해야 한다.
12. hits를 필요이상으로 iterate 하지 말아라.
-> search() 메서드는 100개 이상의 검색 결과가 필요 할 때 재실행이 가능한 Hits 오브젝트를 리턴한다.
HitCollector를 대신 사용하라.
-> 만약 모든 document가 아니라 특정 작은 필드만 필요하다면 FieldCache class를 사용하라.
13. fuzzy 쿼리를 사용 할 때는 최소의 prefix 길이를 사용하라.
14. filter의 사용을 고려하라.
-> 쿼리 조건보다 필터를 사용하는 것이 특정 결과를 가져오는데 훨씬 효율적이다. 이것은 특히 인덱스 파일이 크면 클 수록 그렇다.
필터는 보통 카테고리 조건으로 제한을 걸 때 많이 사용하지만, 많은 곳에서 조건절 대신 사용 하기도 한다. Query의 조건으로 사용 할 때와 Filter를 사용 할 때의 차이점은 Socre를 낼 때 뿐이다.
(쿼리로 제한된 녀석들은 유사점수를 낼 때 포함이 되지만, Filter로 제한 녀석들은 포함이 되지 않는듯..)
-> 많은 아이디어들이 간단하게 적용 할 수 있는거지만, 다른 것들은 당신의 프로그램에 복잡함을 증가 시킬 수 있다.
2. 루씬의 최종버젼인지 확인
3. 로컬 파일 시스템을 사용하라.
4. 더 좋은 하드웨어, 특히 더 빠른 IO 시스템
5. 하드웨어에 RAM을 추가하거나, JVM의 heap 메모리를 증가시켜라.
6. IndexSearcher를 싱글턴 패턴으로..
7. 성능측정시에 첫번째 쿼리는 무시하라.
-> 첫번째 쿼리를 실행하기 위해 searcher는 캐쉬 초기화등을 위해 어느정도의 성능을 희생한다. 다르게 얘기하면 만약 같은 쿼리를 계속 날리면, 정확한 측정이 되지 않을 것이다. (OS단의 캐쉬)
8. IndexSearcher를 re-open하는 것은 꼭 필요 할 때만..
-> index가 바뀌었을때 그것을 반영하기 위해서는 반드시 IndexSearcher를 re-open해야 한다. 그러나 이것은 많은 오버해드를 가져온다. (특히 인덱스 파일이 크다면..). sarcher를 warm up 할 수 있는 방안을 찾아보자.
9. 검색을 수행하기전 인덱스를 optimize하라.
-> 최적화되어있는 인덱스는 검색을 위한 세그먼트가 단 1나이고 이것은 많은 세그먼트가 있는 것보다 빠른 속도를 제공한다. 특히 인덱스 파일 크기가 클 경우에.. 만약 당신의 어플리케이션이 업데이트가 자주 일어나지 않는다면 인덱스 파일을 만들고, 최적화하고 검색을 하면된다. 만일 업데이트가 자주 있고, searcher를 자주 리프레쉬 해야 한다면, 최적화는 많은 부하를 가져 올 것이고, 아마도 mergeFactor를 줄이는 것이 나을 것이다.
10. mergeFactor를 줄여라.
-> 작은 mergeFactor는 작은 세그먼트와 빠른 검색을 의미한다. 하지만 이것은 색인스피드의 감소를 가져온다.
11. 필드와 텀 벡터의 사용을 제한하라.
-> stored field와 텀 벡터를 조회하는 것은 많은 비용을 요구한다. 각각의 document를 조회하기 위해서는 , 루씬은 다른 여러 파일들을 탐색해야 한다.
12. hits를 필요이상으로 iterate 하지 말아라.
-> search() 메서드는 100개 이상의 검색 결과가 필요 할 때 재실행이 가능한 Hits 오브젝트를 리턴한다.
HitCollector를 대신 사용하라.
-> 만약 모든 document가 아니라 특정 작은 필드만 필요하다면 FieldCache class를 사용하라.
13. fuzzy 쿼리를 사용 할 때는 최소의 prefix 길이를 사용하라.
14. filter의 사용을 고려하라.
-> 쿼리 조건보다 필터를 사용하는 것이 특정 결과를 가져오는데 훨씬 효율적이다. 이것은 특히 인덱스 파일이 크면 클 수록 그렇다.
필터는 보통 카테고리 조건으로 제한을 걸 때 많이 사용하지만, 많은 곳에서 조건절 대신 사용 하기도 한다. Query의 조건으로 사용 할 때와 Filter를 사용 할 때의 차이점은 Socre를 낼 때 뿐이다.
(쿼리로 제한된 녀석들은 유사점수를 낼 때 포함이 되지만, Filter로 제한 녀석들은 포함이 되지 않는듯..)
보면서 느낀게... 몇몇 항목은 빠른 색인 속도를 위한 항목과 상반되는 것들이 있다. 내용에도 그러한 것들은 적당한 수치를 찾아내라고 되어 있다.
필터의 사용과 HitCollector 그리고 필드캐쉬의 사용은 적극 고려해봐야 겠다.