우리는 86,315,770 개의 문서가있는 solr 인스턴스가 있습니다. 최대 4GB의 메모리를 사용하며 컨텐츠라는 토큰 화 된 필드에서 패 시팅해야합니다. 디스크의 인덱스 크기는 23GB입니다.Solr 측면 검색 성능 권장 사항
토큰 화 된 필드에서 왜면 처리합니까? 왜냐하면 우리는 그 필드에서 가장 많이 사용 된 용어 인 "n"을 쿼리하기를 원하기 때문입니다. 문제는 그러한 쿼리를 수행하는 데 너무 오래 걸리고 있습니다. 이런면을 할 때 시간을 개선 할 방법이 있습니까? 어떤 추천?
미리 감사드립니다.
Solr은 메모리 내 데이터 구조의 패싯을 계산하므로 패싯 계산이 CPU 바인딩 일 가능성이 높습니다. 패싯을 계산하는 코드는 이미 매우 최적화되어 있습니다 (다중 값 필드의 경우 UnInvertedField의 getCounts 메서드).
하나의 아이디어는 계산을 병렬화하는 것입니다. 이 작업을 수행하는 가장 쉬운 방법은 컬렉션을 Do multiple Solr shards on a single machine improve performance?에 설명 된대로 여러 조각으로 분할하는 것입니다.
그렇지 않으면 용어 사전이 충분히 작고 쿼리가 제한된 수의 양식을 사용할 수있는 경우 모든 (용어, 쿼리) 쌍에 대해 개수 행렬을 유지하는 다른 시스템을 설정할 수 있습니다. 예를 들어 용어 검색어 만 허용하는 경우 모든 용어 쌍의 수를 유지해야합니다. 용어와 쿼리의 총 수에 따라 많은 디스크 공간이 필요합니다. 카운트가 정확하지 않은 경우, 일괄 처리에서 이러한 카운트를 계산하는 것이 가장 쉬운 방법 일 수 있습니다. 그렇지 않으면 Solr과 카운트 싱크를 유지하는 것이 다소 힘들 수도 있습니다.
topTerms 기능을 LukeRequestHandler으로 사용할 수 있습니다.
문제는 검색어에 용어 수를 적용해야합니다. topTerms에서 가능합니까? – rreyes1979
Luke 요청의'numTerms' 매개 변수를 위의 설명에서 설명한대로'facet.limit'을 사용하는 것과 비슷하게 원하는 값으로 설정합니다. 그러나 Luke는 색인에서 더 이상 검색 할 수없는 문서 (삭제되었지만 아직 병합되지 않은 문서)에 대해 Luke가 topTerms를 반환하므로 일반 바닐라 패싯보다 색인의 용어에 대해 다른 #을 반환합니다. –
또한 필자는 패 시팅에 대한 루크의 속도를 테스트했는데 그 속도는 변함없이 오래 걸립니다. 즉, Solr 3.6 또는 4.0을 사용하는 경우 해당 버전의 LukeRequestHandler에서 몇 가지 속도가 향상되었습니다. –
'facet.limit'을 (를) 설정 하시겠습니까? 나는'facet.limit'가 설정되지 않았다면 (당신의 경우에,'n '이 무엇이든간에) 그러한 질의가 100,000 개 이상의 레코드를 가진 경우조차도 오랜 시간이 걸리는 것으로 나타났습니다. –