01 片鍵

    MongoDB的片鍵決定了集合中存儲(chǔ)的數(shù)據(jù)在集合中的分布情況，具體的方法是使用片鍵值的范圍來(lái)對(duì)集合中的數(shù)據(jù)進(jìn)行分區(qū)。舉個(gè)例子：

假如我們以年齡age來(lái)作為片鍵，那么age的范圍理論上是0~80，此時(shí)，MongoDB會(huì)為我們定義age的四個(gè)范圍區(qū)間，他們分別是：0~20,20~40,40~60，60~80，每個(gè)范圍都是一個(gè)chunk，這樣我們寫(xiě)入數(shù)據(jù)之后，數(shù)據(jù)里面的數(shù)據(jù)塊就有：

chunk1:  age  0~20

chunk2:  age  20~40   

chunk3：age  40~60

chunk4：age  60~80

需要注意的是，在一個(gè)集合中，被選為片鍵的這個(gè)字段上必須有一個(gè)支持片鍵的索引，或者是必須有一個(gè)以這個(gè)字段開(kāi)頭的聯(lián)合索引。

通常情況下，我們給字段添加的索引，最常見(jiàn)的是普通索引或者哈希索引，

普通的索引字段如果作為片鍵，那么這個(gè)片鍵我們稱(chēng)為范圍片鍵；

哈希索引字段如果作為片鍵，那么這個(gè)片鍵我們稱(chēng)為哈希片鍵。

下面我們來(lái)看二者的不同之處：

02 范圍片鍵(遞增片鍵)

范圍片鍵，顧名思義，就是將數(shù)據(jù)根據(jù)片鍵劃分到連續(xù)的范圍里面，在這個(gè)模型中，那些值”相似”的文檔可能位于同一個(gè)片中。例如下面這樣：

這中分片方式是MongoDB默認(rèn)的分片方式，它有好處也有壞處。

好處：

    可以高效的讀取連續(xù)范圍內(nèi)的目標(biāo)文檔。如果你使用范圍查詢，則可以比較快速的拿到所有的結(jié)果值。因?yàn)閿?shù)據(jù)所在的數(shù)據(jù)chunk比較少。

壞處：

    如果我們寫(xiě)入的數(shù)據(jù)都幾種在某一個(gè)分片區(qū)間，那么讀寫(xiě)性能都可能因?yàn)槠I劃分不均勻而降低。(例如下圖中，數(shù)據(jù)的基數(shù)大部分在20~maxKey，則大部分都在chunk C的位置，本身分布不均勻),Chunk C的寫(xiě)入壓力將會(huì)增大。

在下列場(chǎng)景中，使用范圍片鍵比較合適：

1、數(shù)據(jù)的基數(shù)比較大

2、分片的寫(xiě)入頻率比較低(插入較少不容易產(chǎn)生chunk的搬運(yùn))

3、非單調(diào)變化的分片(如果單調(diào)寫(xiě)，則會(huì)分到同一個(gè)塊里面，容易達(dá)到chunk割裂的條件，產(chǎn)生chunk的搬運(yùn))

如果數(shù)據(jù)滿足上面的三個(gè)條件，則我們寫(xiě)入的數(shù)據(jù)可能是這樣的：

就是比較均勻的寫(xiě)入到了數(shù)據(jù)塊中。

03 哈希片鍵

    哈希片鍵使用哈希索引在共享集群中對(duì)數(shù)據(jù)進(jìn)行分區(qū)。哈希索引計(jì)算單個(gè)字段的哈希值作為索引值，該值用作片鍵(注意，這里并不是字段本身的值，而是hash之后的值)。

    使用哈希索引，我們寫(xiě)入數(shù)據(jù)之后，對(duì)應(yīng)寫(xiě)入數(shù)據(jù)塊的圖示可能如下：

從圖中我們看出來(lái)，雖然我們輸入的x值比較接近，分別是25、26、27，但是，經(jīng)過(guò)hash函數(shù)之后，他們所在的數(shù)據(jù)塊序號(hào)可能差距很遠(yuǎn)。

哈希分片在分片集群中提供了更均勻的數(shù)據(jù)分布，集合中那些具有近似值的文檔，可能會(huì)被分到不同的塊上，mongos更有可能執(zhí)行廣播操作來(lái)完成給定的范圍查詢。

哈希值得計(jì)算，是由MongoDB來(lái)負(fù)責(zé)的，不是應(yīng)用程序負(fù)責(zé)的

作為哈希片鍵的索引字段應(yīng)該有如下特點(diǎn)：

1、具有大量不同的值

2、哈希索引適合單調(diào)變化的字段，例如自增值，時(shí)間值等(因?yàn)榭梢詫握{(diào)的字段通過(guò)hash函數(shù)映射到不同的塊上去，從而分散寫(xiě)入壓力，例如下圖，雖然數(shù)據(jù)連續(xù)，但是寫(xiě)入了不同的數(shù)據(jù)塊中)

它的缺點(diǎn)也比較明顯，當(dāng)我們查詢某個(gè)范圍的值的時(shí)候，hash索引會(huì)查找更多的數(shù)據(jù)分片，并將最終的結(jié)果匯總起來(lái)交給我們。

在實(shí)際生產(chǎn)環(huán)境中，我們需要結(jié)合自己的需求來(lái)確定使用哪種類(lèi)型的片鍵，再次強(qiáng)調(diào)，在設(shè)定某個(gè)字段作為片鍵之前，需要先在當(dāng)前字段創(chuàng)建對(duì)應(yīng)類(lèi)型的索引，或者創(chuàng)建一個(gè)以當(dāng)前字段開(kāi)頭的聯(lián)合索引。否則設(shè)定片鍵的語(yǔ)句會(huì)報(bào)錯(cuò)。

下面是分片創(chuàng)建從無(wú)到有的過(guò)程舉例：

1、創(chuàng)建表，只有一個(gè)字段name，并插入數(shù)據(jù)
mongos> use aaa
switched to db aaa
mongos> db.aaa.insert({name:1})
WriteResult({ “nInserted” : 1 })
mongos> db.aaa.insert({name:2})
WriteResult({ “nInserted” : 1 })
mongos> db.aaa.insert({name:3})
WriteResult({ “nInserted” : 1 })
mongos> db.aaa.insert({name:4})
WriteResult({ “nInserted” : 1 })
mongos>

2、查看數(shù)據(jù)
mongos> db.aaa.find()
{ “_id” : ObjectId(“5fdb7d54d91f2f9bae3b09a1”), “name” : 1 }
{ “_id” : ObjectId(“5fdb7d56d91f2f9bae3b09a2”), “name” : 2 }
{ “_id” : ObjectId(“5fdb7d59d91f2f9bae3b09a3”), “name” : 3 }
{ “_id” : ObjectId(“5fdb7d5cd91f2f9bae3b09a4”), “name” : 4 }

3、允許數(shù)據(jù)庫(kù)分片
mongos> sh.enableSharding(“aaa”)
{
“ok” : 1,
“operationTime” : Timestamp(1608220038, 3),
“$clusterTime” : {
“clusterTime” : Timestamp(1608220038, 3),
“signature” : {
“hash” : BinData(0,”shemm3xvSYrMiy9t7gSYcVtFUuE=”),
“keyId” : NumberLong(“6894922308364795934″)
}
}
}
mongos>

4、在name字段創(chuàng)建hash索引
mongos> db.aaa.createIndex({name:”hashed”},{background:true})
{
“raw” : {
“sharding_yeyz/127.0.0.1:27018,127.0.0.1:27019,127.0.0.1:27020” : {
“createdCollectionAutomatically” : false,
“numIndexesBefore” : 1,
“numIndexesAfter” : 2,
“ok” : 1
}
},
“ok” : 1,
“operationTime” : Timestamp(1608220115, 3),
“$clusterTime” : {
“clusterTime” : Timestamp(1608220115, 3),
“signature” : {
“hash” : BinData(0,”S3Wz9G26eJyOcwa1OLS6TVYu6SE=”),
“keyId” : NumberLong(“6894922308364795934”)
}
}
}

5、以name字段作為片鍵創(chuàng)建哈希分片
mongos> sh.shardCollection(“aaa.aaa”,{name:”hashed”})
{
“collectionsharded” : “aaa.aaa”,
“collectionUUID” : UUID(“20a3895e-d821-43ae-9d28-305e6ae03bbc”),
“ok” : 1,
“operationTime” : Timestamp(1608220238, 10),
“$clusterTime” : {
“clusterTime” : Timestamp(1608220238, 10),
“signature” : {
“hash” : BinData(0,”qeQlD3jsSvRZkyamEa2hjbezEdM=”),
“keyId” : NumberLong(“6894922308364795934”)
}
}
}

6、查看分片信息
mongos> db.printShardingStatus()
— Sharding Status —
sharding version: {
“_id” : 1,
“minCompatibleVersion” : 5,
“currentVersion” : 6,
“clusterId” : ObjectId(“5fafaf4f5785d9965548f687”)
}
shards:
{ “_id” : “sharding_yeyz”, “host” : “sharding_yeyz/127.0.0.1:27018,127.0.0.1:27019,127.0.0.1:27020”, “state” : 1 }
{ “_id” : “sharding_yeyz1”, “host” : “sharding_yeyz1/127.0.0.1:27024,127.0.0.1:27025,127.0.0.1:27026”, “state” : 1 }
active mongoses:
“4.0.6” : 1
autosplit:
Currently enabled: yes
balancer:
Currently enabled: yes
Currently running: no
Failed balancer rounds in last 5 attempts: 2
Last reported error: Could not find host matching read preference { mode: “primary” } for set sharding_yeyz
Time of Reported error: Wed Nov 18 2020 17:08:14 GMT+0800 (CST)
Migration Results for the last 24 hours:
No recent migrations
databases:
{ “_id” : “aaa”, “primary” : “sharding_yeyz”, “partitioned” : true, “version” : { “uuid” : UUID(“26e55931-d1c1-4dc5-8a03-b5b0e70f6f43”), “lastMod” : 1 } }
aaa.aaa
shard key: { “name” : “hashed” }
unique: false
balancing: true
chunks:
sharding_yeyz 1
{ “name” : { “$minKey” : 1 } } –>> { “name” : { “$maxKey” : 1 } } on : sharding_yeyz Timestamp(1, 0)