MongoDB杭州用户交流会于2017年3月12日下午在阿里巴巴西溪园区举行,吸引了来自全国各地的近300名用户参与,千寻位置、妈妈帮、阿里云等公司的5位技术专家分享了MongoDB 的运维管理及使用经验,干货满满。
用户会进行过程中我已经在中文社区微信总群、二群里做了实时的图文直播,这里再做一个重点内容汇总,错过现场的同学可以学习一下,完整的PPT、以及视频云栖社区的同学正在整理中,敬请期待。
—
首先,来自千寻位置的肖应军同学分享了其统一监控平台使用 MongoDB 的实践经验。
千寻的统一监控平台包含数据采集、分发、存储、报表、监控等多个模块,其中「存储」和「报表」的模块大量使用了mongoDB,分别解决数据存储和数据分析的问题。
在数据存储方面,监控数据拥有固有的特性,比如监控的指标不固定,可能临时增加;数据写入的频率比较固定,不会有大的波峰/谷流量出现;读取的并发量比较低,但一次返回的数据量比较大,同时随着数据不断的累计,存储量会越来越大。而mongoDB能很好的解决上述需求
- mongoDB 无 schema 的特性,使得数据结构扩展起来非常方便
- mongoDB 高性能以及数据压缩的特性完全能慢满足数据存储的需求
- mongoDB 的TTL索引的特性能自动的删除过期的数据,确保存储容量不会无限膨胀
千寻的报表模块经历了2个阶段的发展,第一阶段分析需求比较简单,直接使用 mongoDB 的aggregation、mapReduce做数据分析来完成;而随着业务方越来越多,报表的维度越来越细,开始使用spark(通过mongoDB spark connector)、阿里云EMR等产品配合mongoDB做数据分析,效率更高,并且能满足复杂查询分析的需求。
最后,千寻的同学分析了使用 mongoDB 过程中积累的经验
- 生产环境推荐「1主2次」的配置,保证服务高可用、数据高可靠 (注:要保证高可用,除了后端要多节点,还要正确的使用mongoDB driver,以正确的方式连接复制集)
- 慢查询导致长时间锁库(注:3.x版本wiredtiger引入行级锁后,这个问题应该已经不存在)
- 写入压力大可能导致整个库慢 (注:尤其是备库的读会受影响,参考MongoDB Secondary 延时高(同步锁)问题分析,但数据库压力太大说明资源已经不足了,应该扩容了)
- 建索引时,尽量指定{background: true}选项,后台建索引,避免锁库影响业务。
- mongoshell能直接执行js脚本,能极大的方便集群管理
- 使用TTL索引时,索引的字段必须为时间戳字段(注:官方文档有详细介绍)
- 写入时指定需要的writeConcern级别,推荐{w: 1} (注:3.x的版本里{w: 1}是默认的writeConcern级别,是可靠性与性能的折中选择)
- 自建mongoDB 全部迁移 到 mongoDB云数据库服务,极大的降低了运维管理成本。(注:作为 mongoDB 云数据库的开发者,能得到客户的肯定,感到灰常开心)
—
接下来阿里云的技术专家明俨深度解析了mongoDB sharding 备份相关的技术。
mongoDB sharding 解决了写入能力、存储容量扩展的问题,引入了 mongos 用于请求路由,引入 config server 存储sharding 集群的元数据,整个架构相比复制集更加复杂。
sharding 的备份因为「外部修改」以及「内部数据迁移」的影响,使得针对 sharding 集群的备份很难对应都一个确定的时间点。
传统的解决方案是整个集群停止写操作(注:停写的方式包括业务停写,或对secondary调用fsyncLock,或将secondary节点移除),然后对所有shard、config server的数据进行备份,这样的确能回复到一个确定的时间点,但代价很大。
阿里云 MongoDB 数据库针对sharding备份的解决方案是
- 每个 shard 通过 「定期全量备份 + 持续抓取oplog」,具备恢复到任意时间点的能力(时间点精确到秒级别)
- 通过分析config server的迁移操作记录,恢复时避开「可能影响数据不一致的时间区间」(通常很短)。
—
妈妈帮的技术专家胡兴邦介绍了5年来使用 mongoDB 的经验,妈妈帮从2012年就开始全线使用 mongoDB,从2.2(看版本就知道是资深用户)的版本一路升级到3.2(目前都已升级到3.2的最新版本)。
妈妈帮使用mongoDB一路发展过来,使用的架构也不断演进,主要经历了4个阶段
- 最早的master-slave架构 (注:新接触mongoDB的用户可能不知道这是个啥东西,这是mongoDB早期支持的一种部署模式,跟MySQL的主从架构类似,目前已被复制集替代,不建议使用)
- 业务增长后,使用多组 master-slave 的 mongoDB
- 多组的mongoDB master-slave 升级为 多组复制集
- 多组复制集 + mongoDB sharding
妈妈帮最初选择 mongoDB 主要基于其灵活的文档模型,以及天生可扩展的架构,在业务发展的早期能保证业务快速迭代开发,在业务快速发展之后,还能横向扩展。
在遇到事务方面的需求时(注:mongoDB目前无法支持多文档事务,官方有计划支持),妈妈帮使用了最简单的方式来应对,即「后台定时修正不一致的数据」,其他的备选方案,例如使用消息队列、二阶段提交方式从方案上更加成熟,但实现复杂度更高。
在sharding方面,妈妈帮也积累了不少经验,建议用户在使用sharding时,一定要注意shardKey的选择,并给出了一些建议。
- 能满足业务场景查询需求,尽量保证大部分query条件都由shard key,这样请求只用分发到后端单个shard就能满足,性能更高
- 尽量避免单个shard出现热点 (注:需要正确理解hash分片 和 range分片 2种方式的优劣,做出最适合自己业务的选择)
- 避免shard key的取值过少,导致单个chunk很大(jumbo chunk)而无法自动迁移
- 多阅读官方文档,sharding-shard-key
—
阿里云资深研发工程师果实介绍阿里云 MongoDB 云数据库高可用的主题,介绍mongoDB云数据库如何实现自动的故障检测及故障转移。
阿里云数据库 MongoDB 版 是由3个节点组成的高可用复制集(目前也已支持sharding形态),3个分别为Primary、Secondary 和 Hidden,其中Priamry、Secondary节点提供给用户读写,Hidden节点对用户不可见,主要用于实例备份以及保证实例高可用。
Hidden节点平时只同步Primary上写入的数据,并不对外提供服务,实例的全量及增量备份会在Hidden上进行,做到不影响用户的业务。
同时,后端管控服务会不断的模拟用户访问行为来探测实例可用性,当发现实例有节点故障时
- 如果 Hidden 节点故障(不可恢复的故障,如果机器没挂,会尝试先重启启动),后端管控会从资源池里选择一个新的节点,以Hidden的身份加入复制集,替换原来的Hidden,这个过程对用户的服务无影响。
- 如果 Secondary 节点故障,会自动将 Hidden 节点切换为 Secondary,保证用户访问 Secondary 节点不受影响。此时变成了1的状态,按1的方式继续故障转移处理。
- 如果 Primary 节点故障,这时复制集会自动选出新的Primary,此时复制集里缺一个Secondary,变成了2的状态,按2的方式继续故障转移处理。
如果出现2台及以上节点故障,根据 MongoDB 多数派的选举原则,是无法选出Primary的,这时实例会进入只读状态,需要人工介入恢复,但这种场景极少出现。(注:这里也可以reconfig一下,让复制集变成单节点运行继续服务读写,但考虑到用户数据的可靠性,目前并没有使用这个方案)
除了故障时的处理,对于计划中的机器维修、下线,则需要对机器上所有的实例,先将该节点切换为Hidden角色,然后针对所有的Hidden节点按上述1的流程处理,用新的节点替换,当节点上没有任何实例数据时,就可以安全下线了。
—
最后出场的是徐雷老师,徐雷老师是《MongoDB实战》第2版的译者,徐雷老师的分享风趣幽默,不仅讲到MongoDB,还分享了很多架构设计方面的经验,由于当时有事掉线了,没有获取到精髓,等PPT出来大家可以好好学习一下。
在分享里徐老师也提到 MongoDB 目前在国内外各大企业里都有着广泛的应用,充分说明 MongoDB 是一门值得深入投资的技术。
—
最后,预告一下,MongoDB 中文社区今年还会继续在全国各大城市举行 MongoDB 用户的技术交流会,有强大的社区做后盾,用户们可以更放心的使用 MongoDB;而且 MongoDB 本身官方文档已经非常全面了,绝大多数的问题都能从官方文档找到答案,建议大家多看官方文档,用好 MongoDB,为你的业务创造最大价值。
## 作者简介
张友东,阿里云技术专家,主要关注分布式存储、NoSQL数据库等技术领域,先后参与TFS(淘宝分布式文件系统)、Redis云数据库等项目,目前主要从事MongoDB云数据库的研发工作,致力于让开发者用上最好的MongoDB云服务。
评论前必须登录!
注册