MongoDB Sharding學習理論篇

MongoDB Sharding技術是MongoDB為了解決隨著數據量的增加和讀寫請求的增加，單個MongoDB實例無法應對的問題.通過使用Sharding,MongoDB將數據切分成多個部分,將數據分布存放在多個shard上.Sharding技術使單個shard處理請求減少和存儲容量減小,同時,隨著集群的擴大,整個集群的吞吐量和容量都會擴大.

Sharded cluster分片集群有以下幾個組件：shards，query routers,config servers.

shards: 用來存儲數據，為這個分片集群提供高可用和數據一致性。在一個生產環境中，每個shard都是一個replica set。

query routers： 或者是mongos實例，用于與應用程序交互，將請求轉發到后端的shards，然后將請求結果返回給客戶端。一個分片集群可以有多個query router即mongos實例用于分攤客戶端的請求壓力。如果使用多個mongos實例，可以使用HAProxy或者LVS等代理來轉發客戶端請求到后端的mongos，必須要配置成client affinity模式保證來自同一個客戶端的請求轉發到后端相同的mongos.通常會將mongos實例部署到應用服務器上。

config servers： 用于存儲分片集群的元數據。這些元數據包含整個集群的數據集合data sets與后端shards的對應關系。query router使用這些元數據來將客戶端請求定位到后端相應的shards。生產環境的分片集群正好有3個config servers。config servers里的數據非常重要，如果config servers全部掛掉，整個分片集群將不可用。在生產環境中，每個config server都必須放置到不同的服務器上，并且每個分片集群的config server不能共用，必須分開部署。

MongoDB Sharding是在Collection即集合層面來分布存儲數據的，Sharding依據shard key來講一個集合的數據來分布存儲。

為了將一個集合的數據進行分片，首先需要選擇一個shard key。一個shard key可以是存在于一個集合中每個文檔的索引字段或者符合索引字段。MongoDB將這個shard key的值切分成多個數據塊，然后將這些數據塊均勻分布到后端的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會先計算一個字段值得哈希值，然后使用這些哈希值來創建數據塊。

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 in the cluster.

Performance Distinctions between Range and Hash Based Partitioning

Range based partitioning支持更有效的范圍查詢。對于一個shard key給定一個范圍查詢，query router可以更容易地判斷將請求只路由到包含相應數據庫的shard上。

Range based partitioning可能會導致數據分布不均，這樣會對sharding產生負面作用，比如會出現大部分請求被分發到同一個shard的情況發生。

Hash based partitioning可以確保數據平均分布，但是這樣會導致經過哈希處理的值在各個數據塊和shard上隨機分布，進而使制定的范圍查詢range query不能定位到某些shard而是在每個shard上進行查詢。

Customized Data Distribution with Tag Aware Sharding

MongoDB允許使用tag aware sharding來根據shard key的范圍創建并關聯一些tag到后端的shards。主要用于同一個分片集群數據分布到多個數據中心的情況。

Maintaining a Balanced Data Distribution

隨著數據的增加或者是服務器的增加都會導致整個分片集群的數據分布不均衡，比如一個shard比其他shard上的數據庫chunk明顯多了很多，或者一個數據塊chunk的大小明顯比其他chunk大很多。

MongoDB使用兩個后臺進程來確保一個均衡的分片集群，它們分別是splitting和balancer.

Splitting

Splitting是一個防止chunk變得太大的后臺進程，當一個chunk大小超過了指定的大小，MongoDB將會把這個chunk分成兩半。插入和更新操作都會觸發split。

Balancing

balancer是一個用于管理chunk遷移的后臺進程。

當一個分片集群中一個分片集合的數據分布不均衡時，balancer進程會把擁有最多chunk的shard上的chunk遷移到擁有最少chunk的shard上，直到這個集合的數據分布均衡為止。例如，集合user在shard 1上擁有100個chunk，在shard2上擁有50個chunk，balancer進程會將shard1上的chunk遷移到shard2，直到兩個shard上的chunk數量保持均衡位置。

向一個分片集群中添加或刪除shard都會影響整個集群的均衡性。

Primary shard

每個數據庫都會有一個primary shard存儲這個數據庫中所有未被分片的集合數據。

MongoDB Sharding技術的應用場景：

A.如果數據集data set大小將要或者已經超過了單個MongoDB實例的容量大小。

B.活動的工作集working set大小將要超過最大物理內存大小

C.單個MongoDB實例無法滿足頻繁的寫操作。

如果以上三種情況沒有滿足，不需要部署sharding，只會增加復制度，同時在設計數據模型時，也要考慮到以后作分片的情況。

Data Quantity Requirements

Sharding只會在數據量比較大的情況下才會發揮作用，默認的chunk大小是64MB，只有在滿足特定條件下，balancer進程才會將數據遷移到其他shard上，否則數據會一直存儲到單個shard上。

Broadcast Operations and Targeted Operations

通常情況下，分片集群處理客戶端的請求有以下另種方式：

將操作請求廣播到整個集群中所有包含集合中的文檔的shard上。

基于shard key將操作請求定位到單個shard或一組shard

參考文檔：

http://docs.mongodb.org/manual/sharding/