SolrCloud集羣Collection進行手動二次Sharding--solr分片相關

SolrCloud集羣Collection進行手動二次Sharding

http://blog.csdn.net/shirdrn/article/details/9770829

 

一致性hash和solr千萬級數據分佈式搜索引擎中的應用

http://www.lanceyan.com/tech/arch/consistenthashing_and_solr.html

 SolrCloud中的文件與Collection管理

http://www.codeweblog.com/solrcloud中的文件與collection管理/ 

solrCloud路由

SolrCloud路由

SolrCloud中，提供了兩種路由算法：

compositeIdimplicit 在建立Collection時，須要經過router.name指定路由策略，默認爲compositeId路由。

compositeId

該路由爲一致性哈希路由，shards的哈希範圍從80000000~7fffffff。初始建立collection是必須指定numShards，compositeId路由算法根據numShards的個數，計算出每一個shard的哈希範圍，所以路由策略不能夠擴展shard。

implicit

該路由方式指定索引具體落在路由到哪一個Shard，這與compositeId路由方式索引可均勻分佈在每一個shard上不一樣。同時只有在implicit路由策略下才可建立shard。

利用solrJ新建索引時，須要在代碼中指定索引具體落在哪一個shard上，添加代碼：

doc.addField("_route_", "shard_X");

同時在schema.xml添加字段

<field name="_route_" type="string"/>

利用URL建立implicit路由方式collection：

http://10.21.17.200:9580/solr-5.0.0-web/admin/collections?action=CREATE&name=testimplicit&router.name=implicit&shards=shard1,shard2,shard3

SolrRouter源碼

在Solr源碼中，能夠看到，Solr路由的基類爲DocRouter抽象類，HashBasedRouter和ImplicitDouter繼承自DocRouter，同時CompositeIdRouter又繼承HashBasedRouter抽象類，經過一個工具Hash類實現Document的路由策略。

建立Collection

Solr建立Collection的兩種方式：

經過前臺界面Add Core建立collection

因爲在tomcat，setenv.sh，設置-DnumShards=7，因此該collection有7個shards。

須要注意的是：使用compositeId路由建立collection，指定numShards後，不可擴展Shard，即便勉強增長Shard，新建索引也不會落在該Shard上。查看clusterstate.json，可看到新建shard的"range":null

URL建立collection
經過URL建立collection須要知足條件：num of (shards + replications)< num of live nodes

 

測試環境中3臺solr機器，建立collection URL爲：

http://10.21.17.200:9580/solr-4.10.0/admin/collections?action=CREATE&name=collection1&router.name=compositeId&numShards=5&replicationFactor=1

執行結果報錯

<str name="Operation createcollection caused exception:">

org.apache.solr.common.SolrException:org.apache.solr.common.SolrException:Cannot create collection collection1. Value of maxShardsPerNode is 1, and thenumber of live nodes is 3. This allows a maximum of 3 to be created. Value ofnumShards is 5 and value of replicationFactor is 1. This requires 5 shards tobe created (higher than the allowed number)

</str>

報錯緣由不知足 5 + 1 < 3

數據遷移

在某些場景中，須要對SolrCloud進行擴容或數據遷移。

根據以上討論的兩種路由算法，implicit實現該需求比較簡單，只要建立Shard便可，新建索引時，將索引建到新建Shard上，查詢操做，指定collection名稱，獲得的還是整個集羣返回的結果。

compositeId路由實現上述需求稍微麻煩一下，經過分裂（SPLITSHARD）操做實現。以下圖，對Shard1進行分裂，分裂URL爲：

http://10.21.17.200:9580/solr-4.10.0-web/admin/collections?action=SPLITSHARD&collection=log4j201503&shard=shard1此時Shard1的數據會平均分佈到shard1_0和shard1_1上，在利用DELETESHARD API刪除Shard1，便可保證數據不冗餘

 

關於SolrCloud的索引分片和查詢的可加強點 

Solr4.0包含了分佈式的sorl解決方案solrCloud，能夠作sharding切分，每一個sharding中節點支持選舉算法（leader,replica），在sharding裏面支持query的負載均衡。
在集羣啓動時，就須要聲明當shard、collection等信息，啓動過程當中把集羣的狀態信息維護在zookeeper節點裏。
集羣中的任何一臺server均可以響應客戶端的請求，包括索引操做和查詢操做。

對於索引操做，solrCloud提供了簡單的分片算法，即根據當前的索引記錄的ID值作hash操做，後根據zookeeper中維護的集羣的相關狀態（Collection,RangeInfo,Range<min,max>）去查找hash值在哪一個Range中，找到對應的shard；在該shard中 leader 中創建索引，Leader節點更新結束完成，最後將版本號和文檔轉發給同屬於一個Shard的replicas節點。不過在創建索引時，shard的算法沒有考慮到負載均衡，有可能往一個shard中一直插入，因此須要本身考慮進行shard的切分負載均衡。