如何處理非常頻繁地更新Lucene索引

Question

我試圖原型，使用非常不穩定索引的數據源（論壇，社交網絡等）的索引/搜索應用，這裏有一些性能要求，

1. 非常快的週轉時間（我的意思是，任何新的數據（如在論壇上一個新的消息）應該是在搜索結果中可很快（不到一分鐘））

2. 我需要定期丟棄舊文件，以確保搜索結果不會過時。

3. 最後但並非最不重要的一點，搜索應用程序需要有響應。 （100毫秒數量級上的延遲，並至少應支持10 QPS）

所有的我都可以當前/可滿足W 0使用Lucene的要求（這將讓我滿足所有1,2和3），但我期待着未來的其他需求（比如搜索相關性等），Lucene更容易實現。不過，由於Lucene的設計目標遠比我目前正在使用的更復雜，所以我很難滿足我的性能要求。

這裏有一些問題，

a。我讀過IndexWriter類中的optimize（）方法很昂貴，不應該被頻繁更新的應用程序使用，有什麼選擇？

b。爲了進行增量更新，我需要不斷提交新數據，並且不斷刷新索引閱讀器以確保它具有可用的新數據。這些將影響上面的1和3。我應該嘗試重複索引嗎？解決這個問題的一些常見方法是什麼？

c。我知道Lucene提供了一種刪除方法，它可以讓你刪除所有匹配某個查詢的文檔，在我的情況下，我需要刪除所有年齡大於某個特定年齡的文檔，現在有一種方法是爲每個文檔添加一個日期字段文檔並用它來稍後刪除文檔。是否可以對文檔ID進行範圍查詢（我可以創建自己的ID字段，因爲我認爲由lucene創建的字段不斷更改）刪除文檔？比比較表示爲字符串的日期更快嗎？

我知道這些都是非常開放的問題，所以我沒有在尋找詳細的答案，我會盡力將您的所有答案作爲建議，並用它們來通知我的設計。謝謝！如果您需要其他信息，請告訴我。

Answer 1

答：我認爲最新版本的Lucene並沒有真正需要優化方法，並且對於我對C項的建議，它確實不應該被需要。 B：再次，我認爲最新版本的Lucene，搜索者知道何時更新完成，並且可以處理，而不需要做任何特別的事情。 C：我會避免刪除，只是每天創建一個新的索引。如果將文檔的年齡存儲在索引中，則可以使用現有索引創建新索引。在索引編寫過程中，獲取所有年輕文檔，遍歷它們並將它們添加到新索引中。有一個名爲getCurrentIndex的公共實用方法，搜索者使用它來獲取最新的實時索引。爲了以防萬一，保留1或2箇舊索引，你應該很好。

Answer 2

你可能想考慮使用Solr而不是直接使用Lucene。 Solr處理您提到的所有要求（近實時更新，刪除文檔，性能/分片，範圍查詢），並且它會比您自己的手動代碼更好地完成任務。您無需處理IndexReader級別的問題，即在更新後何時刷新IndexReader。

就範圍查詢而言，Solr具有TrieField功能，這使得數值範圍查詢超快。請參閱http://www.lucidimagination.com/blog/2009/05/13/exploring-lucene-and-solrs-trierange-capabilities/

Answer 3

Lucene現在支持Near Real Time Search。從本質上講，每次你進行搜索時，你都會從IndexWriter獲得一個Reader。內存更改不會到達磁盤，直到達到RAM緩衝區大小，或者在寫入程序上調用明確的commit。由於跳過commit可避免磁盤IO，即使使用新數據，搜索也會快速返回。

Lucene的NRT麻煩之一是索引對數合併算法。將10個文檔添加到細分後觸發合併。接下來，將這10個段合併爲一個包含100個文檔的段，等等。現在，如果您有999,999個文檔，並且觸發了合併，則需要一段時間才能返回，從而打破您的「實時」承諾。

LinkedIn已發佈Zoie，這是一個解決此問題的Lucene之上的庫。這是現場直播，每天處理數百萬次更新和搜索。

大多數情況下，Lucene會支持您的所有需求，因爲您丟棄舊的更新並且移動窗口的大小基本不變。如果沒有，你可能不得不嘗試在戰場上證明的Zoie。

Answer 4

您可以在短時間內緩存索引搜索器並重新打開它。我們使用這個目的的asp.net WebCache，它有CacheItemUpdateCallback，在chached項目過期之前被調用。