MongoDB Sharding技術是MongoDB為了解決隨著數(shù)據(jù)量的增加和讀寫請求的增加，單個MongoDB實例無法應對的問題.通過使用Sharding,MongoDB將數(shù)據(jù)切分成多個部分,將數(shù)據(jù)分布存放在多個shard上.Sharding技術使單個shard處理請求減少和存儲容量減小,同時,隨著集群的擴大,整個集群的吞吐量和容量都會擴大.
Sharded cluster分片集群有以下幾個組件：shards，query routers,config servers.
shards: 用來存儲數(shù)據(jù)，為這個分片集群提供高可用和數(shù)據(jù)一致性。在一個生產環(huán)境中，每個shard都是一個replica set。
query routers： 或者是mongos實例，用于與應用程序交互，將請求轉發(fā)到后端的shards，然后將請求結果返回給客戶端。一個分片集群可以有多個query router即mongos實例用于分攤客戶端的請求壓力。如果使用多個mongos實例，可以使用HAProxy或者LVS等代理來轉發(fā)客戶端請求到后端的mongos，必須要配置成client affinity模式保證來自同一個客戶端的請求轉發(fā)到后端相同的mongos.通常會將mongos實例部署到應用服務器上。
config servers： 用于存儲分片集群的元數(shù)據(jù)。這些元數(shù)據(jù)包含整個集群的數(shù)據(jù)集合data sets與后端shards的對應關系。query router使用這些元數(shù)據(jù)來將客戶端請求定位到后端相應的shards。生產環(huán)境的分片集群正好有3個config servers。config servers里的數(shù)據(jù)非常重要，如果config servers全部掛掉，整個分片集群將不可用。在生產環(huán)境中，每個config server都必須放置到不同的服務器上，并且每個分片集群的config server不能共用，必須分開部署。
MongoDB Sharding是在Collection即集合層面來分布存儲數(shù)據(jù)的，Sharding依據(jù)shard key來講一個集合的數(shù)據(jù)來分布存儲。
為了將一個集合的數(shù)據(jù)進行分片，首先需要選擇一個shard key。一個shard key可以是存在于一個集合中每個文檔的索引字段或者符合索引字段。MongoDB將這個shard key的值切分成多個數(shù)據(jù)塊，然后將這些數(shù)據(jù)塊均勻分布到后端的shard上。MongoDB使用range based partitioning 或者 hash based partitionning來講一個shard key的值進行切分。shard key一旦選擇好是不能變更的。
Range Based Sharding
Given a range based partitioning system, documents with “close” shard key values e likely to be in the same chunk, and therefore on the same shard.
Hash Based Sharding
對于hash based partitionning，MongoDB會先計算一個字段值得哈希值，然后使用這些哈希值來創(chuàng)建數(shù)據(jù)塊。
With hash based partitioning, two documents with “close” shard key values are unlikely to be part of t same chunk. This ensures a more random distribution of a collection inthe cluster.
Performance Distinctions between Range and Hash Based Partitioning
Range based partitioning支持更有效的范圍查詢。對于一個shard key給定一個范圍查詢，query router可以更容易地判斷將請求只路由到包含相應數(shù)據(jù)庫的shard上。
Range based partitioning可能會導致數(shù)據(jù)分布不均，這樣會對sharding產生負面作用，比如會出現(xiàn)大部分請求被分發(fā)到同一個shard的情況發(fā)生。
Hash based partitioning可以確保數(shù)據(jù)平均分布，但是這樣會導致經(jīng)過哈希處理的值在各個數(shù)據(jù)塊和shard上隨機分布，進而使制定的范圍查詢range query不能定位到某些shard而是在每個shard上進行查詢。
Customized Data Distribution with Tag Aware Sharding
MongoDB允許使用tag aware sharding來根據(jù)shard key的范圍創(chuàng)建并關聯(lián)一些tag到后端的shards。主要用于同一個分片集群數(shù)據(jù)分布到多個數(shù)據(jù)中心的情況。
Maintaining a Balanced Data Distribution
隨著數(shù)據(jù)的增加或者是服務器的增加都會導致整個分片集群的數(shù)據(jù)分布不均衡，比如一個shard比其他shard上的數(shù)據(jù)庫chunk明顯多了很多，或者一個數(shù)據(jù)塊chunk的大小明顯比其他chunk大很多。
MongoDB使用兩個后臺進程來確保一個均衡的分片集群，它們分別是splitting和balancer.
Splitting
Splitting是一個防止chunk變得太大的后臺進程，當一個chunk大小超過了指定的大小，MongoDB將會把這個chunk分成兩半。插入和更新操作都會觸發(fā)split。
Balancing
balancer是一個用于管理chunk遷移的后臺進程。
當一個分片集群中一個分片集合的數(shù)據(jù)分布不均衡時，balancer進程會把擁有最多chunk的shard上的chunk遷移到擁有最少chunk的shard上，直到這個集合的數(shù)據(jù)分布均衡為止。例如，集合user在shard 1上擁有100個chunk，在shard2上擁有50個chunk，balancer進程會將shard1上的chunk遷移到shard2，直到兩個shard上的chunk數(shù)量保持均衡位置。
向一個分片集群中添加或刪除shard都會影響整個集群的均衡性。
Primary shard
每個數(shù)據(jù)庫都會有一個primary shard存儲這個數(shù)據(jù)庫中所有未被分片的集合數(shù)據(jù)。
MongoDB Sharding技術的應用場景：
A.如果數(shù)據(jù)集data set大小將要或者已經(jīng)超過了單個MongoDB實例的容量大小。
B.活動的工作集working set大小將要超過大物理內存大小
C.單個MongoDB實例無法滿足頻繁的寫操作。
如果以上三種情況沒有滿足，不需要部署sharding，只會增加復制度，同時在設計數(shù)據(jù)模型時，也要考慮到以后作分片的情況。
Data Quantity Requirements
Sharding只會在數(shù)據(jù)量比較大的情況下才會發(fā)揮作用，默認的chunk大小是64MB，只有在滿足特定條件下，balancer進程才會將數(shù)據(jù)遷移到其他shard上，否則數(shù)據(jù)會一直存儲到單個shard上。
Broadcast Operations and Targeted Operations
通常情況下，分片集群處理客戶端的請求有以下另種方式：
將操作請求廣播到整個集群中所有包含集合中的文檔的shard上。
基于shard key將操作請求定位到單個shard或一組shard
參考文檔：
http://docs.mongodb.org/manual/sharding/
另外有需要云服務器可以了解下創(chuàng)新互聯(lián)cdcxhl.cn，海內外云服務器15元起步，三天無理由+7*72小時售后在線，公司持有idc許可證，提供“云服務器、裸金屬服務器、高防服務器、香港服務器、美國服務器、虛擬主機、免備案服務器”等云主機租用服務以及企業(yè)上云的綜合解決方案，具有“安全穩(wěn)定、簡單易用、服務可用性高、性價比高”等特點與優(yōu)勢，專為企業(yè)上云打造定制，能夠滿足用戶豐富、多元化的應用場景需求。
重慶分公司
重慶分公司
