58同城从MongoDB到MySQL迁移之路 孙玄 2015年11月04日

目录 MongoDB在58同城的架构设计与实践 针对业务场景我们在MongoDB中如何设计库和表 数据量增大和业务并发，我们遇到典型问题及其解决方案 我们为什么要迁移MongoDB？ MongoDB到MySQL的无缝迁移架构设计及实践 迁移后MySQL架构相比于MongoDB架构线上情况对比

MongoDB在58同城的架构设计与实践 使用业务线 58帮帮 58交友 58招聘 58信息质量 58测试 …

MongoDB在58同城的架构设计与实践 Why? What? Scalable & High Availability Master-Slave Replic Set High-performace MMAP Persistent Cache 数据一致性 Rich Querying Full Index Support Auto-Sharding What? 事务性要求低 高访问量 垂直业务扩展

MongoDB在58同城的架构设计与实践 How? free schema Auto-sharding 内嵌文档 自动生成_id … ALL Schema 如何应对？ 减少字段名 数据存储压缩 Auto-sharding 库级sharding Collection sharding 手动sharding(切分大文档) 内嵌文档 自然、高效 更多重复数据、反规范化 RDBMS表拆分 类RDBMS处理 字段名尽可能短小，上层做映射 自动生成_id 默认有(12个字节) 存储空间大 业务层客户端生成 减少MongoDB服务端开销 …

58同城MongoDB使用实践 MongoDB部署 Replica Set + Sharding Shard Server (Replica Set)（n） Config Server（n） Route Server（n） Arbiter Server （n） 增加Shard Server RS内部增减 读写分离 故障转移 库级sharding(move primary) 表级手动sharding auto-sharding(指定时间段凌晨)

针对业务场景我们在MongoDB中如何设计库和表 Auto-Sharding is not that Reliable Why? Sharding key 单一key分片不均衡 复合key性能消耗 Count值计算不准确 Chunk移动过程，计算可能偏大 Balancer的稳定性&智能性 Sharding发生的时间不确定性 指定Sharding迁移时间

针对业务场景我们在MongoDB中如何设计库和表 我们如何设计库？ 线上环境禁用Auto-Sharding 开启数据级别分片 db.runCommand({“enablesharding”: “im”}); 特定库指定到某一固定分片上 db.runCommand({movePrimary:“im”, to: “sharding1”}); 保证数据无迁移稳定 避免Auto-Sharding带来的问题 完全可控 效果好

针对业务场景我们在MongoDB中如何设计库和表 我们如何设计库？ 库设计 对业务增长情况要要求 目前是什么量级 半年~一年是什么量级 库分片 Sharding分片数量 容量规划的关键原则 Memory > Index + Hot Data 索引+热数据要全部加载到内存(MMAP） MongoDB的高性能

针对业务场景我们在MongoDB中如何设计库和表 我们如何设计库？ 如何设计频繁更新删除记录的collection MongoDB的数据库是按文件来存储的 例如：db1下的所有collection都放在一组文件内db1.0,db1.1,db1.2,db1.3… 将频繁更新删除的表放在一个独立的数据库下，将会减少碎片，并提高性能 单库单表绝对不是最好的选择 原因有三： 表越多，映射文件越多，从MongoDB的内存管理方式来看，浪费越多 同理，表越多，回写和读取的时候，无法合并IO资源，大量的随机IO对传统硬盘是致命的 单表数据量大，索引占用高，更新和读取速度慢 Local库 Local库主要存放oplog，oplog同样是要消耗内存的 选择一个合适的oplog值，很重要 高插入高更新，并带有延时从库的副本集需要一个较大的oplog值（比如20G） 如果没有延时从库，则可以适当放小oplog值

针对业务场景我们在MongoDB中如何设计库和表 我们如何设计表？ RDBMS与MongoDB 数据库、表/集合、行/文档 三范式与嵌套 举例“人”描述 RDBMS(People 、Address) MongoDB(People)

针对业务场景我们在MongoDB中如何设计库和表 我们如何设计表？ 一对一 IM用户信息表 用户uid、用户登录名、用户昵称、用户签名 类RDBMS设计 一张用户信息表 {uid:XX, loginname:XX, nickname:XX, sign:XX} uid实际上为_id 主键

针对业务场景我们在MongoDB中如何设计库和表 我们如何设计表？ 一对多 用户在线消息表 一个人可以收很多条消息 典型的一对多 如何设计 类RDBMS {uid，msg，msg_content} 123, 1, 你好 123，2，在吗 MongoDB嵌套 {uid:XX, msg:{[{msgid:1,msg_content:你好}，{msgid:2, msg_content:在吗}]}} 嵌套更自然、更新不方便、单条16MB的限制 RDBMS遵循范式、查询条件更灵活、扩展性高

针对业务场景我们在MongoDB中如何设计库和表 我们如何设计表？ 多对多 Team表&User表 一个Team中有多个User 一个User也可能属于多个Team 典型的多对多关系 如何设计 类RDBMS(三张表) Team表 {teamid, teamname, ……} User表 {userid,username,……} Relation表 {refid, userid, teamid}

针对业务场景我们在MongoDB中如何设计库和表 我们如何设计表？ 多对多 Team表&User表 一个Team中有多个User 一个User也可能属于多个Team 典型的多对多关系 如何设计 MongoDB嵌套（2个集合） Team表 {teamid,teamname, teammates:{[userid, userid, ……]} User表 {useid,usename, teams:{[teamid, teamid,……]}} {useid,usename} 每次通过Team表中的teammates反查询得到teamid Teammates需要建立索引

针对业务场景我们在MongoDB中如何设计库和表 我们如何设计表？  单表数据量大如何Sharding？ Collection Sharding 手动Sharding 如何手动Sharding 单表千万量级 单ID查询key水平拆分表 用户信息表 {uid, loginname, sign, ……} 按照uid水平拆分 uid%64 按照uid的查询 可控、可靠 避免了Auto-Sharding带来的不稳定因素

针对业务场景我们在MongoDB中如何设计库和表 我们如何设计表？  单表数据量大如何Sharding？ 混合ID查询 商品表 {uid, infoid, info,……} infoid包含uid的信息（infoid最后8个bit，uid的最后8个bit） infoid水平拆分 infoid%64 按照uid的查询 按照infoid的查询

数据量增大和业务并发，遇到的问题及其解决方案 大量删除数据问题及其解决方案 背景 IM离线消息集合结构 字段： msgid, fromuid, touid, msgcontent, timestamp, flag 其中touid为索引 其中flag表示离线消息是否已读取，0未读，1读取 删除已经读取的离线消息 db.collection.remove({“flag” : 1}}; 命令非常简单 看似很容易就搞定了 5kw的数据条数 200G的存储空间

数据量增大和业务并发，遇到的问题及其解决方案 大量删除数据问题及其解决方案 遇到问题 晚上10点后部署删除 早上7点还没删除完毕 断续有报警 从库延迟大 QPS/TPS很低 业务无法响应 分析原因 db.collection.remove({“flag” : 1}}; flag不是索引字段 全部扫描 删除速度很慢 冷数据和热数据swap，造成内存中全是冷数据，服务能力急剧下降

数据量增大和业务并发，遇到的问题及其解决方案 大量删除数据问题及其解决方案 如何解决 紧急方案 找到正在执行的op kill opid 长期删除 业务层优化 逻辑删除--》物理删除 离线删除优化 每晚定时从库导出要删除的数据 通过脚本按照objectid的方式进行删除 删除速度可以控制 避免对线上服务影响

MongoDB遇到问题及其解决方案 大量数据空洞问题及其解决方案 遇到问题 大量删除数据，MongoDB存在大量的数据空洞 这些空洞数据也同时会加载到内存 导致内存有效负荷低 数据不断在swap MongoDB数据库性能并没有明显提升 怎么办？

MongoDB遇到问题及其解决方案 db.yourCollection.runCommand(“compact”); 大量数据空洞问题及其解决方案 解决方案 MongoDB数据空间的分配是以DB为单位 不是以Collection为单位的 问题的关键是大量碎片无法利用 碎片整理、空洞合并收缩 怎么做？ 方案一 Online Compress Compact命令 db.yourCollection.runCommand(“compact”); Collection级别压缩 去除Collectoin所在文件碎片 影响服务 压缩效果差，不推荐使用

MongoDB遇到问题及其解决方案 大量数据空洞问题及其解决方案 方案二 收缩数据库 把已有的空洞数据，remove掉，重新生成一份无空洞数据 先预热从库 把预热的从库提升为主库 把之前主库的数据全部删除 重新同步 同步完成后，预热此库 把此库提升为主库 完全无碎片 收缩率100% 持续时间长、投入维护成本高 收缩过程单点存在一定风险 Replic Set

MongoDB遇到问题及其解决方案 大量数据空洞问题及其解决方案 收缩数据库 效果对比如下： 收缩前85G存储文件，收缩后34G存储文件，节省了51G存储空间，大大提升了性能

我们为什么要迁移MongoDB？ 并发/存储量变大，MongoDB服务开始不稳定 高峰期 怎么办？ Mongod CPU占用高 机器负载高 系统态 机器负载高 多次出现，对业务影响大 短期内没有很好的应对措施 Mongod进程本身 Mongos节点高并发挂掉 怎么办？ 转型？！ Mongob+SSD（成本高） MySQL+Cache（稳定、可靠） 业务应用场景可以满足

MongoDB到MySQL的无缝迁移架构设计及实践 数据类型 时效性数据 过期作废(1个月) 迁移简单 核心数据 永久有效 迁移复杂

MongoDB到MySQL的无缝迁移架构设计及实践 时效性数据迁移方案 时效性数据 过期作废(1个月) Write Read Mongo MySQL

MongoDB到MySQL的无缝迁移架构设计及实践 核心数据迁移方案 核心数据 永久有效 Write Read MySQL Mongo 消息队列 Mongo-S

迁移后MySQL架构相比于MongoDB架构线上情况对比 迁移后效果对比