IndexWriter commit的Lucene .NET頻率

Question

我在Lucene.Net中使用IndexWriter編寫了許多文檔。由於需要添加文檔，所以我想知道在提交之前是否需要添加最佳文檔數量。顯然太多了，如果發生崩潰，你可能會失去內存中的所有內容，太頻繁地在每個文件被添加後都會加速吞吐量。

Answer 1

在達到非常高的數字之前，似乎並不存在性能問題。

Total time to commit [10] messages was [00:00:00.1093779] 
Total time to commit [20] messages was [00:00:00.0156221] 
Total time to commit [40] messages was [00:00:00] 
Total time to commit [80] messages was [00:00:00.0312509] 
Total time to commit [160] messages was [00:00:00.0156231] 
Total time to commit [320] messages was [00:00:00.0156273] 
Total time to commit [640] messages was [00:00:00.0312489] 
Total time to commit [1280] messages was [00:00:00.0312509] 
Total time to commit [2560] messages was [00:00:00.0500343] 

Answer 2

這不是一個好的答案，看似簡單的問題。除了「這取決於」 ......

這取決於很多因素，如：

• 多大每個文檔？如果它們很大（很多領域，大領域），那麼當沖刷發生時，數字將會很小
• 什麼是用例？你批量插入？如果是，那麼它的值越高越好，IO越少，吞吐量越高。你是否需要立即承諾/堅持/堅持文檔。那麼你應該承諾每一次添加/更新。很多的IO，但是如果頻率很低。然後是無限的光譜。

您最好設置「setRAMBufferSizeMB」而不是「setMaxBufferedDocs」。限制使用的內存量使基礎架構需求更具可預測性。默認情況下，lucene按內存大小刷新（默認爲16MB）。

還有另一種方法。將緩衝區大小設置爲相當高的數字。但也有一個定時器定期提交。這可以在緩衝和可能「失去」更新的時段之間達到平衡。

是否存在與文檔關聯的遞增「ID」？如果是這樣，請確保它是一個領域。然後在啓動時，您可以通過使用一個ID降序排序（如「通過ID desc選擇頂級1順序」）執行查詢來查詢最新的文檔，並從那裏重新啓動更新。

如果沒有ID，則添加數字日期字段並將DateTime.UtcNow.Ticks放入其中。這成爲你的「更新遊標」。

要牢記的另一件事是搜索延遲。攝取文檔和搜索文檔之間的時間。您可以遵循NRT模式並幾乎完全保持最新狀態。但是有成本。或者你可以決定一些延遲是可以接受的。在這種情況下，您可以更明智地決定何時刷新讀取器/搜索器。

更多的概念性討論。如果您可以提供關於各種關注點和參數的更多細節，我可以更具體一些。