在Lucene中增加索引之後應該優化索引嗎？

Question

我們每隔7小時左右對Lucene索引和增量索引每7天進行一次全部重新索引（即從頭開始創建索引）。我們的索引大約有700,000個文檔，全部索引大約需要17個小時（這不是問題）。

當我們做增量索引，在過去的兩個小時之內發生變化，我們只有索引的內容，因此需要少得多的時間 - 半小時左右。但是，我們已經注意到這段時間（大概10分鐘）花費了很多時間來運行IndexWriter.optimize（）方法。

的LuceneFAQ提到：

的的IndexWriter類支持壓實索引數據庫和加快查詢的優化（）方法。執行文檔集的完整索引或索引的增量更新後，您可能想要使用此方法。如果您的增量更新頻繁添加文檔，您只需稍後執行一次優化，以避免優化的額外開銷。

...但這似乎沒有給出「頻繁」含義的定義。優化是CPU密集型和非常IO密集型的，所以我們寧願不這樣做，如果我們能夠擺脫它的話。在未優化的索引上運行查詢的命中率有多高（特別是在完全重新索引之後，與20個增量索引（例如50,000個文檔發生更改）後的查詢性能相比）？我們應該在每個增量指數之後進行優化還是性能不理想？

Answer 1

墊，因爲你似乎有一個好主意，你的當前進程需要多長時間，我建議你刪除optimize()和測量的影響。

這些2小時窗口中的許多文檔是否會更改？如果只有一小部分（50,000/700,000大約7％）被逐步重新編制索引，那麼我認爲您從optimize()中獲得的價值並不高。

一些想法：

• 不要做一個增量optimize()可言。我的經驗表明，無論如何你都沒有看到巨大的查詢改進。
• 每天而不是每2小時做一次optimize()。
• 在低產量期間（這是javadoc所說的）做optimize()。

並確保您進行測量。沒有它們，這些變化可能是在黑暗中拍攝的。

Answer 2

的optimize操作讀取和寫入整個索引，這就是爲什麼它是如此大量IO的！

背後的想法優化操作是在Lucene索引重新組合所有的各個環節爲一個單一的段，這樣可以大大降低查詢倍，你沒有打開，每個查詢搜索多個文件。如果您使用的是正常的Lucene索引文件結構（而不​​是組合結構），則每次提交操作都會得到一個新的段;與你的重新索引相同嗎？

我覺得Matt有很大的意見，我會說他的一切第二 - 你所擁有的數據來驅動。我實際上會更進一步，只有在需要時纔會優化a）和b）當您的查詢量較少時。

由於查詢性能與索引中的段數密切相關，因此簡單的ls -1 index/segments_* | count可能是真正需要優化時的有用指標。

另外，跟蹤查詢性能和音量，並開始優化，當你達到不可接受的低性能和可接受的低音量將是一個更好的解決方案。

Answer 3

在this mail，奧的斯Gospodnetic建議針對使用優化，如果您的索引看到不斷更新。它是從2007年開始的，但是呼叫optimize()本身就是一種IO操作。你可以考慮採用更加逐步的方法; a MergeScheduler