MongoDB Sharding學習理論篇

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ù)一致性。在一個生產(chǎn)環(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。生產(chǎn)環(huán)境的分片集群正好有3個config servers。config servers里的數(shù)據(jù)非常重要，如果config servers全部掛掉，整個分片集群將不可用。在生產(chǎn)環(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 in the 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產(chǎn)生負面作用，比如會出現(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/