本節(jié)中的設置在solrconfig.xml中的<updateHandler>元素中進行配置，可能會影響索引更新的性能。這些設置影響在內部進行更新的方式。<updateHandler>配置不會影響處理客戶端更新請求的RequestHandler的更高級配置。

<updateHandler class="solr.DirectUpdateHandler2">
  ...
</updateHandler>

提交（Commits）

發(fā)送到 Solr 的數(shù)據(jù)在被提交到索引之前是不可搜索的。這樣做的原因是，在某些情況下，提交可能會很慢，并且應該與其他可能的提交請求隔離進行，以避免覆蓋數(shù)據(jù)。所以，最好提供數(shù)據(jù)提交時的控制權。有幾個選項可用來控制提交的時間。

commit和softCommit

在Solr中，commit是一個動作，要求Solr將這些改變“提交”到Lucene索引文件中。默認情況下，提交操作會導致所有Lucene索引文件“hard commit”到穩(wěn)定的存儲（磁盤）。當客戶端包含具有更新請求的commit=true參數(shù)時，可以確保索引更新完成后，就會將更新中受添加和刪除影響的所有索引段寫入磁盤。

如果指定了一個額外的標志：softCommit=true，那么Solr執(zhí)行一個“soft commit”，這意味著Solr會快速地將您的更改提交到Lucene數(shù)據(jù)結構，但不能保證Lucene索引文件被寫入到穩(wěn)定的存儲中。這是近實時存儲的一個實現(xiàn)，這個功能可以提高文檔的可見性，因為您不必等待后臺合并和存儲（如果使用SolrCloud，則到ZooKeeper ）完成，然后再轉到其他位置。完全提交意味著，如果服務器崩潰，Solr將確切地知道您的數(shù)據(jù)存儲在哪里；soft commit意味著數(shù)據(jù)被存儲，但位置信息尚未被存儲。折中的方法是，soft commit使您能夠更快地查看，因為它不等待后臺合并完成。

有關近實時操作的更多信息，請參閱近實時搜索。

自動提交

這些設置控制掛起的更新將自動推送到索引的頻率。自動提交的另一種替代方法是使用commitWithin，它可以在向Solr發(fā)送更新請求（即推送文檔時）或更新RequestHandler時定義。

• maxDocs
  

  自上次提交以來發(fā)生的更新次數(shù)。

• maxTime
  

  自最早未提交更新以來的毫秒數(shù)。

• openSearcher
  

  是否在執(zhí)行提交時打開新的搜索器。如果是false，則提交將刷新最近的索引更改為穩(wěn)定的存儲，但不會導致新的搜索器被打開，使這些更改可見。默認是true。

如果達到了 maxDocs 或 maxTime 限制，Solr 將自動執(zhí)行提交操作。如果缺少自動提交標記，那么只有顯式提交才會更新索引。是否使用自動提交取決于您的應用程序的需求。

確定最佳自動提交設置是性能和準確性之間的權衡。導致頻繁更新的設置將提高搜索的準確性，因為新內容可以更快地進行搜索，但由于頻繁的更新，性能可能會受到影響。不太頻繁的更新可能會提高性能，但在查詢中顯示更新需要更長的時間。

<autoCommit>
  <maxDocs>10000</maxDocs>
  <maxTime>30000</maxTime>
  <openSearcher>false</openSearcher>
</autoCommit>

您也可以像指定'soft'提交一樣指定'soft'自動提交，不同之處在于，您不應將 autoSoftCommit 標記設置為 "自動提交"。

<autoSoftCommit>
  <maxTime>60000</maxTime>
</autoSoftCommit>

commitWithin

這些commitWithin設置允許強制文檔提交在規(guī)定的時間段內發(fā)生。這在近實時搜索中最常使用，因此默認情況下是執(zhí)行soft提交。但是，這并不會將新文檔復制到主/從環(huán)境中的從屬服務器上。如果這是對實現(xiàn)的要求，可以通過添加一個參數(shù)來強制執(zhí)行，如下例所示：

<commitWithin>
  <softCommit>false</softCommit>
</commitWithin>

有了這個配置，當您將commitWithin作為更新消息的一部分進行調用時，每次都會自動執(zhí)行一個硬性提交。

事件監(jiān)聽器

UpdateHandler部分也是可以配置與更新相關的事件偵聽器的地方。這些可以在任何commit（event="postCommit"）之后觸發(fā)，或者僅在優(yōu)化命令（event="postOptimize"）之后觸發(fā)。

用戶可以編寫自定義更新事件監(jiān)聽器類，但常見的用例是通過RunExecutableListener運行外部可執(zhí)行文件：

• exe
  

  要運行的可執(zhí)行文件的名稱。它應該包括文件的路徑，相對于Solr home。

• dir
  

  用作工作目錄的目錄。默認是當前目錄（“.”）。

• wait
  

  強制調用線程等待，直到可執(zhí)行文件返回響應。默認是true。

• args
  

  任何傳遞給程序的參數(shù)。默認值是none。

• env
  

  任何環(huán)境變量設置。默認值是none。

事務日志

如RealTime Get部分所述，該功能需要事務日志。它在 solrconfig. xml 的 updateHandler 部分中進行了配置。

實時獲取當前依賴于默認情況下啟用的更新日志功能。它依賴于在 solrconfig. xml 中配置的更新日志，其內容如下：

<updateLog>
  <str name="dir">${solr.ulog.dir:}</str>
</updateLog>

三個額外的專家級配置設置會影響索引性能，以及復制副本在必須進入完全恢復之前可能落后于更新的程度，有關更多信息，請參見寫入端容錯部分：

• numRecordsToKeep
  

  每個日志保留的更新記錄數(shù)。默認是100。

• maxNumLogsToKeep
  

  日志的最大數(shù)量保持不變。默認是10。

• numVersionBuckets
  

  用于在檢查重新更新時用于跟蹤最大版本值的bucket的數(shù)量；增加此值可降低在高容量索引期間同步對版本存儲區(qū)的訪問的成本，這要求每個Solr核心具有堆空間

(8 bytes (long) * numVersionBuckets)。默認是65536。

一個例子，要被包括在solrconfig.xml的<config><updateHandler>下，將使用上述高級設置：

<updateLog>
  <str name="dir">${solr.ulog.dir:}</str>
  <int name="numRecordsToKeep">500</int>
  <int name="maxNumLogsToKeep">20</int>
  <int name="numVersionBuckets">65536</int>
</updateLog>