過濾按日期範圍在Lucene的

Question

我知道標題可能暗示它是一個重複的，但我一直沒能找到這個問題的答案具體問題：

我有一個基於日期範圍過濾搜索結果。每個文檔的日期都存儲在每個文檔中（但沒有編入索引）。當使用過濾器時，我注意到索引中的所有文檔都調用了過濾器。

這意味着隨着索引增長（當前只有約300,000個文檔），過濾器會變得越來越慢，因爲它必須遍歷每個單獨的文檔。

由於日期未編制索引，我無法使用RangeQuery。

如何將AFTER過濾器僅應用於作爲查詢結果的文檔以使其更有效？

我比較喜歡在交出結果之前這麼做，以免搞亂我的分數和收藏家。

Answer 1

不太清楚這是否會幫助，但我也有類似的問題對你和以下的（+注）想出了：

1. 我覺得你真的不得不指數的日期領域。在查詢/過濾等方面沒有任何意義。
2. 在Lucene.net v2.9中，範圍查詢哪裏有很多條款，似乎比v2.9有非常緩慢
3. 我修正了我的速度通過切換到使用數字字段和數字字段查詢來使用日期字段時出現問題。這實際上給了我相當速度提升了我的Lucene.net v2.4基線。
4. 將查詢包裝在緩存包裝過濾器中意味着您可以掛起爲過濾器設置的文檔位。這也將大大加快後續查詢使用相同的過濾器。
5. 過濾器並不在評分中發揮作用的一組查詢的結果
6. 加入你的緩存過濾到您的查詢的其餘部分（在這裏我想你有你的自定義的分數和收藏家）意味着它應該滿足你的標準的最後一部分

所以，總結一下：將你的日期字段索引爲數字字段;將您的查詢構建爲數字範圍查詢;將它們轉換爲緩存的過濾器包裝並掛上它們。

我想你會看到一些壯觀超過您當前的索引使用率。

祝你好運！

p.s. 我永遠不會再猜測使用Lucene時會快或慢。我一直在兩個方向感到驚訝！

Answer 2

首先，要過濾一個字段，它必須被索引。

其次，使用過濾器被認爲是限制要搜索的文檔集合的最佳方式。其中一個原因是您可以緩存篩選結果以用於其他查詢。過濾器數據結構非常高效：它是一組與過濾器匹配的文檔。

但是，如果你堅持不使用過濾器，我認爲唯一的方法是使用布爾查詢來做過濾。