MongoDB 分片

一. 什么是分片

分片(shards)是使用多个机器存储数据的方法,MongoDB使用分片以支持巨大的数据存储量和对数据的操作。它将一个很大的集合分割成多个片(shard),每个分片存储于不同的机器或副本集中,每个分片都是一个独立的数据库。

分片为提高系统吞吐量和大数据的存储提供了方法:

  • 使用分片减少了每个分片需要处理的请求数
  • 使用分片减少了每个分片存储的数据量

二. 分片的基础设施

1. 片键(shard key)

MongoDB通过片键将一个集合分为多个部分,它决定了一个集合的文档在不同的分片上的分布。它有如下特性:

  • 片键字段可以是单个字段或者是复合字段
  • 片键字段必须被索引(或是索引的前缀)
  • 片键字段不能是多键索引
  • 集合中的每个文档都必须包含片键字段
  • 文档的片键值不可被修改,只能删除文档,并重新插入新片键文档
  • 不同文档的片键可以相同

MongoDB的片键有两种:

1.1 基于范围的片键

如有Person集合,其片键age,有两个分片,那么分片1可能负责存储-∞<=age<20的文档,分片2负责存取20<=age<∞的文档,这里的∞代表MongoDB所有值的最大值,而不仅限于数字。这是最简单的基于范围的片键模型,我们需要手动指定某个范围的片键位于某个分片上,MongoDB的分片机制要比这个要灵活强大得多。

1.2 基于哈希的片键:

同样,我们可以基于片键哈希值来进行分片之间的分发,集合片键需要有足够大的基数。

在写入的时候,MongoDB(mongos)会将请求分发到负责该片键的分片上,在查询的时候,如果查询涉及了片键,则和写入一样,MongoDB会将请求分发到对应的片键上(针对性查询),否则,MongoDB必须将请求发送到所有的分片上,以获取结果。

更多参考:http://docs.mongoing.com/manual-zh/core/sharding-shard-key.html

2. 块分裂(chunk split)

随着文档的不断写入,各个分片的集合大小会拉开差距,单个分片的集合大小仍然可能是个问题。MongoDB采用单分片多区间的方式来将片键映射到分片,某个区间片键内的文档被称作”块”(chunk),当某个块超过设置的块大小(sharding-chunk-size,默认为64M,会动态调整)时,MongoDB会负责将这个数据块分割为两个,分裂会改变元信息,但效率很高,对集群的性能也没有影响。

3. 块迁移 (chunk migration)

随着块分裂持续下去,会导致不同分片之间的块数量和压力的不均衡,这个时候,MongoDB会开始一次分片间的数据块迁移,平衡各个分片的块数量,并调整各个分片的片键区间。MongoDB允许管理员控制块阀值大小,并且可以通过标记来直接决定集群分布。

块分裂,块迁移示例图:

分片 片键
分片1 age (-∞, 20)
分片2 age [20, ∞)

分片2的文档持续增长,导致块分裂:

分片 片键
分片1 age (-∞, 20)
分片2 age [20, 30), [30, 50), [50, ∞)

当各个分片之间的块数量差距过大时,导致块迁移:

分片 片键
分片1 age (-∞, 20), [20, 30)
分片2 age [30, 50), [50, ∞)

分块过程是由平衡器(balancer)来控制的,整个分裂和迁移过程都是自动的,块的分裂阀值可设置,如果你想要人为控制块分布,只能关闭平衡器,或者重新选择片键。

三. 如何选择片键

1. 范围片键 vs 哈希片键

基于范围的分片方式提供了更高效的范围查询,给定一个片键的范围,分发路由可以很简单地确定哪个数据块存储了请求需要的数据,并将请求转发到相应的分片中。

不过,基于范围的分片会导致数据在不同分片上的不均衡,有时候,带来的消极作用会大于查询性能的积极作用。比如,如果片键所在的字段是线性增长的,一定时间内的所有请求都会落到某个固定的数据块中,最终导致分布在同一个分片中。在这种情况下,一小部分分片承载了集群大部分的数据,系统并不能很好地进行扩展。

与此相比,基于哈希的分片方式以范围查询性能的损失为代价,保证了集群中数据的均衡。哈希值的随机性使数据随机分布在每个数据块中,因此也随机分布在不同分片中。但是也正由于随机性,一个范围查询很难确定应该请求哪些分片,通常为了返回需要的结果,需要请求所有分片。

2. 哈希片键的选择

哈希片键的选择是比较简单的,片键只需要满足基数够大,通常ObjectId,自增ID,时间戳,都是不错的选择。

3. 范围片键选择

范围片键的选择是比较复杂的,但目标是一致的:读写分离数据局部性,举几个例子:

a. 小基数片键:

小基数片键随着数据增长和块分裂,单个块的片键范围越来越小,最终可能会形成单个块对应单个片键,此时无法再进行块分裂,从而导致单个块过大,吞吐量也会受到影响。

小基数片键满足数据局部性,并且基于片键的查询效率也很高,但MongoDB不能对数据块进行有效地分割,导致读写不能分离。

解决方案:如果是要基于该小基数片键进行大量的查询,可以选择组合片键,确保第二个字段有足够大的基数。

b. 升序片键:

我们可能会选择ObjectId这类自增Key作为片键,这类Key的问题是可能会造成单一且不可分散的性能单点,因为新数据总是写入最新的数据块,没有做到写分离。

c. 随机片键

随机片键的原理有点像哈希片键,比如选择MD5这类Key来做片键,这样能够很好地满足读写分离,文档被随机分布在分片中。但和哈希片键不同的是,哈希片键对片键查询仍然是比较高效的,根据片键算出哈希值,找到指定分片即可。对于随机片键来说,通常我们不会基于随机片键进行查询,而非片键查询需要向所有分片发出请求。因此实际上随机片键相对于哈希片键,在灵活性(哈希函数可以自己设置),查询效率等方面都是有所不如的。

而无论哈希片键还是随机片键,都存在一个问题,数据过于分散,数据局部性不是很高,可能会导致块迁移时,磁盘IO开销很大(冷数据)。

d. 好的片键

由于数据通常满足时间局部性,因此首先我们希望数据大致按照时间排序,但同时,我们希望数据能均匀分布,不要造成性能热点,因此添加一个搜索键作为第二片键。比如{"month":1, "name":1},在3月时,当数据量够大时,MongoDB能够根据name键有效合理地分块,随着时间增长,在4月时,3月的数据开始不再被使用,置换出内存,渐渐成为冷数据,并且由于3月的数据不再写入,因此3月的数据也无需被分裂从而进一步造成块迁移,因此不会造成块迁移磁盘IO开销大的问题。

一般情况下,好的片键可以通过该公式推导:{控制局部化:1, 控制读写分离:1},控制局部化的键可以是粗粒度时间(考虑一下为什么不是细粒度?),控制读写分离的键通常是查询键。