MongoDB 企业中分片集群设计

来自AI助手的总结
介绍MongoDB分片集群规划、片键选择与硬件配置原则
MongoDB 企业中分片集群设计

一、如何用好分片集群

1、合理的架构

  • 是否需要分片

  • 需要多少分片

  • 数据的分布规则

2、正确的姿势

  • 选择需要分片的表

  • 选择正确的片键

  • 使用合适的均衡策略

3、足够的资源

  • CPU

  • RAM

  • 存储

  • 二、分片的基本标准

  • 关于数据:数据量不超过 3TB,尽可能保持在 2TB一个片;

  • 关于索引:常用索引必须容纳进内存;

  • 按照以上标准初步确定分片后,还需要考虑业务压力,随着压力增大, CPU、 RAM、磁盘中的任何一项出现瓶颈时,都可以通过添加更多分片来解决。

二、如何粗略判断需要多少分片

  • A = 所需存储总量 / 单服务器可挂载容量

  • B = 工作集大小 / (单服务器内存容量 * 0.6)

  • C = 并发量总数 / (单服务器并发量 * 0.7)

分片数量 = max(A, B, C) =?

例子:


A = 8TB / 2TB = 4

B = 400GB / ( 256G \* 0.6) = 3 C = 30000 / (9000\*0.7) = 6 分片数量 = max(A, B, C) = 6

三、额外的考量

考虑分片的分布:

  • 是否需要跨机房分布分片?

  • 是否需要容灾?

  • 高可用的要求如何 ?

四、选择片键的正确姿势

  • 片键 shard key:文档中的一个字段 ,也就是我们要选择的分片键

  • 文档 doc :包含 shard key 的一行数据

  • 块 Chunk :是一个逻辑的概念,包含 n 个文档,通常是 64M, 从 6.0.3开始不以 chunk进行均衡,而是 以为数据量进行均衡

  • 分片 Shard:包含 n 个 chunk

  • 集群 Cluster: 包含 n 个分片

  • 正确的姿势 ——选择合适的片键 影响片键效率的主要因素:

  • 取值基数( Cardinality);

  • 取值分布;

  • 分散写,集中读;

  • 被尽可能多的业务场景用到;

  • 避免单调递增或递减的片键;

4.1 准则 1:选择基数大的片键

对于小基数的片键:

  • 因为备选值有限,那么块的总数量就有限;

  • 随着数据增多,块的大小会越来越大;

  • 水平扩展时移动块会非常困难;

例如:存储一个高中的师生数据,以年龄(假设年龄范围为 15~65岁)作为片键, 15<=年龄 <=65,且只为整数 ,所以最多只会有 51个 chunk

结论:取值基数要大!

4.2 准则 2:选择分布均匀的片键

对于分布不均匀的片键:

  • 造成某些块的数据量急剧增大

  • 这些块压力随之增大

  • 数据均衡以 chunk 为单位,所以系统无能为力

例如:存储一个学校的师生数据,以年龄(假设年龄范围为 15~65岁)作为片键,那么:

  • 15<=年龄 <=65,且只为整数

  • 大部分人的年龄范围为 15~18岁(学生)

  • 15、 16、 17、 18四个 chunk 的数据量、访问压力远大于其他 chunk **结论:取值分布应尽可能均匀。

4.3 准则 3:查询的时候定向性好

考虑:

  • 4个分片的集群,你希望读某条特定的数据

  • 如果用片键作为条件查询, mongos可以直接定位到具体的分片

  • 如果不用片键查询, mongos需要吧查询发到 4个分片

  • 等最后的一个响应, mongos才能响应应用端

结论:对主要查询要具有定向能力

4.4 通过一个例子来看片键选择

我们用一个 Email系统的例子来学习下片键,这是一个 email的文档,里面有 id, id就是自增的,无穷大

{
  "_id": ObjectId(),
  "user": 123,
  "time": Date(),
  "subject": "...",
  "recipients": [],
  "body": "...",
  "attachments": []
}

5.4 选择片键:

5.4 选择片键:

5.4 选择片键:

5.4 选择片键:

五、如何规划硬件

  • mongos 与 config 通常消耗很少的资源,可以选择低规格虚拟机;

  • 资源的重点在于 shard 服务器:

  • 需要足以容纳热数据索引的内存;

  • 正确创建索引后 CPU 通常不会成为瓶颈,除非涉及非常多的计算;

  • 磁盘尽量选用 SSD;

实际测试是最好的检验,来看你的资源配置是否完备。 另外,即使项目初期已经具备了足够的资源,仍然需要考虑在合适的时候扩展。建议监控 各项资源使用情况,无论哪一项达到 60%以上,则开始考虑扩展。因为:

  • 扩展需要新的资源,申请新资源需要时间;

  • 扩展后数据需要均衡,均衡需要时间。应保证新数据入库速度慢于均衡速度

  • 均衡需要资源,如果资源即将或已经耗尽,均衡也是会很低效的。

© 版权声明
THE END
喜欢就支持一下吧
点赞13 分享
评论 抢沙发

请登录后发表评论

    暂无评论内容