在MongoDB中如何设计库和表

MongoDB 本身提供了Auto-Sharding的功能，这个智能的功能作为 MongoDB 的最具卖点的特性之一，真的非常靠谱吗（图 3）？也许理想是丰满的，现实是骨干滴。

首先是在 Sharding Key 选择上，如果选择了单一的 Sharding Key，会造成分片不均衡，一些分片数据比较多，一些分片数据较少，无法充分利用每个分片集群的能力。为了弥补单一 Sharding Key 的缺点，引入复合 Sharing Key，然而复合 Sharding Key 会造成性能的消耗；

第二count 值计算不准确的问题，数据 Chunk 在分片之间迁移时，特定数据可能会被计算 2 次，造成 count 值计算偏大的问题；

第三Balancer 的稳定性 & 智能性问题，Sharing 的迁移发生时间不确定，一旦发生数据迁移会造成整个系统的吞吐量急剧下降。为了应对 Sharding 迁移的不确定性，我们可以强制指定 Sharding 迁移的时间点，具体迁移时间点依据业务访问的低峰期。比如 IM 系统，我们的流量低峰期是在凌晨 1 点到 6 点，那么我们可以在这段时间内开启 Sharding 迁移功能，允许数据的迁移，其他的时间不进行数据的迁移，从而做到对 Sharding 迁移的完全掌控，避免掉未知时间 Sharding 迁移带来的一些风险。

如何设计库（DataBase）？

我们的 MongoDB 集群线上环境全部禁用了 Auto-Sharding 功能。如上节所示，仅仅提供了指定时间段的数据迁移功能。线上的数据我们开启了库级的分片，通过 db.runCommand({“enablesharding”: “im”}); 命令指定。并且我们通过 db.runCommand({movePrimary:“im”, to: “sharding1”}); 命令指定特定库到某一固定分片上。通过这样的方式，我们保证了数据的无迁移性，避免了 Auto-Sharding 带来的一系列问题，数据完全可控，从实际使用情况来看，效果也较好。

既然我们关闭了 Auto-Sharding 的功能，就要求对业务的数据增加情况提前做好预估，详细了解业务半年甚至一年后的数据增长情况，在设计 MongoDB 库时需要做好规划：确定数据规模、确定数据库分片数量等，避免数据库频繁的重构和迁移情况发生。

那么问题来了，针对 MongoDB，我们如何做好容量规划？

MongoDB 集群高性能本质是 MMAP 机制，对机器内存的依赖较重，因此我们要求业务热点数据和索引的总量要能全部放入内存中，即：Memory > Index + Hot Data。一旦数据频繁地 Swap，必然会造成 MongoDB 集群性能的下降。当内存成为瓶颈时，我们可以通过 Scale Up 或者 Scale Out 的方式进行扩展。

第二：我们知道 MongoDB 的数据库是按文件来存储的：例如：db1 下的所有 collection 都放在一组文件内 db1.0,db1.1,db1.2,db1.3……db1.n。数据的回收也是以库为单位进行的，数据的删除将会造成数据的空洞或者碎片，碎片太多，会造成数据库空间占用较大，加载到内存时也会存在碎片的问题，内存使用率不高，会造成数据频繁地在内存和磁盘之间 Swap，影响 MongoDB 集群性能。因此将频繁更新删除的表放在一个独立的数据库下，将会减少碎片，从而提高性能。

第三：单库单表绝对不是最好的选择。原因有三：表越多，映射文件越多，从 MongoDB 的内存管理方式来看，浪费越多；同理，表越多，回写和读取的时候，无法合并 IO 资源，大量的随机 IO 对传统硬盘是致命的；单表数据量大，索引占用高，更新和读取速度慢。

第四：Local 库容量设置。我们知道 Local 库主要存放 oplog，oplog 用于数据的同步和复制，oplog 同样要消耗内存的，因此选择一个合适的 oplog 值很重要，如果是高插入高更新，并带有延时从库的副本集需要一个较大的 oplog 值（比如 50G）；如果没有延时从库，并且数据更新速度不频繁，则可以适当调小 oplog 值（比如 5G）。总之，oplog 值大小的设置取决于具体业务应用场景，一切脱离业务使用场景来设置 oplog 的值大小都是耍流氓。

如何设计表（Collection）？

MongoDB 在数据逻辑结构上和 RDBMS 比较类似，如图 4 所示：MongoDB 三要素：数据库（DataBase）、集合（Collection）、文档（Document）分别对应 RDBMS（比如 MySQL）三要素：数据库（DataBase）、表（Table）、行（Row）。

图 4 MongoDB 和 RDBMS 数据逻辑结构对比

MongoDB 作为一支文档型的数据库允许文档的嵌套结构，和 RDBMS 的三范式结构不同，我们以“人”描述为例，说明两者之间设计上的区别。“人”有以下的属性：姓名、性别、年龄和住址；住址是一个复合结构，包括：国家、城市、街道等。针对“人”的结构，传统的 RDBMS 的设计我们需要 2 张表：一张为 People 表 [图 5]，另外一张为 Address 表 [图 6]。这两张表通过住址 ID 关联起来（即 Addess ID 是 People 表的外键）。在 MongoDB 表设计中，由于 MongoDB 支持文档嵌套结构，我可以把住址复合结构嵌套起来，从而实现一个 Collection 结构 [图 7]，可读性会更强。

图 5 RDBMSPeople 表设计

图 6 RDBMS Address 表设计

图 7 MongoDB 表设计

MongoDB 作为一支 NoSQL 数据库产品，除了可以支持嵌套结构外，它又是最像 RDBMS 的产品，因此也可以支持“关系”的存储。接下来会详细讲述下对应 RDBMS 中的一对一、一对多、多对多关系在 MongoDB 中我们设计和实现。

IM 用户信息表，包含用户 uid、用户登录名、用户昵称、用户签名等，是一个典型的一对一关系，在 MongoDB 可以采用类 RDBMS 的设计，我们设计一张 IM 用户信息表 user：{_id:88, loginname:musicml, nickname:musicml,sign:love}，其中 _id 为主键，_id 实际为 uid。IM 用户消息表，一个用户可以收到来自他人的多条消息，一个典型的一对多关系。

我们如何设计？

一种方案，采用 RDBMS 的“多行”式设计，msg 表结构为：{uid，msgid，msg_content}，具体的记录为：123, 1, 你好；123，2，在吗。

另外一种设计方案，我们可以使用 MongoDB 的嵌套结构：{uid:123, msg:{[{msgid:1,msg_content: 你好}，{msgid:2, msg_content: 在吗}]}}。

采用 MongoDB 嵌套结构，会更加直观，但也存在一定的问题：更新复杂、MongoDB 单文档 16MB 的限制问题。采用 RDBMS 的“多行”设计，它遵循了范式，一方面查询条件更灵活，另外通过“多行式”扩展性也较高。

在这个一对多的场景下，由于 MongoDB 单条文档大小的限制，我们并没采用 MongoDB 的嵌套结构，而是采用了更加灵活的类 RDBMS 的设计。

在 User 和 Team 业务场景下，一个 Team 中有多个 User，一个 User 也可能属于多个 Team，这种是典型的多对多关系。

在 MongoDB 中我们如何设计？一种方案我们可以采用类 RDBMS 的设计。一共三张表：Team 表{teamid,teamname, ……}，User 表{userid,username,……}，Relation 表{refid, userid, teamid}。其中 Team 表存储 Team 本身的元信息，User 表存储 User 本身的元信息，Relation 表存储 Team 和 User 的所属关系。

在 MongoDB 中我们可以采用嵌套的设计方案：一种 2 张表：Team 表{teamid,teamname,teammates:{[userid, userid, ……]}，存储了 Team 所有的 User 成员和 User 表{useid,usename,teams:{[teamid, teamid,……]}}，存储了 User 所有参加的 Team。

在 MongoDB Collection 上我们并没有开启 Auto-Shariding 的功能，那么当单 Collection 数据量变大后，我们如何 Sharding？对 Collection Sharding 我们采用手动水平 Sharding 的方式，单表我们保持在千万级别文档数量。当 Collection 数据变大，我们进行水平拆分。比如 IM 用户信息表：{uid, loginname, sign, ……}，可用采用 uid 取模的方式水平扩展，比如：uid%64，根据 uid 查询可以直接定位特定的 Collection，不用跨表查询。

通过手动 Sharding 的方式，一方面根据业务的特点，我们可以很好满足业务发展的情况，另外一方面我们可以做到可控、数据的可靠，从而避免了 Auto-Sharding 带来的不稳定因素。对于 Collection 上只有一个查询维度（uid），通过水平切分可以很好满足。

但是对于 Collection 上有 2 个查询维度，我们如何处理？比如商品表：{uid, infoid, info,……}，存储了商品发布者，商品 ID，商品信息等。我们需要即按照 infoid 查询，又能支持按照 uid 查询。为了支持这样的查询需求，就要求 infoid 的设计上要特殊处理：infoid 包含 uid 的信息（infoid 最后 8 个 bit 是 uid 的最后 8 个 bit），那么继续采用 infoid 取模的方式，比如：infoid%64，这样我们既可以按照 infoid 查询，又可以按照 uid 查询，都不需要跨 Collection 查询。

数据量、并发量增大，遇到问题及其解决方案

大量删除数据问题及其解决方案

我们在 IM 离线消息中使用了 MongoDB，IM 离线消息是为了当接收方不在线时，需要把发给接收者的消息存储下来，当接收者登录 IM 后，读取存储的离线消息后，这些离线消息不再需要。已读取离线消息的删除，设计之初我们考虑物理删除带来的性能损耗，选择了逻辑标识删除。IM 离线消息 Collection 包含如下字段：msgid, fromuid, touid, msgcontent, timestamp, flag。其中 touid 为索引，flag 表示离线消息是否已读取，0 未读，1 读取。

当 IM 离线消息已读条数积累到一定数量后，我们需要进行物理删除，以节省存储空间，减少 Collection 文档条数，提升集群性能。既然我们通过 flag==1 做了已读取消息的标示，第一时间想到了通过 flag 标示位来删除：db.collection.remove({“flag” :1}}; 一条简单的命令就可以搞定。表面上看很容易就搞定了？！实际情况是 IM 离线消息表 5kw 条记录，近 200GB 的数据大小。

悲剧发生了：晚上 10 点后部署删除直到早上 7 点还没删除完毕；MongoDB 集群和业务监控断续有报警；从库延迟大；QPS/TPS 很低；业务无法响应。事后分析原因：虽然删除命令 db.collection.remove({“flag” : 1}}; 很简单，但是 flag 字段并不是索引字段，删除操作等价于全部扫描后进行，删除速度很慢，需要删除的消息基本都是冷数据，大量的冷数据进入内存中，由于内存容量的限制，会把内存中的热数据 swap 到磁盘上，造成内存中全是冷数据，服务能力急剧下降。

遇到问题不可怕，我们如何解决呢？首先我们要保证线上提供稳定的服务，采取紧急方案，找到还在执行的 opid，先把此命令杀掉（kill opid），恢复服务。长期方案，我们首先优化了离线删除程序 [图 8]，把已读 IM 离线消息的删除操作，每晚定时从库导出要删除的数据，通过脚本按照 objectid 主键（_id）的方式进行删除，并且删除速度通过程序控制，从避免对线上服务影响。其次，我们通过用户的离线消息的读取行为来分析，用户读取离线消息时间分布相对比较均衡，不会出现比较密度读取的情形，也就不会对 MongoDB 的更新带来太大的影响，基于此我们把用户 IM 离线消息的删除由逻辑删除优化成物理删除，从而从根本上解决了历史数据的删除问题。

图 8 离线删除优化脚本

大量数据空洞问题及其解决方案

MongoDB 集群大量删除数据后（比如上节中的 IM 用户离线消息删除）会存在大量的空洞，这些空洞一方面会造成 MongoDB 数据存储空间较大，另外一方面这些空洞数据也会随之加载到内存中，导致内存的有效利用率较低，在机器内存容量有限的前提下，会造成热点数据频繁的 Swap，频繁 Swap 数据，最终使得 MongoDB 集群服务能力下降，无法提供较高的性能。

通过上文的描述，大家已经了解 MongoDB 数据空间的分配是以 DB 为单位，而不是以 Collection 为单位的，存在大量空洞造成 MongoDB 性能低下的原因，问题的关键是大量碎片无法利用，因此通过碎片整理、空洞合并收缩等方案，我们可以提高 MongoDB 集群的服务能力。

那么我们如何落地呢？

方案一：我们可以使用 MongoDB 提供的在线数据收缩的功能，通过 Compact 命令（db.yourCollection.runCommand(“compact”);）进行 Collection 级别的数据收缩，去除 Collectoin 所在文件碎片。此命令是以 Online 的方式提供收缩，收缩的同时会影响到线上的服务，其次从我们实际收缩的效果来看，数据空洞收缩的效果不够显著。因此我们在实际数据碎片收缩时没有采用这种方案，也不推荐大家使用这种空洞数据的收缩方案。

既然这种数据方案不够好，我们可以采用 Offline 收缩的方案二：此方案收缩的原理是：把已有的空洞数据，remove 掉，重新生成一份无空洞数据。那么具体如何落地？先预热从库；把预热的从库提升为主库；把之前主库的数据全部删除；重新同步；同步完成后，预热此库；把此库提升为主库。

具体的操作步骤如下：检查服务器各节点是否正常运行 (ps -ef |grep mongod)；登入要处理的主节点 /mongodb/bin/mongo–port 88888；做降权处理 rs.stepDown()，并通过命令 rs.status() 来查看是否降权；切换成功之后，停掉该节点；检查是否已经降权，可以通过 web 页面查看 status，我们建议最好登录进去保证有数据进入，或者是 mongostat 查看； kill 掉对应 mongo 的进程： kill 进程号；删除数据，进入对应的分片删除数据文件，比如： rm -fr /mongodb/shard11/*；重新启动该节点，执行重启命令，比如：如:/mongodb/bin/mongod –config /mongodb/shard11.conf；通过日志查看进程；数据同步完成后，在修改后的主节点上执行命令 rs.stepDown() ，做降权处理。

通过这种 Offline 的收缩方式，我们可以做到收缩率是 100%，数据完全无碎片。当然做离线的数据收缩会带来运维成本的增加，并且在 Replic-Set 集群只有 2 个副本的情况下，还会存在一段时间内的单点风险。通过 Offline 的数据收缩后，收缩前后效果非常明显，如 [图 9, 图 10] 所示：收缩前 85G 存储文件，收缩后 34G 存储文件，节省了 51G 存储空间，大大提升了性能。

图 9 收缩 MongoDB 数据库前存储数据大小

图 10 收缩 MongoDB 数据库后存储数据大小

MongoDB 集群监控

MongoDB 集群有多种方式可以监控：mongosniff、mongostat、mongotop、db.xxoostatus、web 控制台监控、MMS、第三方监控。我们使用了多种监控相结合的方式，从而做到对 MongoDB 整个集群完全 Hold 住。

第一是 mongostat[图 11]，mongostat 是对 MongoDB 集群负载情况的一个快照，可以查看每秒更新量、加锁时间占操作时间百分比、缺页中断数量、索引 miss 的数量、客户端查询排队长度（读|写)、当前连接数、活跃客户端数量 (读|写) 等。

图 11 MongoDB mongostat 监控

mongstat 可以查看的字段较多，我们重点关注 Locked、faults、miss、qr|qw 等，这些值越小越好，最好都为 0；locked 最好不要超过 10%；造成 faults、miss 原因主要是内存不够或者内冷数据频繁 Swap，索引设置不合理；qr|qw 堆积较多，反应了数据库处理慢，这时候我们需要针对性的优化。

第二是 web 控制台，和 MongoDB 服务一同开启，它的监听端口是 MongoDB 服务监听端口加上 1000，如果 MongoDB 的监听端口 33333，则 Web 控制台端口为 34333。我们可以通过 http://ip:port（ http://8.8.8.8:34333 ）访问监控了什么 [图 12]：当前 MongoDB 所有的连接数、各个数据库和 Collection 的访问统计包括：Reads, Writes, Queries 等、写锁的状态、最新的几百行日志文件。

图 12 MongoDB Web 控制台监控

第三是 MMS（MongoDBMonitoring Service），它是 2011 年官方发布的云监控服务，提供可视化图形监控。工作原理如下：在 MMS 服务器上配置需要监控的 MongoDB 信息（ip/port/user/passwd 等）；在一台能够访问你 MongoDB 服务的内网机器上运行其提供的 Agent 脚本；Agent 脚本从 MMS 服务器获取到你配置的 MongoDB 信息；Agent 脚本连接到相应的 MongoDB 获取必要的监控数据；Agent 脚本将监控数据上传到 MMS 的服务器；登录 MMS 网站查看整理过后的监控数据图表。具体的安装部署，可以参考： http://mms.10gen.com 。

图 13 MongoDB MMS 监控

第四是第三方监控，MongoDB 开源爱好者和团队支持者较多，可以在常用监控框架上扩展，比如：zabbix，可以监控 CPU 负荷、内存使用、磁盘使用、网络状况、端口监视、日志监视等；nagios，可以监控监控网络服务（HTTP 等）、监控主机资源（处理器负荷、磁盘利用率等）、插件扩展、报警发送给联系人（EMail、短信、用户定义方式）、手机查看方式；cacti，可以基于 PHP,MySQL,SNMP 及 RRDTool 开发的网络流量监测图形分析工具。