MogoDB 分片键

MongoDB 根据分片键分割 collection 中的文档，然后分配到分片集群的成员中。

分片键可以是一个存在于每个文件中的索引字段或者复合索引字段。

MongoDB 使用不同范围的分片键值来分割 collection 中的数据。不同分片键范围是不重叠的并且每个分片键范围与一个 chunk 关联。

选择分片键

选择的分片键要尽量使 chunks 平滑的分配到集群的分片中。如果不那么做，会影响集群的性能：

假设所有的 chunks 都被分配到一个分片中，那么整个集群的能力就是这一台分片的能力
假设 chunks 没有均匀分配，集中在一个分片中，那么这个分片可能会成为瓶颈。因为总的耗时取决于最慢的那个分片

为了选择出好的分片键，还需要了解分片键的以下性质

基数性
频率
单调改变

基数性

分片键的基数性决定了平衡器可以创建的最大 chunks 数目。

在任意时刻，一个唯一的键值对只能存在于不超过一个的 chunk 中。现有一个基数性为 4 的分片键，那么在集群中最多有 4 个（有效的） chunks，因为增加额外的分片不会带来收益，每个 chunk 储存一个唯一的分片键。

然而高的基数性也不能保证数据在集群中平滑分配，这还与频率和单调性有关。当选择分片键时，这三个因素都要考虑到。

频率

分片键的频率指给定的分片键值在文件中多常出现。

如果大部分的文件只包含一部分分片键，那么储存大部分文件的分片会成为集群的瓶颈。如果大部分文件只包含一个分片键，那么对应的 chunk 会很大并且不可分割。这就会降低集群的性能。

如果你的数据模型需要在一个高频率的分片键，考虑使用一个唯一的或者低频率的复合索引代替。

单调改变的分片键

单调改变指分片键是单调递增或单调递减的，这样的分片键更容易插入到集群中的一个分片中（而不是均匀分配）。

发生这种情况的原因是每个集群都有两个 chunk 捕捉超出边界的分片键。一个捕捉超出（分片键的）最大值的分片键，一个捕捉小于最小值的分片键。

如果一个分片键是单调递增的，那么在一定时刻之后，所有新增都会进入到 [maxKey, 正无穷] 这个 chunk。同理，单调递减的分片键会进入 [负无穷, minKey]。包含对应 chunk 的分片就会成为写操作的瓶颈。

唯一索引

只有使用整个分片键作为其前缀的唯一索引才能确保其是跨分片唯一的[2]。

哈希分片

哈希分片使用一个字段的哈希索引作为分片键来分割数据。

哈希分片以牺牲查询隔离性为代价来提供分布更加均匀的分片集群。分片值相邻的文档更不可能在同样的分片上，因此对应给定的范围查询 mongos 更可能去执行广播查询。同时，mongos 也能匹配相等的查询到一个分片上。

哈希分片键

选择作为哈希分片键的字段应该有高基数性。假设没有高基数性，那么数据就会集中到某些分片上而不是均匀分配到所有分片，然后数据过多的分片会造成瓶颈。

理想的哈希分片键是单调性的字段，比如 ObjectId 或者时间。

分片键的限制

大小

分片键的大小不能超过 512 bytes。

分片键索引类型

分片键的索引可以是在分片键上递增的索引，一个以分片键为前缀的在分片键上递增的复合索引或是一个哈希索引。

分片键索引不能是在分片键字段上的多键索引、文本索引或者地理空间索引。

分片键不可改变

如果你一定要改变分片键：

导出所有数据
Drop 旧的分片 collection
设置新的分片键
预先分割分片键的范围来确保初始分配是均匀的
导入数据

文档中的分片键不可改变

你不能修改分片键在文本中的对应字段的值。

参考