Solr搜索引擎【索引提交、事務日誌、原子更新】

一.索引提交java

  當一個文檔被添加到Solr中,但沒有提交給索引以前,這個文檔是沒法被搜索的。換句話說,從查詢的角度看,文檔直到提交以後纔是可見的。Solr有兩種類型的提交:軟提交和正常提交【也稱硬提交】。apache

  1.正常提交  安全

    Solr正常提交是將全部未提交的文檔寫入磁盤,並刷新一個內部搜索器組件,讓新提交的文檔可以被搜索。搜索器實際上能夠看做索引中全部已提交文檔的只讀視圖。能夠這樣說,硬提交是花銷很大的操做,因爲硬提交須要開啓一個新搜索器,因此會影響到查詢性能。服務器

    當正常提交成功後,新提交的文檔被安全保存在持久存儲器上不會由於正常的維護操做或服務器崩潰重啓而丟失。出於高可用性考慮,若是磁盤發生故障,就須要一套故障轉移方案,這一點在之後接着討論。ide

  2.軟提交性能

    軟提交支持近實時搜索【Near Real-Time NRT】。軟提交做爲近乎實時可被搜索到的一種機制,跳過了硬提交的高消耗,例如,刷新到持久存儲器就是花銷較大的操做。軟提交相對而言花銷較低,能夠每一秒都執行一次軟提交,使得新近被索引的文檔在添加到Solr以後很快被搜索到。但要記住,在某一時刻仍然須要執行硬提交操做,以確保文檔最終被寫入到持久化存儲器中。ui

  綜上所述:this

    》硬提交讓文檔可被搜索,因爲須要將其寫入到持久化存儲器中,因此花銷較大spa

    》軟提交也可讓文檔被搜索,不須要將其寫入到持久化存儲中日誌

  3.自動提交

    無論是正常提交仍是軟提交,均可以採用如下三種策略中的一種來自動提交文檔:

      》在指定時間內提交文檔

      》一旦達到用戶指定的未提交文檔數閾值,就提交那麼未提交的文檔

      》每隔特定時間間隔提交全部文檔

  4.配置

    Solr硬提交與軟提交的自動提交須要在solrconfig.xml中進行配置。 

 1     <!-- AutoCommit
 2 
 3          Perform a hard commit automatically under certain conditions.
 4          Instead of enabling autoCommit, consider using "commitWithin"
 5          when adding documents.
 6 
 7          http://wiki.apache.org/solr/UpdateXmlMessages
 8 
 9          maxDocs - Maximum number of documents to add since the last
10                    commit before automatically triggering a new commit.
11 
12          maxTime - Maximum amount of time in ms that is allowed to pass
13                    since a document was added before automatically
14                    triggering a new commit.
15          openSearcher - if false, the commit causes recent index changes
16            to be flushed to stable storage, but does not cause a new
17            searcher to be opened to make those changes visible.
18 
19          If the updateLog is enabled, then it's highly recommended to
20          have some sort of hard autoCommit to limit the log size.
21       -->
22      <autoCommit>
23        <maxTime>${solr.autoCommit.maxTime:15000}</maxTime> <!-- 上一次提交到自動提交的最長時間間隔 -->
24        <openSearcher>false</openSearcher> <!-- 提交後是否開啓一個新的搜索器 -->
25      </autoCommit>

  執行自動提交時一般會打開一個新搜索器。在默認狀況下【未開啓】,某文件自動提交,該文件將被寫入到磁盤,但在搜索結果中不可見。Solr之因此提供這個選項,是爲了減小未提交更新的事務日誌大小,並避免在大規模索引過程當中打開太多搜索器。

  在solrconfig.xml中使用autoSoftCommit元素也能夠自動配置軟提交。

1     <!-- softAutoCommit is like autoCommit except it causes a
2          'soft' commit which only ensures that changes are visible
3          but does not ensure that data is synced to disk.  This is
4          faster and more near-realtime friendly than a hard commit.
5       -->
6 
7      <autoSoftCommit>
8        <maxTime>${solr.autoSoftCommit.maxTime:-1}</maxTime> <!-- -1表示無限大 -->
9      </autoSoftCommit>

二.事務日誌

  Solr使用事務日誌來確保提交到索引並已接受的更新保存在持久化存儲器中。事務日誌用來避免因提交過程當中的異常狀況而致使提交的文檔丟失的狀況。具體來講,事務日誌主要有三個做用:

    》支持近實時獲取和原子更新【下面具體講解】

    》解除提交過程當中寫入的持久性

    》經過solrcloud的分片表明支持副本的同步

  在solrconfig.xml中的一個Solr內核的事務日誌配置以下:

 1 <!-- Enables a transaction log, used for real-time get, durability, and
 2          and solr cloud replica recovery.  The log can grow as big as
 3          uncommitted changes to the index, so use of a hard autoCommit
 4          is recommended (see below).
 5          "dir" - the target directory for transaction logs, defaults to the
 6                 solr data directory.
 7          "numVersionBuckets" - sets the number of buckets used to keep
 8                 track of max version values when checking for re-ordered
 9                 updates; increase this value to reduce the cost of
10                 synchronizing access to version buckets during high-volume
11                 indexing, this requires 8 bytes (long) * numVersionBuckets
12                 of heap space per Solr core.
13     -->
14     <updateLog>
15       <str name="dir">${solr.ulog.dir:}</str> <!-- 默認目錄是data目錄下的tlog -->
16       <int name="numVersionBuckets">${solr.ulog.numVersionBuckets:65536}</int>
17     </updateLog>

  每次提交狀況都會被記錄到事務日誌中。直到發起提交以前,事務日誌會持續增加。在提交期間會處理活動的事務日誌,以後將打開一個新的事務日誌。一個更新執行步驟以下:

  

 

  執行步驟解釋以下:

    1.客戶端應用程序使用HTTP POST方式發送一個更新請求,能夠是JSON/XML或者Solr內部二進制javabin格式

    2.Jetty【Solr內部自帶的WEB服務器】將此請求發送給Solr的Web應用程序

    3.Solr的請求調度器經過請求路徑中的collection名稱肯定調用的solr內核。接下來調度器定位到/update請求處理器

    4.更新請求處理器對該請求進行處理,且該請求處理器將調用一個可配置的更新處理器鏈,在索引時爲每一個文檔進行額外的處理

    5.ADD請求寫入到事務日誌中

    6.一旦更新請求被安全地保存到持久存儲器,就會經過響應讀寫器迴應客戶端應用。這時,客戶端應用得知更新請求成功執行,就能夠繼續執行下面的請求

  注意,事務日誌的關鍵在於權衡事務日誌的長度與硬提交的執行頻率。若是事務日誌變得很龐大,重啓就須要更長時間來處理更新,也會形成恢復過程緩慢。

相關文章
相關標籤/搜索