[mongo]分片集群

分片集群

分片集群机制及原理

常见部署架构

• 

为什么要使用分片集群

• 数据容量日益增大，访问性能日渐降低
• 新品上线异常火爆，如何支撑更多的并发用户
• 单库已有 10TB 数据，恢复需要1-2天，如何加速
• 地理分布数据

完整的分片集群

• 

• 路由节点 mongos

  • 路由节点
  • 提供集群单一入口
  • 转发应用端请求
  • 选择合适数据节点进行读写合并多个数据节点的返回
  • 无状态建议至少2个

• 配置节点 mongod config

  • 提供集群元数据存储分片数据分布的映射
  • 普通复制集架构
  • 

• 数据节点

  • sharding primary and secondary
  • 以复制集为单位横向扩展
  • 最大1024分片
  • 分片之间数据不重复所有分片在一起才可完整工作

MongoDB 分片集群特点

• 应用全透明，无特殊处理
• 数据自动均衡
• 动态扩容，无须下线
• 提供三种分片方式

分片集群数据分布方式

• 基于范围
• 基于 Hash
• 基于 zone / tag

分片集群数据分布方式 – 基于范围

• 优点
  • 片键范围查询性能好
  • 优化读
• 缺点
  • 数据分布可能不均匀
  • 容易有热点

分片集群数据分布方式 – 基于哈希

• 优点
  • 数据分布均匀，写优化
  • 适用：日志，物联网等高并发场景
• 缺点
  • 范围查询效率低

分片集群数据分布方式 – 自定义Zone

小结

• 分片集群可以有效解决性能瓶颈及系统扩容问题
• 分片额外消耗较多，管理复杂，能不分片尽量不要分片

分片集群设计

合理的架构

合理的架构 – 分片大小

• 数据量不超过3TB，尽可能保持在2TB一个片
• 常用索引必须容纳进内存
• 业务压力

合理的架构 – 需要多少个分片

• 

合理的架构 – 其他需求

• 考虑分片的分布
  • 是否需要跨机房分布分片
  • 是否需要容灾
  • 高可用的要求如何

正确的姿势

• 各种概念由小到大
  • 片键 shard key：文档中的一个字段
  • 文档 doc ：包含 shard key 的一行数据
  • 块 Chunk ：包含 n 个文档
  • 分片 Shard：包含 n 个 chunk
  • 集群 Cluster： 包含 n 个分片

正确的姿势 - 选择合适片键

• 取值基数（Cardinality）；
• 取值分布；
• 分散写，集中读
• 被尽可能多的业务场景用到
• 避免单调递增或递减的片键；

正确的姿势 - 选择基数大的片键

• 对于小基数的片键
  • 因为备选值有限，那么块的总数量就有限
  • 随着数据增多，块的大小会越来越大；
  • 水平扩展时移动块会非常困难；

正确的姿势 - 选择基数大的片键

正确的姿势 – 选择分布均匀的片键

正确的姿势 –足够的资源

• mongos 与 config 通常消耗很少的资源，可以选择低规格虚拟机
• 资源的重点在于 shard 服务器
  • 需要足以容纳热数据索引的内存
  • 正确创建索引后 CPU 通常不会成为瓶颈，除非涉及非常多的计算
  • 磁盘尽量选用 SSD
• 建议监控各项资源使用情况，无论哪一项达到60%以上，则开始考虑扩展
  • 扩展需要新的资源，申请新资源需要时间
  • 扩展后数据需要均衡，均衡需要时间。应保证新数据入库速度慢于均衡速度
  • 均衡需要资源，如果资源即将或已经耗尽，均衡也是会很低效的

MongoDB 监控最佳实践

常用的监控工具及手段

• MongoDB Ops Manager
• Percona
• 通用监控平台
• 程序脚本

如何获取监控数据

• db.serverStatus()
  • db.serverStatus() 包含的监控信息是从上次开机到现在为止的累计数据
  • 官方参考
• db.isMaster()
• mongostats 命令行工具
  • mongostats --host remote-host --port 27017 --username myuser --password mypassword --authenticationDatabase admin --discover 5

监控报警的考量

• 具备一定的容错机制以减少误报的发生
• 总结应用各指标峰值
• 适时调整报警阈值
• 留出足够的处理时间

建议监控指标

• 
• 
•