转载：MongoDB 在 58 同城百亿量级数据下的应用实践

为何要使用 MongoDB？

MongoDB 这个来源英文单词“humongous”，homongous 这个单词的意思是“巨大的”、“奇大无比的”，从 MongoDB 单词自己能够看出它的目标是提供海量数据的存储以及管理能力。MongoDB 是一款面向文档的 NoSQL 数据库，MongoDB 具有较好的扩展性以及高可用性，在数据复制方面，支持 Master-Slaver（主从）和 Replica-Set（副本集）等两种方式。经过这两种方式可使得咱们很是方便的扩展数据。

MongoDB 较高的性能也是它强有力的卖点之一，存储引擎使用的内存映射文件（MMAP 的方式），将内存管理工做交给操做系统去处理。MMAP 的机制，数据的操做写内存便是写磁盘，在保证数据一致性的前提下，提供了较高的性能。

除此以外，MongoDB 还具有了丰富的查询支持、较多类型的索引支持以及 Auto-Sharding 的功能。在全部的 NoSQL 产品中，MongoDB 对查询的支持是最相似于传统的 RDBMS，这也使得应用方能够较快的从 RDBMS 转换到 MonogoDB。

在 58 同城，咱们的业务特色是具备较高的访问量，并能够按照业务进行垂直的拆分，在每一个业务线内部经过 MongoDB 提供两种扩展机制，当业务存储量和访问量变大，咱们能够较易扩展。同时咱们的业务类型对事务性要求低，综合业务这几点特性，在 58 同城使用 MongoDB 是较合适的。

如何使用 MongoDB？

MongoDB 做为一款 NoSQL 数据库产品，Free Schema 是它的特性之一，在设计咱们的数据存储时，不须要咱们固定 Schema，提供给业务应用方较高的自由度。那么问题来了，Free Schema 真的 Free 吗？

第一：Free Schema 意味着重复 Schema。在 MongoDB 数据存储的时候，不但要存储数据自己，Schema（字段 key）自己也要重复的存储（例如：{“name”:”zhuanzhuan”, “infoid”:1,“infocontent”:”这个是转转商品”}），必然会形成存储空间的增大。

第二：Free Schema 意味着 All Schema，任何一个须要调用 MongoDB 数据存储的地方都须要记录数据存储的 Schema，这样才能较好的解析和处理，必然会形成业务应用方的复杂度。

那么咱们如何应对呢？在字段名 Key 选取方面，咱们尽量减小字段名 Key 的长度，好比：name 字段名使用 n 来代替，infoid 字段名使用 i 来代替，infocontent 字段名使用 c 来代替（例如：{“n”:”zhuanzhuan”, “i”:1, “c”:”这个是转转商品”}）。使用较短的字段名会带来较差的可读性，咱们经过在使用作字段名映射的方式（ #defineZZ_NAME  ("n")），解决了这个问题；同时在数据存储方面咱们启用了数据存储的压缩，尽量减小数据存储的量。

MongoDB 提供了自动分片（Auto-Sharding）的功能，通过咱们的实际测试和线上验证，并无使用这个功能。咱们启用了 MongoDB 的库级 Sharding；在 CollectionSharding 方面，咱们使用手动 Sharding 的方式，水平切分数据量较大的文档。

MongoDB 的存储文档必需要有一个“_id”字段，能够认为是“主键”。这个字段值能够是任何类型，默认一个 ObjectId 对象，这个对象使用了 12 个字节的存储空间，每一个字节存储两位 16 进制数字，是一个 24 位的字符串。这个存储空间消耗较大，咱们实际使用状况是在应用程序端，使用其余的类型（好比 int）替换掉到，一方面能够减小存储空间，另一方面能够较少 MongoDB 服务端生成“_id”字段的开销。

在每个集合中，每一个文档都有惟一的“_id”标示，来确保集中每一个文档的惟一性。而在不一样集合中，不一样集合中的文档“_id”是能够相同的。好比有 2 个集合 Collection_A 和 Collection_B，Collection_A 中有一个文档的“_id”为 1024，在 Collection_B 中的一个文档的“_id”也能够为 1024。

MongoDB 集群部署

MongoDB 集群部署咱们采用了 Sharding+Replica-Set 的部署方式。整个集群有 Shard Server 节点（存储节点，采用了 Replica-Set 的复制方式）、Config Server 节点（配置节点）、Router Server（路由节点、Arbiter Server（投票节点）组成。每一类节点都有多个冗余构成。知足 58 业务场景的一个典型 MongoDB 集群部署架构以下所示 [图 2]：

图 2 58 同城典型业务 MongoDB 集群部署架构

在部署架构中，当数据存储量变大后，咱们较易增长 Shard Server 分片。Replica-Set 的复制方式，分片内部能够自由增减数据存储节点。在节点故障发生时候，能够自动切换。同时咱们采用了读写分离的方式，为整个集群提供更好的数据读写服务。

图 3 Auto-Sharding MAY is not that Reliable

针对业务场景咱们在 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 中的一对1、一对多、多对多关系在 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 开发的网络流量监测图形分析工具。

最后我要感谢公司和团队，在 MongoDB 集群的大规模实战中积累了宝贵的经验，才能让我有机会撰写了此文，因为 MongoDB 社区不断发展，特别是 MongoDB 3.0，对性能、数据压缩、运维成本、锁级别、Sharding 以及支持可插拔的存储引擎等的改进，MongoDB 愈来愈强大。文中可能会存在一些不妥的地方，欢迎你们交流指正。

讲师介绍

孙玄，极客邦培训专家讲师，58 同城系统架构师、技术委员会架构组主任、产品技术学院优秀讲师，58 同城即时通信、C2C 技术负责人，负责 58 核心系统的架构以及优化工做。分布式系统存储专家，2007 年开始从事大规模高性能分布式存储系统架构设计实现工做。涉及自主研发分布式存储系统、MongoDB、MySQL、Memcached、Redis 等。前百度高级工程师，参与社区搜索部多个基础系统的设计与实现。