（一）分片方式
MongoDB提供了基於哈希(hashed)和基於范圍(Range)2種分片方式：
（1.1）哈希分片
哈希分片使用hash索引來在分片集群中對數據進行划分。哈希索引計算某一個字段的哈希值作為索引值，這個值被用作片鍵。
哈希分片以減少定向操作和增加廣播操作為代價。分片集群內的數據更加均衡。
從MongoDB4.0開始，mongo shell提供了convertShardKeyToHashed()方法，用於查看鍵的hash值。
選擇作為hash分片鍵的字段應該有良好的基數或者該字段包含大量不同的值，hash分片非常適合選取具有像objectId或時間戳那樣單調更改的字段作為片鍵。
使用sh.shardCollection()方法，來對集合進行hash分片
sh.shardCollection("database.collection",{<field> : "hashed" } )
（1.2）范圍分片
基於范圍的分片會將數據划分為由片鍵值確定的連續范圍。在范圍分片模型中，具有“接近”片鍵的文檔可能位於相同的chunk或者shard中，連續范圍讀取文檔將變得高效，但是如果片鍵選擇不佳，則讀取和寫入的想你將會降低。
如果未選擇其它選項(如hash分片或者zone),則基於范圍的分片是默認的分片方式。
范圍分片片鍵的選擇：
- 基數大
- 頻率低
- 非單調變化
使用sh.shardCollection()方法，來對集合進行范圍分片，可以選擇單字段或者多字段
sh.shardCollection("database.collection",{<shard key>})
（二）片鍵選擇因素
分片鍵決定了集合內的文檔如何在集群的多個分片上分布數據，分片鍵要么是一個索引字段，要么是一個存在於集合所有文檔中的符合索引字段。MongoDB嘗試在集群中的各個分片之間平均分配數據塊(chunk)，特別注意，shard之間平均分配的數據塊(chunk)，而不是數據量，分片鍵的選擇直接關系到分片結果的好壞。
NOTE：
在MongoDB4.2之前，文檔的分片字段是不可以修改的。從4.2版本開始，除非分片鍵是不可變的_id字段，否則你可以更新文檔的分片字段。
所有需要分片的集合都必須具有支持分片的索引，即分片鍵上必須有索引，可以使分片鍵的索引，也可以是符合索引，對於符合索引，分片鍵必須是索引的前綴。
- 如果集合為空，則sh.shardCollection()在分片鍵上自動創建索引，無需認為干預
- 如果集合存在數據，則必須先創建索引，然后再使用sh.shardCollection()來為集合分片。
分片鍵的選擇需要綜合考慮分片鍵的基數、頻率和變化率。
- 基數。分片鍵的基數決定了分片集群可以創建的最大chunk的數目。在任何給定的時間，唯一的分片值只能存在一個chunk上。例如：使用性別進行分片，則只能分為“男”和“女”2個chunk，不能隨着數據增多而分裂為更多的chunk，因為一個分片值只能存儲在同一個chunk中。
- 頻率。頻率代表給定值在該列中出現的比率，與關系型數據庫中select distinct ...異曲同工。如果大多數文檔包含了這些值的子集，那么存儲這些文檔的chunk將成為集群中的瓶頸，隨着數據的增長，他們將會成為不可分割的數據塊，降低了集群水平擴展的有效性。例如：集合people用來統計各個名族的人信息，使用名族作為分片字段，那么根據我國56個名族的人數分布，占據人口總數92%的漢族將占據一個chunk，這樣會導致該chunk非常巨大，失去了分片的意義。
- 變化率。單調遞增或單調遞減的分片鍵可能將數據寫到集群中的單個分片上。如果分片鍵值始終在增加，則所有新插入都將路由到以maxKey為上限的塊。 如果分片鍵值始終在減小，則所有新插入都將路由到以minKey為下限的塊。 包含該塊的分片將成為寫操作的瓶頸。
【完】