캐시와 워밍업에 관해 읽고 있었는데 많은 질문이 남았습니다.
Google이 나를 여기로 데려왔습니다.https://solr.apache.org/guide/7_3/query-settings-in-solrconfig.html
최신 버전은 여기에 있는 것 같습니다.https://solr.apache.org/guide/solr/latest/configuration-guide/caches-warming.html
이 문서를 읽은 후 일련의 질문이 생겼습니다. 여기에 나열하겠습니다. 주요 질문은 자동 온난화에 관한 것입니다.
1/ 수명이 있는 인스턴스를 가질 수 있고 이러한 인스턴스는 캐시를 가질 수 있는 "인덱스 검색기"에 대한 언급이 있습니다.
새 인스턴스를 구축하고 이전 인스턴스를 무효화하는 프로세스는 새 인스턴스가 생성되는 동안 이전 데이터를 제공하는 이전 인스턴스가 여전히 있을 수 있다는 사실을 "인스턴스"가 참조한다는 의미라는 것을 이해해야 합니까? 그리고 한 코어에 대해 동시에 여러 개의 인덱스 검색기가 있지 않습니까?
2/ 캐시 무효화 측면에서 이 모든 것이 어떻게 작동합니까? 캐시는 기본적으로 검색자이며, 캐시 1개가 무효화되면 검색자는 다른 모든 캐시와 함께 다시 생성되어야 합니까?
3/ 자동 온난화는 기본적으로 이전 Index Searcher 인스턴스에서 여러 항목을 가져와서 새 인스턴스에 추가한다는 내용을 읽었습니다. 이러한 복사된 항목이 여전히 유효하다는 일종의 보험이 있습니까? 즉, 특정 문서 또는 쿼리 결과에 대한 변경 사항이 포함될 수 있는 일부 커밋으로 인해 캐시가 더 이상 유효하지 않은 경우... 오래된 자료를 기반으로 한 문서/결과가 포함된 오래된 항목을 복사하지 않도록 하는 메커니즘이 있습니까? ?
4/ 512개 항목과 같은 숫자를 사용하는 캐시의 예를 봅니다. 이 낮은 것 같습니다. 여기서 고려해야 할 사항은 무엇입니까? 새로운 Index Searcher를 구축해야 하기 때문에 캐시가 매우 자주 재구축되므로 항상 큰 개체를 생성하는 것이 낭비이고 자주 버려지고 다시 구성되는 경우가 있습니까? 또는 다른 것?
5/ 문서를 생성하고 애플리케이션에서 생성된 사용자 ID를 기반으로 쿼리를 수행하는 애플리케이션이 있다고 가정합니다. 그리고 1개의 코어/컬렉션 "user_documents"가 있고 "user id"가 필드인 상태로 모두 거기에 들어갑니다. 이 시나리오에서는 한 명의 사용자가 모든 사용자의 캐시를 무효화할 수 있는 것처럼 보입니다. 그것을 어떻게 피합니까?
6/ 필터 캐시와 관련하여 LRU 캐시의 가장 오래된 항목이 새로운 전체 항목으로 대체된다는 내용을 읽었습니다. 필터는 쿼리의 각 "fq"에 대한 스토리 항목을 캐시하므로 긴 쿼리가 캐시에서 푸시되지만 fq 중 일부만 푸시되고 다른 쿼리는 푸시되지 않는 일이 발생할 수 있습니까? 이게 나쁜 일인가요?
7/ 문서 캐시의 경우 다음 줄이 표시됩니다.
documentCache의 크기는 항상 max_results보다 커야 합니다.
Solr가 요청 중에 문서를 다시 가져올 필요가 없도록 max_concurrent_queries를 곱합니다.
그것이 의미하는 바는 무엇입니까? 설정 이름으로 max_results 및 max_concurrent_queries에 대한 문서를 찾을 수 없습니다.
이에 시간을 할애해주신 모든 분께 감사드립니다.