合併索引Lucene .NET不會產生與直接寫入索引相同的結果

我一直在嘗試一些方法來對Lucene索引進行異步初始化。合併索引Lucene .NET不會產生與直接寫入索引相同的結果

女巫之一是將我們的數據以較小的批量索引爲單獨的索引，然後將這些數據合併爲一個更大的索引。

問題是，當任務完全完成時，我們的索引似乎沒有得到同樣的結果。

現在很多特定的查詢將產生相同數量的結果，例如， contentType：通知

所有文檔選擇器也會產生相同的結果。（：）

但是，如果我做了通配符搜索，例如'c *'是由碎片索引構建的索引，然後合併得到0結果，但寫在一個大去的結果可以產生幾十萬結果（巫婆是公平的，因爲c *是相當廣泛的搜索）...

是否有任何事情需要在合併索引上完成，或者在處理它們時是否存在一些差異？...我試圖對它們運行Optimize，但沒有運氣。

來源

2015-09-28 Jens

不知道任何細節......我說你正在使用這個螺母:)

過於大錘子，我與一批創建的索引（100的數以百萬計的文檔）和工作增量索引（數百萬文檔每天更新100K +）。兩種方法都只在單個索引目錄上使用單個IndexWriter。

訣竅是適當調整IW MergePolicy和/或通過偶爾更新IndexReader來調整搜索器「等待時間」。這實質上是「緩存」了一段時間的IR，以犧牲稍微過時爲代價來提高搜索速度。根據預期調整期限。

我可以在辦法擴大，如果這仍是一個問題

來源

2016-03-20 17:53:50 AndyPook

我想這一切都取決於文件的複雜性，如果你有幾個字段非常簡單的文件可能會比非常複雜的文檔非常不同。我所知道的是，它需要超過1個小時來索引我們所有的文件。我們意識到這裏存在一個存儲瓶頸，因爲同樣的設置可以在25K IOPS - 2GB/s存儲上7分鐘內完成。因此，它可能無助於在內存中構建索引並將它們合併到磁盤中，但只有通過測試才能知道。如果不起作用，測試性能毫無意義。 – Jens

如果您正在「批量」創建索引而不是連續更新，則可以使用IndexWriter上的SetRAMBufferSizeMB來設置較大的值。這會在沖刷到磁盤之前緩衝內存中的文檔。副作用是分段更大，合併發生得更少。隨着磁盤IO數量急劇減少，我看到了數量級的改進。 – AndyPook

設置RAM緩衝區實際上只有在我們觸及flush時纔有所幫助。事實證明，儘管導致我們大部分問題的是SAN，並且大約需要10分鐘來索引〜25萬個文檔（大約7.5億個字段，估計每個文檔的平均字段數量約爲3000個） ......儘管從理論的角度來看，原始問題仍然令我感興趣，但爲什麼合併方法似乎產生了不同的結果，但是我無法重現這個問題，因爲它沒有更簡單和更原始的實現，所以最初的它必須在我們的包裝中） – Jens

合併索引Lucene .NET不會產生與直接寫入索引相同的結果

回答

相關問題