国产gaysexchina男同gay,japanrcep老熟妇乱子伦视频,吃奶呻吟打开双腿做受动态图,成人色网站,国产av一区二区三区最新精品

SolrCloud中的碎片和索引數(shù)據(jù)

2018-12-26 11:00 更新

當(dāng)您的集合對(duì)于一個(gè)節(jié)點(diǎn)來說太大時(shí),您可以通過創(chuàng)建多個(gè)分片將其分解并分段存儲(chǔ)。

碎片是集合的邏輯分區(qū),包含集合中的文檔的子集,使集合中的每個(gè)文檔都包含在一個(gè)碎片中。哪個(gè)碎片包含集合中的每個(gè)文檔取決于該集合的整體“碎片”策略。

例如,您可能有一個(gè)集合,其中每個(gè)文檔的“國家/地區(qū)”字段確定它屬于哪個(gè)分片,因此來自同一個(gè)國家/地區(qū)的文檔位于同一位置。不同的集合可以簡單地在每個(gè)文檔的uniqueKey上使用“哈希”來確定其碎片。

在SolrCloud之前,Solr支持分布式搜索,它允許在多個(gè)分片上執(zhí)行一個(gè)查詢,因此查詢是針對(duì)整個(gè)Solr索引執(zhí)行的,搜索結(jié)果中不會(huì)有任何文檔被遺漏。所以在一個(gè)碎片上分割一個(gè)索引并不完全是一個(gè)SolrCloud的概念。然而,分布式方法存在幾個(gè)問題,需要使用SolrCloud進(jìn)行改進(jìn):

  1. 將索引分割成碎片是有點(diǎn)手動(dòng)的。
  2. 沒有支持分布式索引,這意味著您需要明確地發(fā)送文件到一個(gè)特定的碎片;Solr無法自行找出發(fā)送文件的碎片。
  3. 沒有負(fù)載平衡或故障轉(zhuǎn)移,所以如果您有大量的查詢,您需要找出發(fā)送它們的位置,如果一個(gè)碎片死了,它就消失了。

SolrCloud解決了這些限制。支持自動(dòng)分配索引進(jìn)程和查詢,并且ZooKeeper提供故障轉(zhuǎn)移和負(fù)載平衡。另外,每個(gè)碎片都可以有多個(gè)復(fù)制副本,以增強(qiáng)可靠性。

Leader和副本

在SolrCloud中沒有主人或奴隸。相反,每個(gè)碎片至少包含一個(gè)物理副本,其中一個(gè)是Leader。Leader自動(dòng)當(dāng)選,最初是先到先得,然后根據(jù)http://zookeeper.apache.org/doc/trunk/recipes.html#sc_leaderElection上描述的ZooKeeper流程。

如果一個(gè)Leader失敗了,其他副本中的一個(gè)會(huì)自動(dòng)選為新的Leader。

當(dāng)文檔被發(fā)送到Solr節(jié)點(diǎn)進(jìn)行索引時(shí),系統(tǒng)首先確定該文檔屬于哪個(gè)碎片,然后確定哪個(gè)節(jié)點(diǎn)當(dāng)前正在主管該碎片的Leader。然后將文檔轉(zhuǎn)發(fā)給當(dāng)前Leader進(jìn)行索引,并且Leader將更新轉(zhuǎn)發(fā)給所有其他副本。

副本的類型

默認(rèn)情況下,如果leader失敗,所有副本都有資格成為leader。但是,這是有要求的:如果所有副本都可以在任何時(shí)候成為leader,那么每個(gè)副本都必須始終與其leader保持同步。添加到leader的新文檔必須路由到副本,每個(gè)副本必須提交。如果副本發(fā)生故障或暫時(shí)不可用,然后重新加入群集,則恢復(fù)可能會(huì)很慢,因?yàn)樗e(cuò)過了大量的更新。

這些問題對(duì)于大多數(shù)用戶來說不是問題。但是,如果副本的表現(xiàn)更像前一種模式,則某些用例會(huì)更好一些,或者不是實(shí)時(shí)同步,或者根本就沒有資格成為leader。

Solr通過允許您在創(chuàng)建新集合或添加副本時(shí)設(shè)置副本類型來完成此操作??捎玫念愋褪牵?/p>

  • NRT:這是默認(rèn)的設(shè)置。NRT副本(NRT = NearRealTime)維護(hù)事務(wù)日志,并將新文檔寫入本地索引。任何這種類型的副本都有資格成為leader。傳統(tǒng)上,這是Solr唯一支持的類型。
  • TLOG:這種類型的副本維護(hù)事務(wù)日志,但不會(huì)在本地索引文檔更改。這種類型有助于加快索引,因?yàn)楦北局胁恍枰l(fā)生任何提交。當(dāng)這種類型的副本需要更新其索引時(shí),通過復(fù)制leader的索引來實(shí)現(xiàn)。這種類型的復(fù)制品也有資格成為碎片的leader;它會(huì)通過首先處理它的事務(wù)日志來做到這一點(diǎn)。如果它確實(shí)成為leader,它將表現(xiàn)得如同它是NRT類型的復(fù)制品一樣。
  • PULL:這種類型的副本不會(huì)維護(hù)事務(wù)日志,也不會(huì)在本地修改索引文檔。它只復(fù)制碎片leader的索引。沒有資格成為碎片leader,根本不參加碎片leader候選。

如果在創(chuàng)建時(shí)未指定副本的類型,則將是NRT類型。

組合群集中的副本類型

有三種推薦的副本類型的組合:

  • 所有NRT副本
  • 所有TLOG副本
  • 帶有PULL副本的TLOG副本

所有NRT副本

將其用于小型到中型的群集,甚至是更新(索引)吞吐量不太高的大型群集。NRT是唯一支持soft-commits的副本,所以在需要NearRealTime時(shí)也可以使用這種組合。

所有TLOG副本

如果不需要NearRealTime,并且每個(gè)碎片的副本數(shù)量很高,則使用此組合,但是您仍然希望所有副本能夠處理更新請(qǐng)求。

TLOG副本加上PULL副本

如果不需要NearRealTime,則每個(gè)分片的副本數(shù)很高,并且希望通過文檔更新提高搜索查詢的可用性,即使這意味著暫時(shí)服務(wù)過時(shí)的結(jié)果,也可以使用此組合。

副本類型的其他組合

不推薦其他副本類型的組合。如果碎片中的多個(gè)副本正在寫入自己的索引,而不是從NRT副本中復(fù)制,則leader選舉可能導(dǎo)致碎片的所有副本與leader不同步,并且所有副本都必須復(fù)制完整索引。

使用PULL副本恢復(fù)

如果PULL副本下降或離開群集,則需要考慮幾個(gè)方案。

如果PULL副本由于leader關(guān)閉而無法同步到leader,則不會(huì)發(fā)生復(fù)制。但是,它將繼續(xù)提供查詢服務(wù)。一旦它可以再次連接到leader,副本將恢復(fù)。

如果PULL副本無法連接到ZooKeeper,它將從群集中刪除,查詢將不會(huì)從群集路由到它。

如果PULL副本因任何其他原因死亡或無法訪問,將無法進(jìn)行查詢。當(dāng)它重新加入集群時(shí),它將從leader復(fù)制,當(dāng)完成時(shí),它將準(zhǔn)備再次提供查詢服務(wù)。

文檔路由

Solr提供了在創(chuàng)建集合時(shí)通過指定router.name參數(shù)來指定集合使用的路由器實(shí)現(xiàn)的功能。

如果使用compositeId路由器(默認(rèn)),則可以在文檔ID中使用前綴發(fā)送文檔,該文檔ID將用于計(jì)算哈希Solr用于確定文檔發(fā)送到索引的碎片。前綴可以是您想要的任何東西(例如,它不一定是分片名稱),但它必須是一致的,所以Solr的行為一致。

例如,如果要為客戶共同定位文檔,則可以使用客戶名稱或ID作為前綴。如果您的客戶是“IBM”,例如,ID為“12345”的文檔,則可以在文檔ID字段中插入前綴“IBM!12345”。感嘆號(hào)('!')在這里至關(guān)重要,因?yàn)樗鼌^(qū)分了用于確定哪個(gè)分片用于指引文檔的前綴。

然后在查詢時(shí),用_route_參數(shù)(即,q=solr&_route_=IBM!)將查詢前綴(es)包含到查詢中,以將查詢引導(dǎo)到特定的碎片。在某些情況下,這可能會(huì)提高查詢性能,因?yàn)樗诓樵兯兴槠瑫r(shí)克服了網(wǎng)絡(luò)延遲。

該compositeId路由器支持含有最多2級(jí)路由的前綴。例如:首先按地區(qū)進(jìn)行前綴路由,然后由客戶:“USA!IBM!12345”

另一個(gè)用例可能是:客戶“IBM”擁有大量文檔,并且希望將其分散到多個(gè)碎片中。這種用例的語法是:shard_key/num!document_id;其中 /num是從復(fù)合哈希中使用的分片密鑰中的比特?cái)?shù)。

所以IBM/3!12345將從分片密鑰中獲取3位,從獨(dú)特的文檔ID中獲取29位,在集合中傳播占用超過1/8的碎片。同樣,如果num值是2,則會(huì)將文檔分散到碎片數(shù)量的1/4。在查詢時(shí),您可以使用_route_參數(shù)(即q=solr&_route_=IBM/3!)將查詢的前綴(es)和位數(shù)包含到查詢中,以將查詢定向到特定的分片。

如果您不想影響文檔的存儲(chǔ)方式,則不需要在文檔ID中指定前綴。

如果創(chuàng)建了集合并在創(chuàng)建時(shí)定義了“隱式”路由器,則還可以定義一個(gè)router.field參數(shù),以使用每個(gè)文檔中的字段標(biāo)識(shí)文檔所屬的分片。如果指定的字段在文檔中缺失,則該文檔將被拒絕。您也可以使用該_route_參數(shù)來命名特定的分片。

碎片分割

當(dāng)您在SolrCloud中創(chuàng)建一個(gè)集合時(shí),您決定要使用的初始數(shù)字碎片。但是事先很難知道您需要的碎片的數(shù)量,特別是當(dāng)組織需求在可以隨時(shí)改變的時(shí)候,以及稍后發(fā)現(xiàn)您選擇錯(cuò)誤的成本可能很高,包括創(chuàng)建新的內(nèi)核和重新索引您的所有數(shù)據(jù)。

分割碎片的能力在Collections API中。目前它允許將碎片分成兩部分?,F(xiàn)有的分片保持原樣,所以拆分操作有效地將數(shù)據(jù)的兩個(gè)副本作為新的分片。準(zhǔn)備就緒后,您可以稍后刪除舊的碎片。

有關(guān)如何使用碎片分割的更多詳細(xì)信息,請(qǐng)參考“Collection API SPLITSHARD命令”部分。

在SolrCloud中忽略來自客戶端應(yīng)用程序的提交

在大多數(shù)情況下,在SolrCloud模式下運(yùn)行時(shí),索引客戶端應(yīng)用程序不應(yīng)該發(fā)送顯式提交請(qǐng)求。相反,您應(yīng)該使用openSearcher=false和自動(dòng)soft-commits配置自動(dòng)提交以使最近的更新在搜索請(qǐng)求中可見。這可以確保在集群中定期執(zhí)行自動(dòng)提交。

為了強(qiáng)制客戶端應(yīng)用程序不應(yīng)該發(fā)送顯式提交的策略,您應(yīng)該更新將數(shù)據(jù)索引到SolrCloud的所有客戶端應(yīng)用程序。然而,這并不總是可行的,所以Solr提供了IgnoreCommitOptimizeUpdateProcessorFactory,它允許您忽略顯式的提交或優(yōu)化來自客戶應(yīng)用程序的請(qǐng)求,而不用重構(gòu)您的客戶應(yīng)用程序代碼。

要激活這個(gè)請(qǐng)求處理器,您需要將以下內(nèi)容添加到您的solrconfig.xml中:

<updateRequestProcessorChain name="ignore-commit-from-client" default="true">
  <processor class="solr.IgnoreCommitOptimizeUpdateProcessorFactory">
    <int name="statusCode">200</int>
  </processor>
  <processor class="solr.LogUpdateProcessorFactory" />
  <processor class="solr.DistributedUpdateProcessorFactory" />
  <processor class="solr.RunUpdateProcessorFactory" />
</updateRequestProcessorChain>

如上面的示例所示,處理器將返回200給客戶端,但會(huì)忽略“提交/優(yōu)化”請(qǐng)求。請(qǐng)注意,您還需要連接SolrCloud所需的隱式處理器,因?yàn)榇俗远x鏈代替了默認(rèn)鏈。

在下面的示例中,處理器將使用帶有自定義錯(cuò)誤消息的403代碼引發(fā)異常:

<updateRequestProcessorChain name="ignore-commit-from-client" default="true">
  <processor class="solr.IgnoreCommitOptimizeUpdateProcessorFactory">
    <int name="statusCode">403</int>
    <str name="responseMessage">Thou shall not issue a commit!</str>
  </processor>
  <processor class="solr.LogUpdateProcessorFactory" />
  <processor class="solr.DistributedUpdateProcessorFactory" />
  <processor class="solr.RunUpdateProcessorFactory" />
</updateRequestProcessorChain>

最后,您還可以將其配置為只忽略優(yōu)化,并讓提交通過執(zhí)行:

<updateRequestProcessorChain name="ignore-optimize-only-from-client-403">
  <processor class="solr.IgnoreCommitOptimizeUpdateProcessorFactory">
    <str name="responseMessage">Thou shall not issue an optimize, but commits are OK!</str>
    <bool name="ignoreOptimizeOnly">true</bool>
  </processor>
  <processor class="solr.RunUpdateProcessorFactory" />
</updateRequestProcessorChain>
以上內(nèi)容是否對(duì)您有幫助:
在線筆記
App下載
App下載

掃描二維碼

下載編程獅App

公眾號(hào)
微信公眾號(hào)

編程獅公眾號(hào)