정확히 내가 huddler.com에 대한 검색을 처리 한 방법입니다. 한 Zend_Search_Lucene 인덱스를 여러 데이터 형식 당 하나씩 사용했습니다. "all"옵션의 경우 모든 인덱스의 모든 것을 포함하는 다른 인덱스가 있었을뿐입니다. 따라서 인덱스에 문서를 추가 할 때 두 번, 적절한 "유형"인덱스에 한 번, "모두" "색인. 젠드 루씬 (Zend Lucene)은 다른 루씬 (Lucene) 구현물에 비해 심각하게 못 미쳤다. 그래서 이것이 내가 찾은 최고의 해결책이었다. Zend의 포트는 lucene 쿼리 구문의 하위 집합 만 지원하며 중간 색인 (10-100 MB), "a *"와 같은 간단한 쿼리 또는 인용 구문이 제대로 수행되지 않는 경우 (if 조금도).
큰 사이트를 우리 플랫폼에 가져 왔을 때 Zend Lucene은 확장되지 않음을 발견했습니다. 우리의 색인은 대략 1.0 GB에 이르렀으며 간단한 쿼리는 15 초가 걸렸습니다. 일부 쿼리에 1 분 이상 소요되었습니다. 인덱스를 처음부터 구축하는 데는 약 20 시간이 걸렸습니다.
나는 Solr로 전환했다. Solr은 색인 생성 중에 50 배, 그리고 많은 쿼리에서 1000 배 빠릅니다 (대부분의 쿼리는 < 5ms로 끝나며 모두 < 100ms로 끝납니다). 훨씬 더 강력합니다. 또한 30 분 만에 100,000 개 이상의 문서 색인을 처음부터 다시 작성할 수있었습니다 (20 시간에서 감소).
이제 모든 것이 "유형"필드가있는 하나의 Solr 색인에 있습니다. 나는 각각의 검색에 대한 인덱스에 대해 각각 다른 "유형 :"필터 쿼리가있는 쿼리와 "모든"옵션의 "유형 :"이없는 쿼리를 여러 번 실행합니다.
인덱스를 100MB 이상으로 늘리려면 분당 검색 요청을 최소한 받거나 고급 검색 기능을 제공하려면 Zend_Search_Lucene을 포기하는 것이 좋습니다.
어떻게이 클래스를로드 할 수 있습니까? – Druckles