SolrCloud:根據Solr Wiki的譯文

標籤：

本文是作者根據Apache Solr Document的譯文，翻譯不正確或者理解不到位的地方歡迎大家指正！謝謝！Nodes, Cores, Cluster and LeadersNodes and Cores

在SolrCloud中，一個node就是一個JVM運行Solr的執行個體，通常稱之為server。每個Solrcore都可以被當作一個node。任何一個node都可以包含一個Solr的執行個體和多樣化的資料在其中。

Solr core中儲存了基於一篇文章中發現的常值內容和欄位的索引。一個單獨的Solr執行個體可以包含多個core，這些core基於本地的標準彼此間分離。這些core針對不同的使用者（在美國的使用者或者在加拿大的使用者）提供不同的搜尋方式，提供私密關注點（某些使用者不能訪問某些文檔），提供內容毫不相關或者很難整合到一起的文檔（鞋子的資料和DVD的資料）。

當你在SolrCloud模式下啟動一個新的core時，這個core會自動註冊到ZooKeeper當中。這一過程包括建立一個臨時node（如果Solr執行個體停止這個臨時node就會消失），註冊core和如何串連core（例如Solr的URL，core名稱等）的相關資訊。用戶端和叢集中的nodes可以通過這些資訊來決定為了執行請求需要訪問哪些資訊。

新的Solr cores可以通過CoreAdmin來建立和關聯collection。新增的雲相關參數將在Parameter Reference頁面介紹。使用CREATE操作的對象：

l  collection：core所屬於的collection。預設是core的名稱

l  shard：shardid代表core

l  collection.<param>=<value>：如果一個新的collection被建立就會設定一組<param>=<value>屬性。例如collection.configName=<configname>用來指出新的collection的config。

例如：

curl ‘http://localhost:8983/solr/admin/cores?action=CREATE&name=mycore&collection=my_collection&shard=shard2‘

Clusters

一個cluster是被ZooKeeper管理的一組Solr nodes單獨集合。當你擁有一個cluster，在任何時候你都可以向叢集發請求，如果這個請求是公認的，你可以確保這個請求會被作為一個單元來管理和持久化，也就是你不會遺失資料。做完操作馬上就可以看到狀態的更新，叢集可以被擴張或者收縮。

Creating a Cluster

只要在Zookeeper上註冊的Solr執行個體超過一個，叢集就被建立了。

Resing a Cluster

叢集包含一個可設定shard數量的參數。當你啟動solr的時候，通過傳遞系統參數numShards來設定新叢集的shard數量。無論任何一個Solr node都必須在第一次啟動的時候傳遞numShards參數，用來自動設定shard應該屬於哪個執行個體的一部分。一旦你啟動Solr node的數量超過numShards，nodes將會為每個shard建立replicas，均勻的分布在node上只要他們屬於同一個collection。

想要在你的collection中添加更多的core，僅僅啟動新的core。你可以在任何時候這樣做，新的core會在啟用之前與當前在shard中的replicas同步。

如果你採用手動的給一個core賦予一個shard id，你同樣可以繞過numShards。

Shard的數量決定了你的索引資料有多麼片段化，所以在你初始化叢集的設定之後你不能更改索引的shard數量。

不過，你有機會將你的索引分離到多個shard中去，即使你只有一台伺服器。你可以在將來擴張到多台伺服器上面。完成這個操作只要遵循以下幾點：

1.      在一台物理伺服器上用多個core來設定你的collection。每個shard都是那個shard下的leader。

2.      當你準備好了，你可以通過啟動每台新伺服器上所屬於那些shard新的replica來移動那些shard到新的伺服器上。

3.      刪除原來伺服器上的shard。ZooKeeper將會把replica升級為那個shard的leader。

Leaders and Replicas

leader的概念跟solr replication功能中的master很相近。Leader負責確保replicas跟儲存在leader中的資訊保持一致。

然後使用SolrCloud，你就不僅僅擁有一個master和一到多個slave，反而你很可能進行分散式查詢和多伺服器之間索引的通訊。如果你已經設定Solr的numShards=2，例如你的所有分別在兩個shard上。這種情況下，兩個shard都將被視為leader。如果你在初始化兩個之後啟動了更多的node，那這些node就自動的被當做這些leader的replica。

Replica歸屬於shard是為了他們在第一次加入到叢集時保持啟動狀態。這是由round-robin方式完成的，除非手動地將帶有shardId參數的新node歸屬給一個shard在啟動期間。這個參數通常作為系統的屬性，-DshardId=1，新的node需要附上shard的ID值。

在後期重啟的時候，每個node載入到node第一次啟動時分配給他的shard中去（不管這個分配是手動的還是自動的）。如果一開始被分配為leader的node不可擷取了，一個replica可以變成leader。

思考：

l  Node A伴隨引導參數啟動，指向一個獨立的ZooKeeper，numShards設定為2.

l  Node B啟動並指向獨立的ZooKeeper

Node A和Node B都是shard，在啟動Node A時定義滿足2個shard插槽。如果我們查看Solr控制台，我們會發現兩個node都包含leader（用一個實邊的白圓表示）。

l  Node C啟動並指向獨立的ZooKeeper

Node C將會自動成為Node A的一個replica，因為我們沒有指定他屬於任何一個其他的shard，而且他也不能夠成為一個新的shard因為我們只定義了兩個shard而且這兩個都被佔用了。

l  Node D啟動並指向獨立的ZooKeeper

Node D將會自動成為Node B的一個replica，道理與Node C相同。

進行重啟，假設Node C在Node A之前重啟會發生什嗎？Node C會成為leader，Node A成為了NodeC的replica。

Shards and IndexingData in SolrCloud

當你的資料存放區在一個node上數量過大，你可以分離這些資料通過建立一或多個shard來儲存在section中。每一個都是邏輯索引的一部分，或者是core，包含了所有node中section的索引。

Shard是一種以一定數量的server或是node來分離core的方法。例如，假設你有一個shard包含各種狀態的資料，或是不同種類的，將要被獨立的檢索，但通常是結合的。

在SolrCloud之前，Solr提供分布式檢索，允許從多個shard執行一個查詢，所以執行的這個查詢與solr全部索引對立而且查詢結果中不會丟失documents。所以通過shard分離core並不是Solrcloud專屬的概念。然而，分布式方法伴隨的一些問題SolrCloud很有必要進行改進：

1.      將core分離到shard中是手動的

2.      不支援分布式索引，那就意味著你需要明確的發送document到特殊的shard中；Sole不能指出document發送到了自己哪一個shard。

3.      沒有負載平衡或者容錯，所以如果你想大規模的查詢，你需要指出請求發送到哪而且如果一個shard崩潰了就結束了。

SolrCloud解決了這些問題。支援分布式的索引和分布式自動查詢，ZooKeeper提供容錯和負載平衡。另外，每個shard都可以有多個replica用來增加健壯性。

在SolrCloud中沒有master和slaves。代替他們的是leaders和replicas。Leaders是自動選舉的，以first-come-first-served為基本原則，基於ZooKeeper處理描述在http://zookeeper.apache.org/doc/trunk/recipes.html#sc_leaderElection

如果leader停掉了，他的一個replica就會被自動選舉為新的leader。每個node都啟動後，他會被分配到擁有最少replica的shard中。如果情況都一樣，那就會被分配到shard ID最小的那個shard中。

當一個document發送到伺服器用於索引時，系統會先判斷這台伺服器是一個replica還是leader。

l  如果伺服器是replica，這個document會轉寄給leader進行處理。

l  如果伺服器是leader，SolrCloud決定document應該訪問哪個shard，然後將document轉寄給那個shard的leader，在這個shard產生這個document的索引，然後標記該索引並轉寄給其他的replica。

Document Routing

當建立你的collection時，Solr具備通過指定router.name參數的collection來實現router的能力。如果你使用“compositeId”router，你可以發送帶document ID首碼的document，這將用於計算hash，Solr以此決定document發往哪個shard產生索引。這個首碼可以是任意的（不要是shard的名稱），但必須始終如一這樣solr效能才穩定。例如，你想要給客戶同步資料，你可以使用客戶名或ID作為首碼。例如，如果你的客戶是IBM，document的ID是“12345”，你最好在document的id值中加入首碼：“IBM!12345”。“!”是一個邊界，區分首碼用來決定哪個shard來管理這個document。

那麼在查詢的時候，在你的查詢語句中通過_route_參數（也就是，q=solr&_route_=IBM!）加入首碼來管理查詢到指定的shard。在某些情況下，這樣做會增強查詢的效能，因為從所有shard查詢時網路的潛在因素。

提示：_route_參數代替shard.keys，shard.keys在Solr以後發布的版本中棄用。

這個compositeId支援2級首碼。例如：第一個是地區首碼，然後是客戶首碼：“USA!IBM!12345”

另一種使用情境是如果IBM這個客戶有大量的文檔，你想要分布他們到多個shard中去。這種用法的文法是：“shard_key/num!document_id”，這個num就是在複合hash使用shrad的key的bit的數量。

因此“IBM/3!12345”將會在shard key中佔用3bit，在唯一的doc id中佔29bit，在collection中傳播租戶超過shard的1/8。例如num值為2就會跨1/4的shard傳播該document。在查詢的時候，直接到指定的shard中用_route_參數查詢，將bit的num一起包含在首碼中（也就是q=solr&_route_=IBM/3!）。

如果你不想影響document如何儲存，就不用在document ID中指定首碼。

如果你建立了一個collection而且定義在建立的時候定義了“implicit”route，你可以添加定義一個router.field參數，通過各個document的這個field來確定document屬於哪個shard。如果在document中丟失這個field指定，document將會被拒絕。你同樣可以使用_route_參數來命名一個指定的shard。

Shard Splitting

當你在SolrCloud中建立一個collection，你要決定shard的初始化個數。但是很難提前知道你所需要的shard個數，特別是當組織需求發生改變，這成本會很高當事後發現你的選擇是錯誤的，涉及建立新的core而且重建所有資料的索引。

Collection API提供拆分shard的能力。目前允許拆分一個shard為兩片。現有的shard保持不變，所以拆分操作實際上將兩個切片的資料作為兩個新的shard。當你準備好了易後你可以刪除老的shard。

更多關於拆分shard的內容在Collection API這一章節。https://cwiki.apache.org/confluence/display/solr/Collections+API

Ignoring Commits fromClient Application in SolrCloud

多數情況下我們在SolrCloud模式下運行，用戶端應用不能直接發送提交索引資料的請求。當然，你可以通過配置openSearcher=false和soft-commits自動認可使最新動向在搜尋請求中顯示。這可以確保schedule叢集中的提交定期發生。確保用戶端應用不會發送直接提交的方案，你可以更新所有用戶端應用的solr索引資料到SolrCloud中。然而這種方法並不是一直都可行，因此solr提供IgnoreCommitOptimizeUpdateProcessorFactory，可以允許你不用重構用戶端應用的代碼來忽略來自用戶端應用的直接提交或者最佳化的請求。想要啟用這個要求處理常式，你需要在solrconfig.xml中添加一下配置：

<updateRequestProcessorChainname="ignore-commit-from-client" default="true">

  <processorclass="solr.IgnoreCommitOptimizeUpdateProcessorFactory">

    <intname="statusCode">200</int>

  </processor>

  <processorclass="solr.LogUpdateProcessorFactory" />

  <processorclass="solr.DistributedUpdateProcessorFactory" />

  <processorclass="solr.RunUpdateProcessorFactory" />

</updateRequestProcessorChain>

在上面的例子中，處理器會返回給用戶端200但是會忽略commit/optimize請求。注意你的SolrCloud同樣需要接入隱式的處理器，因為這個定製的chain會覆蓋預設的chain。

在下面的這個例子當中，處理器會返回一個403 code異常的定製的錯誤資訊：

<updateRequestProcessorChainname="ignore-commit-from-client" default="true">

  <processorclass="solr.IgnoreCommitOptimizeUpdateProcessorFactory">

    <intname="statusCode">403</int>

    <str name="responseMessage">Thoushall not issue a commit!</str>

  </processor>

  <processor class="solr.LogUpdateProcessorFactory"/>

  <processorclass="solr.DistributedUpdateProcessorFactory" />

  <processorclass="solr.RunUpdateProcessorFactory" />

</updateRequestProcessorChain>

最後，你可以通過以下配置來忽略最佳化使提交通過：

<updateRequestProcessorChain name="ignore-optimize-only-from-client-403">

  <processorclass="solr.IgnoreCommitOptimizeUpdateProcessorFactory">

    <str name="responseMessage">Thoushall not issue an optimize, but commits are OK!</str>

    <boolname="ignoreOptimizeOnly">true</bool>

  </processor>

  <processorclass="solr.RunUpdateProcessorFactory" />

</updateRequestProcessorChain>

Distributed RequestsLimiting Which Shardsare Queried

SolrCloud的一大優點就是可以在各個包含或不包含你要找的資料的shrad間進行分散式查詢。你可以選取查詢全部的資料或者只是部分資料。

從所有shard查詢collection看起來很熟悉，好像SolrCloud甚至沒有發揮作用：

http://localhost:8983/solr/gettingstarted/select?q=*:*

你只想從一個shard查詢，你可以指定通過那個shard的邏輯ID來指定shard：

http://localhost:8983/solr/gettingstarted/select?q=*:*&shards=shard1

如果你想查詢一組shard ids，你可以同時指定他們：

http://localhost:8983/solr/gettingstarted/select?q=*:*&shards=shard1,shard2

上面的兩個例子，shard Ids會隨機選取相應shard下的replica。

以下兩者任選其一，你可以明確的指定shard中你希望使用的replica：

http://localhost:8983/solr/gettingstarted/select?q=*:*&shards=localhost:7574/solr/gettingstarted,localhost:8983/solr/gettingstarted

或者，你可以從一個單獨的shard中指定一個replica的集合通過使用符號“|”（為了達到負載平衡的目的）：

http://localhost:8983/solr/gettingstarted/select?q=*:*&shards=localhost:7574/solr/gettingstarted|localhost:7500/solr/gettingstarted

當然，你可以通過“，”來指定一個shard集合，集合中成員又可以是通過“|”來指定的多個shard。例如這個例子當中需要2個shard，第一個是從shard1從隨機選取的replica，第二個是通過“|”明確劃分的集合：

http://localhost:8983/solr/gettingstarted/select?q=*:*&shards=shard1,localhost:7574/solr/gettingstarted|localhost:7500/solr/gettingstarted

Configuring theShardHandlerFactory

在Solr分布式搜尋應用方面你可以直接配置並發和線程池。這允許更細粒度的控制，你可以根據你紫的具體要求來調整他的目標。預設的配置有利於延遲的輸送量。

可以在solrconfig.xml中來配置標準的處理常式：

<requestHandler name="standard" class="solr.SearchHandler" default="true">

  <!-- other params go here -->

  <shardHandler class="HttpShardHandlerFactory">

    <int name="socketTimeOut">1000</int>

    <int name="connTimeOut">5000</int>

  </shardHandler>

</requestHandler>

Configuring statsCache(Distributed IDF)

為了計算關聯度，需要文檔和長期統計。Solr提供四種模式來進行文檔的統計計算：

LocalStatsCache: 這隻使用本地術語和文檔統計來計算相關性。為了從各個shard統一分布的術語，這種配置的效果很好。

如果沒有配置<statsCache>，預設為這項。

ExactStatsCache: 此實現使用全域值（跨collection）為文檔頻率。

ExactSharedStatsCache: 功能與ExactStatsCache很像，但在同一條件下，對於後續的請求來說，全域資料是可重用的。

LRUStatsCache:通過LRU緩衝全域統計，在請求之間共用。

通過在solrconfig.xml中配置<statsCache>來實現。例如下面這行Solr使用ExactStatsCache實現：

<statsCache class="org.apache.solr.search.stats.ExactStatsCache"/>

Avoiding DistributedDeadlock

每個片段是頂級的查詢請求進行子要求其他所有的片段。應注意確保服務的HTTP請求的線程的最大數量是大於從頂級客戶和其他片段的請求的數量。如果不是這種情況，則配置可能會導致分布式死結。

例如，死結可能在兩個片段的情況下發生的，每一個與只是一個單一的線程服務的HTTP請求。兩個線程可以同時接收一個頂層請求，並將請求分為彼此。因為沒有更多的剩餘的線程來服務要求，傳入請求將被阻塞，直到其他的等待請求被完成，但他們不會完成，因為他們等待的子請求。通過確保Solr配置足夠數量的線程來處理，就可以避免死結，這樣。

Prefer Local Shards

Solr允許你通過一個可選的布爾型參數命名preferLocalShards表明分散式查詢，當一個本地shard可用時，傾向於這個shard的replica。換句話說，如果查詢包括preferLocalShards= true，然後查詢控制器將本地replica執行查詢而不是選擇隨機從整個叢集的查詢服務。這是有用的，當一個查詢請求多個欄位或大的欄位被返回，因為它避免了在網路上移動大量的資料時，它是在本地。此外，此功能可以是有用的，用於最大限度地減少的影響的問題的副本與退化的效能，因為它降低的可能性，退化的副本將被擊中的其他健康的副本。

最後，它表明這一特徵的價值減少集合中增加shard數因為查詢控制器將直接查詢到大部分的非本地replica的shard。換句話說，這一特徵對與一個小數量的shard和許多replica集合的查詢最佳化是非常有用的。另外，如果你要求從collection所有nodes的replica中進行負載平衡的查詢只能用這個選項，如Solr的CloudSolrClient會做。如果不Server Load Balancer，這個功能可以在叢集中引入一個熱點，因為查詢將不均勻分布在整個叢集中。

https://cwiki.apache.org/confluence/display/solr/SolrCloud

http://wiki.apache.org/solr/FrontPage

未完待續...

SolrCloud:根據Solr Wiki的譯文