基本概念¶

Shard Key(分片键)¶

通过定义 shared key （分片键）从而对整个集合进行分片，分片键的好坏直接影响到整个集群的性能
另外需要注意的是，一个集合有且只有一个分片键，一旦分片键确定好之后就不能更改
分片键分为以下两种类型

基于 Hashed 的分片:

MongoDB 计算分片键字段值的哈希值，用以确定该文档存于哪个 chunk, 从而达到将集合分摊到不同的 chunk
此种类型能够使得数据整体分布比较均匀，对于等值查询效率很高
但是对于范围查询效率就比较低，因为可能要扫描所有的分片才能获取到数据

基于 Ranged 的分片:

MongoDB 会将相似的值放到一个 chunk 中
所以说如果在查询的时候带上分片键的范围条件，查询效率会非常高，因为不需要扫描所有的分片就可以定位到数据

注意，如果片键的值为单调递增或单调递减，那么不适合采用该分片策略
因为数据总会写到一个分片，从而没有很好地分散 IO

Chunk(块)¶

chunk （块）是均衡器迁移数据的最小单元，默认大小为 64MB，取值范围为 1-1024MB
一个块只存在于一个分片，每个块由片键在特定范围内的文档组成，块的范围为左闭又开即 [start,end)
一个文档属于且只属于一个块，当一个块增加到特定大小的时候，会通过拆分点（split point）被拆分成 2 个较小的块

chunk 的拆分&迁移¶

拆分过程如下:

mongos 接收到客户端发起的写请求后会检查当前块的拆分阈值点。
如果需要拆分，mongos 则会像分片服务器发起一个拆分请求。
分片服务器会做拆分工作，然后将信息返回 mongos。

迁移过程如下:

均衡器进程发送 moveChunk 命令到源分片。
源分片使用内部 moveChunk 命令，在迁移过程，对该块的操作还是会路由到源分片。
目标分片构建索引。
目标分片开始进行数据复制。
复制完成后会同步在迁移过程中该块的更改。
同步完成后源分片会连接到配置服务器，使用块的新位置更新集群元数据。
源分片完成元数据更新后，一旦块上没有打开的游标，源分片将删除其文档副本。

修改 chunk 大小¶

备注

修改 chunk 大小需要注意以下几点: chunk 的自动拆分操作仅发生在插入或更新的时候。如果减少 chunk size，将会耗费一些时间将原有的 chunk 拆分到新 chunk，并且此操作不可逆。如果新增 chunk size，已存在的 chunk 只会等到新的插入或更新操作将其扩充至新的大小。 chunk size 的可调整范围为 1-1024MB。

jumbo chunk¶

在有些情况下，chunk 会持续增长，超过 ChunkSize，官方称为 jumbo chunk:

该块无法被 MongoDB 拆分，也不能被均衡器迁移
故久而久之会导致 chunk 在分片服务器上分布不均匀
从而成为性能瓶颈，表现之一为 insert 数据变慢

造成jumbo chunk的原因:

一个固定键值下面的数据太多导致
相同的片键只能保存在相同的块中
如果一个相同的片键过多，则会导致一个块过大，成为 jumbo chunk

Balancer(均衡器)¶

MongoDB 的 balancer （均衡器）是监视每个分片的 chunk 数的一个后台进程。
当分片上的 chunk 数达到特定迁移阈值时，均衡器会尝试在分片之间自动迁移块，使得每个分片的块的数量达到平衡。
分片群集的平衡过程对用户和应用程序层完全透明，但在执行过程时可能会对性能产生一些影响。

备注

从 MongoDB 3.4 开始，balancer 在配置服务器副本集（CSRS）的主服务器上运行，