W3Cschool
恭喜您成為首批注冊(cè)用戶
獲得88經(jīng)驗(yàn)值獎(jiǎng)勵(lì)
當(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):
SolrCloud解決了這些限制。支持自動(dòng)分配索引進(jìn)程和查詢,并且ZooKeeper提供故障轉(zhuǎn)移和負(fù)載平衡。另外,每個(gè)碎片都可以有多個(gè)復(fù)制副本,以增強(qiáng)可靠性。
在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>
如果在創(chuàng)建時(shí)未指定副本的類型,則將是NRT類型。
有三種推薦的副本類型的組合:
將其用于小型到中型的群集,甚至是更新(索引)吞吐量不太高的大型群集。NRT是唯一支持soft-commits的副本,所以在需要NearRealTime時(shí)也可以使用這種組合。
如果不需要NearRealTime,并且每個(gè)碎片的副本數(shù)量很高,則使用此組合,但是您仍然希望所有副本能夠處理更新請(qǐng)求。
如果不需要NearRealTime,則每個(gè)分片的副本數(shù)很高,并且希望通過文檔更新提高搜索查詢的可用性,即使這意味著暫時(shí)服務(wù)過時(shí)的結(jié)果,也可以使用此組合。
不推薦其他副本類型的組合。如果碎片中的多個(gè)副本正在寫入自己的索引,而不是從NRT副本中復(fù)制,則leader選舉可能導(dǎo)致碎片的所有副本與leader不同步,并且所有副本都必須復(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命令”部分。
在大多數(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>
Copyright©2021 w3cschool編程獅|閩ICP備15016281號(hào)-3|閩公網(wǎng)安備35020302033924號(hào)
違法和不良信息舉報(bào)電話:173-0602-2364|舉報(bào)郵箱:jubao@eeedong.com
掃描二維碼
下載編程獅App
編程獅公眾號(hào)
聯(lián)系方式:
更多建議: