## 為什么需要Sharded cluster？ MongoDB目前3大核心優勢：『靈活模式』+ 『高可用性』 + 『可擴展性』，通過json文檔來實現靈活模式，通過[復制集](https://yq.aliyun.com/articles/64?spm=0.0.0.0.9jrPm8)來保證高可用，通過Sharded cluster來保證可擴展性。 當MongoDB復制集遇到下面的業務場景時，你就需要考慮使用Sharded cluster * 存儲容量需求超出單機磁盤容量 * 活躍的數據集超出單機內存容量，導致很多請求都要從磁盤讀取數據，影響性能 * 寫IOPS超出單個MongoDB節點的寫服務能力  如上圖所示，Sharding Cluster使得集合的數據可以分散到多個Shard（復制集或者單個Mongod節點）存儲，使得MongoDB具備了橫向擴展（Scale out）的能力，豐富了MongoDB的應用場景。 ## Sharded cluster架構 Sharded cluster由Shard、Mongos和Config server 3個組件構成。  Mongos是Sharded cluster的訪問入口，強烈建議所有的管理操作、讀寫操作都通過mongos來完成，以保證cluster多個組件處于一致的狀態。 Mongos本身并不持久化數據，Sharded cluster所有的元數據都會存儲到Config Server（下一節詳細介紹），而用戶的數據則會分散存儲到各個shard。Mongos啟動后，會從config server加載元數據，開始提供服務，將用戶的請求正確路由到對應的Shard。 ## 數據分布策略 Sharded cluster支持將單個集合的數據分散存儲在多個shard上，用戶可以指定根據集合內文檔的某個字段即shard key來分布數據，目前主要支持2種數據分布的策略，范圍分片（Range based sharding）或hash分片（Hash based sharding）。 ### 范圍分片  如上圖所示，集合根據x字段來分片，x的取值范圍為[minKey, maxKey]（x為整型，這里的minKey、maxKey為整型的最小值和最大值），將整個取值范圍劃分為多個chunk，每個chunk（通常配置為64MB）包含其中一小段的數據。 Chunk1包含x的取值在[minKey, -75)的所有文檔，而Chunk2包含x取值在[-75, 25)之間的所有文檔… 每個chunk的數據都存儲在同一個Shard上，每個Shard可以存儲很多個chunk，chunk存儲在哪個shard的信息會存儲在Config server種，mongos也會根據各個shard上的chunk的數量來自動做負載均衡。 范圍分片能很好的滿足『范圍查詢』的需求，比如想查詢x的值在[-30, 10]之間的所有文檔，這時mongos直接能將請求路由到Chunk2，就能查詢出所有符合條件的文檔。 范圍分片的缺點在于，如果shardkey有明顯遞增（或者遞減）趨勢，則新插入的文檔多會分布到同一個chunk，無法擴展寫的能力，比如使用_id作為shard key，而MongoDB自動生成的id高位是時間戳，是持續遞增的。 ### Hash分片 Hash分片是根據用戶的shard key計算hash值（64bit整型），根據hash值按照『范圍分片』的策略將文檔分布到不同的chunk。  Hash分片與范圍分片互補，能將文檔隨機的分散到各個chunk，充分的擴展寫能力，彌補了范圍分片的不足，但不能高效的服務范圍查詢，所有的范圍查詢要分發到后端所有的Shard才能找出滿足條件的文檔。 ### 合理的選擇shard key 選擇shard key時，要根據業務的需求及『范圍分片』和『Hash分片』2種方式的優缺點合理選擇，同時還要注意shard key的取值一定要足夠多，否則會出現單個jumbo chunk，即單個chunk非常大并且無法分裂（split）；比如某集合存儲用戶的信息，按照age字段分片，而age的取值非常有限，必定會導致單個chunk非常大。 ## Mongos Mongos作為Sharded cluster的訪問入口，所有的請求都由mongos來路由、分發、合并，這些動作對客戶端driver透明，用戶連接mongos就像連接mongod一樣使用。 Mongos會根據請求類型及shard key將請求路由到對應的Shard ### 查詢請求 * 查詢請求不包含shard key，則必須將查詢分發到所有的shard，然后合并查詢結果返回給客戶端 * 查詢請求包含shard key，則直接根據shard key計算出需要查詢的chunk，向對應的shard發送查詢請求 ### 寫請求 寫操作必須包含shard key，mongos根據shard key算出文檔應該存儲到哪個chunk，然后將寫請求發送到chunk所在的shard。 ### 更新/刪除請求 更新、刪除請求的查詢條件必須包含shard key或者_id，如果是包含shard key，則直接路由到指定的chunk，如果只包含_id，則需將請求發送至所有的shard。 ### 其他命令請求 除增刪改查外的其他命令請求處理方式都不盡相同，有各自的處理邏輯，比如listDatabases命令，會向每個Shard及Config Server轉發listDatabases請求，然后將結果進行合并。 ## Config Server ### config database Config server存儲Sharded cluster的所有元數據，所有的元數據都存儲在config數據庫，3.2版本后，Config Server可部署為一個獨立的復制集，極大的方便了Sharded cluster的運維管理。 ~~~ mongos> use config switched to db config mongos> db.getCollectionNames() [ "shards", "actionlog", "chunks", "mongos", "collections", "lockpings", "settings", "version", "locks", "databases", "tags", "changelog" ] ~~~ ### config.shards config.shards集合存儲各個Shard的信息，可通過addShard、removeShard命令來動態的從Sharded cluster里增加或移除shard。如下所示，cluster目前擁有2個shard，均為復制集。 ~~~ mongos> db.addShard("mongo-9003/10.1.72.135:9003,10.1.72.136:9003,10.1.72.137:9003") mongos> db.addShard("mongo-9003/10.1.72.135:9003,10.1.72.136:9003,10.1.72.137:9003") mongos> db.shards.find() { "_id" : "mongo-9003", "host" : "mongo-9003/10.1.72.135:9003,10.1.72.136:9003,10.1.72.137:9003" } { "_id" : "mongo-9004", "host" : "mongo-9004/10.1.72.135:9004,10.1.72.136:9004,10.1.72.137:9004" } ~~~ ### config.databases config.databases集合存儲所有數據庫的信息，包括DB是否開啟分片，[primary shard](https://docs.mongodb.org/manual/core/sharded-cluster-shards/)信息，對于數據庫內沒有開啟分片的集合，所有的數據都會存儲在數據庫的primary shard上。 如下所示，shtest數據庫是開啟分片的（通過[enableSharding命令](https://docs.mongodb.org/manual/reference/method/sh.enableSharding/)），primary shard為mongo-9003； 而test數據庫沒有開啟分片，primary shard為mongo-9003。 ~~~ mongos> sh.enableSharding("shtest") { "ok" : 1 } mongos> db.databases.find() { "_id" : "shtest", "primary" : "mongo-9003", "partitioned" : true } { "_id" : "test", "primary" : "mongo-9003", "partitioned" : false } ~~~ Sharded cluster在數據庫創建時，為用戶選擇當前存儲數據量最小的shard作為數據庫的primary shard，用戶也可調用[movePrimary命令](https://docs.mongodb.org/manual/reference/command/movePrimary/)來改變primary shard以實現負載均衡，一旦primary shard發生改變，mongos會自動將數據遷移到的新的primary shard上。 ### config.colletions 數據分片是針對集合維度的，某個數據庫開啟分片功能后，如果需要讓其中的集合分片存儲，則需調用[shardCollection](https://docs.mongodb.org/manual/reference/command/shardCollection/)命令來針對集合開啟分片。 如下命令，針對shtest數據里的hello集合開啟分片，使用x字段作為shard key來進行范圍分片。 ~~~ mongos> sh.shardCollection("shtest.coll", {x: 1}) { "collectionsharded" : "shtest.coll", "ok" : 1 } mongos> db.collections.find() { "_id" : "shtest.coll", "lastmodEpoch" : ObjectId("57175142c34046c3b556d302"), "lastmod" : ISODate("1970-02-19T17:02:47.296Z"), "dropped" : false, "key" : { "x" : 1 }, "unique" : false } ~~~ ### config.chunks 集合分片開啟后，默認會創建一個新的chunk，shard key取值[minKey, maxKey]內的文檔（即所有的文檔）都會存儲到這個chunk。當使用Hash分片策略時，可以預先創建多個chunk，以減少chunk的遷移。 ~~~ mongos> db.chunks.find({ns: "shtest.coll"}) { "_id" : "shtest.coll-x_MinKey", "ns" : "shtest.coll", "min" : { "x" : { "$minKey" : 1 } }, "max" : { "x" : { "$maxKey" : 1 } }, "shard" : "mongo-9003", "lastmod" : Timestamp(1, 0), "lastmodEpoch" : ObjectId("5717530fc34046c3b556d361") } ~~~ 當chunk里寫入的數據量增加到一定閾值時，會觸發chunk分裂，將一個chunk的范圍分裂為多個chunk，當各個shard上chunk數量不均衡時，會觸發chunk在shard間的遷移。如下所示，shtest.coll的一個chunk，在寫入數據后分裂成3個chunk。 ~~~ mongos> use shtest mongos> for (var i = 0; i < 10000; i++) { db.coll.insert( {x: i} ); } mongos> use config mongos> db.chunks.find({ns: "shtest.coll"}) { "_id" : "shtest.coll-x_MinKey", "lastmod" : Timestamp(5, 1), "lastmodEpoch" : ObjectId("5703a512a7f97d0799416e2b"), "ns" : "shtest.coll", "min" : { "x" : { "$minKey" : 1 } }, "max" : { "x" : 1 }, "shard" : "mongo-9003" } { "_id" : "shtest.coll-x_1.0", "lastmod" : Timestamp(4, 0), "lastmodEpoch" : ObjectId("5703a512a7f97d0799416e2b"), "ns" : "shtest.coll", "min" : { "x" : 1 }, "max" : { "x" : 31 }, "shard" : "mongo-9003" } { "_id" : "shtest.coll-x_31.0", "lastmod" : Timestamp(5, 0), "lastmodEpoch" : ObjectId("5703a512a7f97d0799416e2b"), "ns" : "shtest.coll", "min" : { "x" : 31 }, "max" : { "x" : { "$maxKey" : 1 } }, "shard" : "mongo-9004" } ~~~ ### config.settings config.settings集合里主要存儲sharded cluster的配置信息，比如chunk size，是否開啟balancer等 ~~~ mongos> db.settings.find() { "_id" : "chunksize", "value" : NumberLong(64) } { "_id" : "balancer", "stopped" : false } ~~~ ### 其他集合 * config.tags主要存儲sharding cluster標簽（tag）相關的你洗，以實現[根據tag來分布chunk的功能](https://docs.mongodb.org/manual/tutorial/administer-shard-tags/)； * config.changelog主要存儲sharding cluster里的所有變更操作，比如balancer遷移chunk的動作就會記錄到changelog里； * config.mongos存儲當前集群所有mongos的信息； * config.locks存儲鎖相關的信息，對某個集合進行操作時，比如moveChunk，需要先獲取鎖，避免多個mongos同時遷移同一個集合的chunk。 ## 參考資料 * [MongoDB復制集架構原理](https://yq.aliyun.com/articles/64?spm=0.0.0.0.9jrPm8) * [MongoDB Sharding簡介](https://docs.mongodb.org/manual/core/sharding-introduction/) * [primary shard](https://docs.mongodb.org/manual/core/sharded-cluster-shards/) * [enableSharding命令](https://docs.mongodb.org/manual/reference/method/sh.enableSharding/) * [movePrimary命令](https://docs.mongodb.org/manual/reference/command/movePrimary/) * [shardCollection](https://docs.mongodb.org/manual/reference/command/shardCollection/) * [sharding的管理操作](https://docs.mongodb.org/manual/reference/command/nav-sharding/) * [部署sharded cluster](https://docs.mongodb.org/manual/tutorial/deploy-shard-cluster/)