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/