Solr 自動預熱和各種快取機制如何運作?

Solr 自動預熱和各種快取機制如何運作?

我正在閱讀有關緩存和變暖的信息,但我留下了很多問題。

谷歌把我帶到這裡: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/ 就快取失效而言,這一切是如何運作的?快取基本上就是搜尋器嗎?

3/ 我讀到自動預熱基本上從舊的索引搜尋器實例中獲取一堆條目並將它們添加到新實例中。有什麼保險可以保證這些複製的條目仍然有效嗎?也就是說:如果快取不再有效,由於某些提交可能包括對某些文件或查詢結果的變更......是否有一種機制可以確保我們避免複製包含基於過時資料的文件/結果的舊條目?

4/ 我看到使用 512 個條目等數字的快取範例。這看起來很低。這裡有哪些考慮因素呢?由於必須建立新的索引搜尋器,快取是否會非常頻繁地重建,因此一直創建大物件是一種浪費,只是為了頻繁地放棄然後重新建構它們?還是其他東西?

5/ 假設您有一個應用程序,該應用程式根據應用程式產生的使用者 ID 建立文件並執行查詢。我有 1 個核心/集合“user_documents”,所有內容都放在那裡,“用戶 id”是一個字段。在這種情況下,似乎 1 個用戶的操作可能會使所有用戶的快取失效。如何避免這種情況呢?

6/ 關於過濾器緩存,我讀到 LRU 快取中最舊的條目會被新的整體取代。由於過濾器會為查詢的每個「fq」快取故事條目,因此是否會發生長查詢被從快取中推出的情況,但只有其中一些 fq 而不是其他查詢?這是壞事嗎?

7/ 對於文檔緩存,我看到以下行:

documentCache 的大小應始終大於 max_results

乘以 max_concurrent_queries,以確保 Solr 在請求期間不需要重新取得文件。

這意味著什麼?我找不到有關 max_results 和 max_concurrent_queries 作為設定名稱的文件。

感謝所有為此付出時間的人。

相關內容