Mongo 整体架构介绍(1)-------分片集群

摘要

在mongo初识文中介绍了mongo与cassandra的主要区别，以及mongo物理部署架构图。本文接着上一篇的mongo 架构图，来继续讲分片集群。

分片介绍

shard key

mongo 默认配置是不分片的，需要自行enable.mongo 根据shard key来对数据进行分片。有三种分片方式

range

根据范围来分片，比如1-10到shardA,11-20 shardB，以此类推

hash

根据shard key的hash 值来分片

tag

代表的shard key 的一段范围值,比如下图，Tag A代表的就是[1,10)



三种分片的方式区别

range分片会让相近的数据分配在同一个shard上，这样如果进行shard key范围查找的时候效率更高，因为不需要跨shard，或者跨更少的shard.

hash 会让数据分布的更加均匀，降低了某一部分连续的数据都存储在同一shard上，导致数据在集群中分布不均匀。

tag通常是用来隔离数据的，多用于多数据中心架构中。确保相近的数据能够落在物理上相近的shard上。

chunk的概念

看了上面的tag hash，有分布式基础的应该会有疑问，A,B两个shard都有tag A,如果一条数据的shard key值落在了tag A范围时，那他会落在哪个shard 上呢。Shard A or Shard B,this is a question.

这里必须得引入chunk的概念了。shard 并不是mongo document 存储的最小单位，插入/读取的路由也不是基于shard的。最小单位是chunk.

chunk 是一组shard key value 范围的数据集合[minKeyValue,maxKeyValue)，是shard的细分。

在Nosql的分布式存储模式中，要求数据要尽可能的在集群中均匀分布，必然会涉及到数据的移动进行balance.cassandra 通过一致性hash以及虚拟节点来实现这点。如果mongo只是通过shard 这种粗粒度的进行数据分片，可以想象随着数据的增长，必然会出现数据的分布不均匀，不同shard 的规模不一样。引入chunk后，细分了数据，由于shard 是一组物理及其的复制集，不可移动。引入chunk后，可以通过move chunk来balance 数据在各个shard直接的分布。

chunk的移动

chunk 是一组shard key value的集合。他有大小限制，默认的chunk size 是64MB.你可以去更改这个值。当chunk超过这个值，插入或者更新时就会触发chunk 分裂，chunk代表更小范围的shard key value 集合。所以chunk最小范围是一个shard key,以后再也无法分裂。当chunk 在各个shard 上分布不均匀的时候，mongo 的balancer就会move chunk,确保在chunk在各个shard中均匀分布。moveChunk是需要代价的，所以mongo有阈值来控制什么时候去move chunk.

chunk中数量	阈值
<20	2
20-79	4
‘>=80	8

当一个chunk document 数目超过250,000 或者大小超过1.3*(chunk_size/obj_avg_size)的时候就无法move了。obj_avg_size是一个document的平均大小。就会演变成一个超级大的chunk，就会导致数据的分布不均匀，导致请求的热点产生，极大的影响性能。这是我们不想看到的。所以通常来说单一字段作为shard key，都会造成问题，需要联合字段来做shard key.

跨数据中心的chunk move代价岂不是很高

数据的移动在物理分布不同的数据中心代价肯定很高，所以要避免这样的情况发生，可以利用三种分片方式中的tag 分片来做。因为tag是在chunk move 之上，当chunk move时会去检查这个tag 设置的。

如何选择shard key

如何选择shard key，是件充满艺术的事情！mongo 不支持修改shard key，所以要提前定义好shard key。shard key 需要遵循以下原则

数据要在集群中分布均匀

nosql database 都要考虑这个问题，数据均匀分布意味着很多，shard key 的取值范围肯定不能太小

查询

需要考虑你的query case，要让查询尽可能的跨越少的shard

mongo 的限制

比如上面说的，chunk 的documents 数和大小限制，要避免大的，不可移动的chunk 产生。

什么时候去分片

当你准备好的时候，就去分片。

程序的架构是不断演进的，数据的规模也是不断在增长的。如果你的mongo是为大数据存储服务的，那么你应该尽可能早的去定义shard key.如果你的应用可预知的数据规模是很小的，百万级别以下的，那你可以推迟这件事。