Solr過濾器如何實際執行？

Question

我對查詢處理的理解是否正確？

1. 得到緩存或第一過濾查詢文檔集將創建實施OpenBitSet或SortedVIntSet的，並將它緩存
2. 獲取文檔集從高速緩存或所有其他過濾器創建自己的執行DocBitSet的，它會與相交原始（這段代碼的效率取決於DocSet的實施第一次執行）
3. 我們使用Lucene過濾器+查詢搜索（effici）使用MainQuery和最終DocSet進行跳躍（在所有交集之後）這ency是依賴於第一文檔集實施）
4. 我們採用後置濾波器（成本> 100 & &緩存==假）作爲一部開拓創新的查詢

這樣的結果表現將依賴於AND第一個篩選器因爲對於小查詢SortedIntSet更有效，對於大BitSet更好。 我正確嗎？

問題第二部分： 文檔集有兩個主要的實現 - HashDocSet和SortedIntDoc，在所有情況下，每個路口實現循環在第一過濾器，並檢查它也是第二文檔集......這意味着我們必須排序按尺寸過濾，最小爲先。 是否可以控制緩存過濾器的順序（成本只適用於非緩存過濾器）？

Answer 1

聽起來不錯。欲瞭解更多信息，請看SolrIndexSearcher#getProcessedFilter。

因此，性能將取決於第一個過濾器，因爲對於小查詢SortedIntSet更有效，而對於大BitSet更好。我對麼？

這是空間效率問題比速度問題更多。甲排序INT []成本4 * nDocs字節，而位組成本maxDoc/8個字節，這是爲什麼Solr的用途來分類的INT []每當文件集合中的數量爲< maxDoc/32

二問題的一部分：文檔集有兩個主要的實現 - HashDocSet和SortedIntDoc

與SortedIntDocSet的問題是，它不支持隨機訪問，並與HashDocSet的問題是，它不能爲了列舉文檔的ID，這對評分很重要。這就是爲什麼Solr幾乎在任何地方使用SortedIntDocSets並在需要隨機訪問時創建一個臨時HashDocSet的原因（例如，查看JoinQParserPlugin或DocSlice＃intersect）。