什么是Solr近實時搜索（NRT）

近實時搜索

什么是 Solr 近實時搜索？近實時（Near Real Time，簡稱NRT）搜索意味著文檔在被索引后幾乎立即可用于搜索。

這允許在“接近”實時看到文檔的添加和更新。在提交過程中，Solr 不會阻止更新。在打開新的索引和返回的新搜索之前，它也不會等待后臺合并完成。

通過使用 NRT，您可以將 commit 命令修改為軟提交，這樣可以避免可能造成代價的標(biāo)準(zhǔn)提交的部分內(nèi)容。您仍然希望執(zhí)行標(biāo)準(zhǔn)提交以確保文檔處于穩(wěn)定存儲狀態(tài)，但軟提交允許您在此期間同時查看索引的非常近實時視圖。

但是，要特別注意緩存和自動設(shè)置（autowarm）設(shè)置，因為它們會對 NRT 性能產(chǎn)生很大的影響。

提交和優(yōu)化（Commits 和 Optimizing）

提交操作使索引更改對新的搜索請求可見。一個硬提交（hard commit）使用事務(wù)日志來獲得的最新文檔更改的ID，并在索引文件上調(diào)用 fsync，以確保它們已被刷新到穩(wěn)定的存儲，并且不會因電源故障而導(dǎo)致數(shù)據(jù)丟失。當(dāng)前的事務(wù)日志被關(guān)閉，并打開一個新的事務(wù)日志。有關(guān)數(shù)據(jù)丟失問題，請參閱下面的“事務(wù)日志”討論。

軟提交（soft commit）的速度要快得多，因為它只會使索引更改可見，而不 fsync 索引文件，或者編寫新的索引描述符或啟動新的事務(wù)日志。搜索具有 NRT 要求（希望對搜索快速可見的索引更改）的集合將希望經(jīng)常進(jìn)行軟提交，但不太經(jīng)常提交。softCommit 可能花費較少，但它不是免費的，因為它可能會降低吞吐量。有關(guān)數(shù)據(jù)丟失問題，請參閱下面的“事務(wù)日志”討論。

優(yōu)化就像硬提交, 除非它強(qiáng)制所有的索引段首先合并到單個段中。根據(jù)使用情況，這個操作應(yīng)該很少進(jìn)行，因為它涉及讀取和重寫整個索引。片段通常會隨著時間的推移而合并（由合并政策確定），而優(yōu)化只是迫使這些合并立即發(fā)生。

軟提交使用兩個參數(shù)：maxDocs 和 maxTime。

• maxDocs
  

  整數(shù)。定義在將它們推送到索引之前要排隊的文檔的數(shù)量。它與update_handler_autosoftcommit_max_time參數(shù)一起工作，如果達(dá)到任何限制，文檔將被推送到索引。

• maxTime
  

  將文檔推送到索引之前要等待的毫秒數(shù)。它與update_handler_autosoftcommit_max_docs參數(shù)一起工作，如果達(dá)到任何限制，文檔將被推送到索引。

使用 maxDocs 和 maxTime 可以適當(dāng)?shù)卣{(diào)整您的提交策略。

事務(wù)日志（tlogs）

事務(wù)日志是至少最后一個 N (默認(rèn) 100) 文檔索引的 "滾動窗口"。Tlogs 在 solrconfig. xml 中配置，包括 N 的值。當(dāng)前的事務(wù)日志是關(guān)閉的，每當(dāng)發(fā)生各種硬性提交時都會打開一個新的事務(wù)日志。軟提交對事務(wù)日志沒有影響。

啟用 tlog 時，添加到索引中的文檔將在索引調(diào)用返回到客戶端之前寫入 tlog。如果發(fā)生不正常的關(guān)閉（例如：斷電、JVM 崩潰等），則任何寫入到 Solr 停止時打開的 tlog 的文檔將在啟動時重播。

當(dāng) Solr 被正常關(guān)閉（即使用 bin/solr stop 命令等）時，Solr 將關(guān)閉 tlog 文件和索引段，因此在啟動時不需要重播。

AutoCommits

自動提交也使用 maxDocs 和 maxTime 參數(shù)。然而，在許多策略中使用硬性 autocommit 和 autosoftcommit 實現(xiàn)更靈活的提交是有用的。

一個常見的配置是每隔1 - 10分鐘執(zhí)行一次硬性 autocommit，每秒鐘執(zhí)行一次 autosoftcommit。使用這種配置，新文檔將在添加后大約一秒鐘內(nèi)顯示出來，如果斷電，軟提交將會丟失，除非已經(jīng)完成了硬提交。

例如：

<autoSoftCommit>
  <maxTime>1000</maxTime>
</autoSoftCommit>

最好使用 maxTime 而不是 maxDocs 修改 autoSoftCommit，尤其是在通過提交操作對大量文檔進(jìn)行索引時。關(guān)閉 autoSoftCommit 批量索引也是更好的選擇。

提交和優(yōu)化的可選屬性

• waitSearcher
  

  阻塞，直到打開新的搜索器并將其注冊為主要查詢搜索器，使更改可見。默認(rèn)是true。

• OpenSearcher
  

  打開一個新的搜索器，使目前為止搜索到的所有文檔都可見。默認(rèn)是true。

• softCommit
  

  執(zhí)行一個軟提交。這將更快地刷新索引的視圖，但不保證文檔穩(wěn)定存儲。默認(rèn)是false。

• expungeDeletes
  

  僅適用于commit是否從段中清除已刪除的數(shù)據(jù)。默認(rèn)是false。

• maxSegments
  

  僅適用于optimize最多可以優(yōu)化的部分。默認(rèn)是1。

提交和優(yōu)化具有可選屬性的示例：

<commit waitSearcher="false"/>
<commit waitSearcher="false" expungeDeletes="true"/>
<optimize waitSearcher="false"/>

將提交和提交的參數(shù)作為 URL 的一部分傳遞

更新處理程序也可以獲取 commit 相關(guān)參數(shù)作為更新 URL 的一部分。這個例子添加了一個小的測試文檔，并在之后立即產(chǎn)生一個明確的提交：

http://localhost:8983/solr/my_collection/update?stream.body=<add><doc>
   <field name="id">testdoc</field></doc></add>&commit=true

或者，您可能想要使用這個：

http://localhost:8983/solr/my_collection/update?stream.body=<optimize/>

這個例子使得索引被優(yōu)化到最多10個段，但是不會等待，直到完成（waitFlush=false）：

curl 'http://localhost:8983/solr/my_collection/update?optimize=true&maxSegments=10&waitFlush=false'

這個例子增加了一個小小的測試文檔，包含了 commitWithin，告訴 Solr 確保文檔不晚于10秒后提交（這個方法通常優(yōu)于顯式提交）：

curl http://localhost:8983/solr/my_collection/update?commitWithin=10000
  -H "Content-Type: text/xml" --data-binary '<add><doc><field name="id">testdoc</field></doc></add>'

雖然stream.body功能對于開發(fā)和測試非常重要，但它通常不應(yīng)該在生產(chǎn)系統(tǒng)中啟用，因為它允許用戶讀取可能改變系統(tǒng)狀態(tài)的權(quán)限。該功能在默認(rèn)情況下是禁用的。有關(guān)詳細(xì)信息，請參見SolrConfig 中的 RequestDispatcher。

更改默認(rèn)的 commitWithin 行為

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

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

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