15 만 뉴스 기사가있는 뉴스 사이트가 있습니다. 약 250 개의 새로운 기사가 매일 5-15 분 간격으로 데이터베이스에 추가됩니다. 나는 Solr이 수백만 개의 레코드에 최적화되어 있고 150K가 문제가되지 않는다는 것을 알고 있습니다. 하지만 캐시가 모든 업데이트와 함께 무효화되기 때문에 빈번한 업데이트가 문제가 될지 걱정됩니다. 내 dev에 서버에서 페이지의 콜드로드 (모든 페이지는 몇 MLT 쿼리를 실행하기 때문에)로드 5-7 초 걸립니다.색인을 지속적으로 업데이트하는 Solo
색인을 두 개로 나눌 경우 도움이 될 것입니다. - 보관 색인과 최신 색인. 아카이브 색인은 매일 한 번 업데이트됩니다.
누구나 지속적으로 업데이트되는 색인을 위해 설치를 최적화하는 방법을 제안 할 수 있습니까?
감사합니다.
내 대답은 다음과 같습니다. 그것이 어떻게 수행되는지 모른다면 아직 최적화를 시도하지 마십시오. 당신이 말했듯이 150K는 그리 많지 않습니다. 테스트를 위해 그 크기의 인덱스를 빨리 만들어야합니다. 그런 다음 다른 동시 스레드에서 두 개의 MLT 쿼리를 실행하여 (사용자를 시뮬레이트하기 위해) 더 많은 문서를 인덱싱하면서 어떻게 동작하는지 확인하십시오.
주목해야 할 설정 중 하나는 자동 커밋입니다. 끊임없이 색인을 생성하기 때문에 각 문서를 커밋 할 수 없습니다 (Solr을 가져옵니다). 이 설정에 사용할 값을 선택하면 시스템 응답 시간을 유지하면서 시스템의 대기 시간 (새 문서가 결과로 반환되는 데 필요한 횟수)을 조정할 수 있습니다.
COMMIT 간격 조정에 대한 아이디어가 마음에 들었습니다. 항상 문서를 계속 추가하고 정기적으로 COMMIT 할 수 있어야합니다. 그런 다음 간격마다 한 번만 캐시를 다시 지불합니다. –
결과 당 MoreLikeThis 쿼리를 실행하는 대신 기본 쿼리에서 mlt = true를 사용하는 것을 고려하십시오. 왕복을 절약 할 수 있으므로 더 빨라질 것입니다.
"몇 개의 MLT 쿼리"를 몇 개 지정할 수 있습니까? 페이지 당 얼마나 많은 총 Solr 쿼리를 실행하고 있습니까? –
어떤 클라이언트 플랫폼을 사용하고 있습니까? –
내 로컬 dev 서버는 Mac입니다. 프로덕션 서버는 CentOS입니다. 섹션 색인 페이지에는 각 아티클에 대해 MLT 쿼리와 함께 20 개의 아티클이 포함되어 있습니다. 기사 페이지에는 두 개의 MLT 쿼리가 포함되어 있습니다. –