最佳做法是「最新的」長後重建

Question

我們有一個一般性的問題有關最佳實踐/編程時長的索引重建。這個問題不是「solr specific」，也可以適用於原始Lucene或任何其他類似的索引工具/庫/黑匣子。

問題

什麼是保證的Solr/Lucene索引的最佳做法是「絕對最新的」長索引重建後，即如果12小時指數的過程中重建，用戶有加/修改/刪除數據庫記錄或文件（PDF格式的），你如何確保在最後重建索引「包括」這些變化？

語境

• 大型數據庫和Solr的索引文件系統（例如PDF文件）
• 多核Solr的實例，其中CORE0是「搜索」，所有添加/更改/刪除核心-1是「重建」.Core1是一個「臨時核心」。
• 重建我們「搬家」核1至CORE0結束後，這樣的搜索和更新違背新鮮重建分貝

當前的方法

• 重建過程查詢數據庫，並/或遍歷文件系統的「所有數據庫記錄」或「所有文件」
• 重建，如果他們出現在查詢/文件系統遍歷年底將「獲取」新的數據庫記錄/ PDF文件。 （例如，查詢是「從由element_id元素順序*」。如果我們繼續將結果集的開放式i..e，而不是所有在建的大名單一度結果集將包括項添加在最後。同樣的，如果新文件被添加到「結尾」（新文件夾或新文件），文件遍歷將包括這些文件。
• 重建將而不是「獲得」以下內容：更改或刪除重建的db記錄/文檔過程已經處理過，「只是重建索引」

擬議方針

01在Solr的客戶
• 軌道（即通過數據庫表）的所有添加/修改/出現的DB /文件系統
• 在重建（但交換核心）之前，過程中這些改變的最終刪除：即從索引中刪除所有已刪除的記錄/ PDF文件，編制所有更新和補充

按照第

• 有沒有更好的辦法
• Solr中是否有任何魔法手段來「合併」成CORE0核心-1

謝謝

Answer 1

有許多方法來剝皮這隻貓....我猜測，在core1（又名「on deck」核心）的長索引過程中，您正在針對已經填充的core0（又名「live」核心）運行用戶查詢。

1. 如果你能區分哪些變化，爲什麼不更新活動核心？如果您可以針對活動核心和PDF的文件系統運行查詢以查明哪些文檔已更新，哪些文件已被刪除，只需針對活動核心執行所有操作，然後放棄此離線過程。這將是最簡單的....只需在您的solr文檔中放置pdf的更新時間即可檢測哪些已更改。如果pdf不存在於solr中，則添加它。保留solr文檔ID列表，最後，可以刪除沒有匹配PDF的任何文檔。在此期間，你仍然有未來的實時更新。

2. 你可以代理傳入的實時更新和複用（？）他們，讓他們去這兩個核心-1和CORE0。我已經構建了一個簡單的代理接口，並發現它非常簡單。這樣，所有更新都將發佈到您的兩個核心，而且您不必執行任何「調整」。

3. 最後，您可以合併兩個核心：http://wiki.apache.org/solr/MergingSolrIndexes#Merging_Through_CoreAdmin如果您有兩個具有相同ID的文檔，或者一個文檔不在一個核心中，但在另一個核心中存在，我並不真正知道發生了什麼......我認爲這都是一個附加過程，但是你想要深入研究這一點。

喜歡聽聽這是怎麼回事！