混合Lucene/MySQL查詢或概念

Question

我們的項目需要近實時搜索和不斷更新。數據當前存儲在MySQL數據庫中，Lucene索引隨着數據庫的修改而更新。

我們目前在我們想要的地方有搜索功能。但是，我們正在嘗試添加「標記」文件到索引/數據庫中的功能。由於數據源可能是數百萬條記錄，因此我們不想更新Lucene索引以進行標記（或者是否有方法可以對Lucene進行大規模更新）。我們在MySQL中有一個文檔ID表，我們希望用它來確定標籤集。

到目前爲止，我發現的最好的選擇是將ID列表作爲整數數組進行檢索，對它們進行排序（因此我只需要循環一次），然後遍歷並查找兩者之間的匹配（儘管這是不理想的，因爲我們可能會失去排序）。

嘗試在MySQL中的「IN」查詢中使用Lucene ID列表失敗，因爲文檔數量可能在數百萬個以及MySQL扼流器上。

深入瞭解我們如何優化或做到這一點？

另一個建議是使用MutliSearcher的第二個索引，但我不完全確定如何去做，因爲在更新或刪除標記集時，仍然需要更新索引，可能有100萬行。

Answer 1

對於您的「批量更新」，您不能在MySql表中基於時間戳記或類似文件對Lucene索引執行delta更新嗎？我已經在solr中完成了這個任務，而不是直接在Lucene中完成，但由於Solr是Lucene功能的一個包裝，這基本上是相同的（或者我假設......）。

。

Relevant question, (perhaps).

Answer 2

對於所有下面的假設是，你沒有足夠的RAM完全容納整個集合。

索引技術的設計特別適用於讀取次數多於寫入次數的情況。首先分析相應的頻率並因此量化「持續更新」將是很好的。

如果更新頻率太高，您可能想嘗試直接使用您的數據庫系統處理這部分搜索（如果MySQL沒有完成這項工作，也有PostgreSQL;響應速度也會取決於數據庫中的索引機制和可用於在內存中緩存它們的內存）。否則，您可能需要考慮Solr（這不僅僅是Lucene的一個簡單包裝，因爲它提供了可能基於Lucene的額外功能，但本身並不能使用Lucene）。

特別是：

• Solr performance factors
• Multi Core approach（即核心交換）
• StreamingUpdateSolrServer

也許你可以使用取決於更新的批量大小和性能不同的策略提交/優化的交易。對於大批量更新，複製備用核心，批量更新，提交/優化和交換核心可能更容易。但是，它不再是「近實時」（NRT）; NRT in Lucene的想法是本地的並且直接依賴於可用的RAM和集合大小。