58同城作为中国最大的生活服务平台，涵盖了房产、招聘、二手、二手车、黄页等核心业务。58同城发展之初，大规模使用关系型数据库（SQL Server、MySQL等），随着业务扩展速度增加，数据量和并发量演变的越来越有挑战，此阶段58的数据存储架构也需要相应的调整以更好的满足业务快速发展的需求。
MongoDB经过几个版本的迭代，到2.0.0以后，变的越来越稳定，它具备的高性能、高扩展性、Auto-Sharding、Free-Schema、类SQL的丰富查询和索引等特性，非常诱惑，同时58同城在一些典型业务场景下使用MongoDB也较合适，2011年，我们开始使用MongoDB，逐步扩大了使用的业务线，覆盖了58帮帮、58交友、58招聘、信息质量等等多条业务线。
随着58每天处理的海量数据越来越大，并呈现不断增多的趋势，这为MongoDB在存储与处理方面带来了诸多的挑战。面对百亿量级的数据，我们该如何存储与处理，本文将详细介绍MongoDB遇到的问题以及最终如何“完美”解决。
本文详细讲述MongoDB在58同城的应用实践：MongoDB在58同城的使用情况；为什么要使用MongoDB；MongoDB在58同城的架构设计与实践；针对业务场景我们在MongoDB中如何设计库和表；数据量增大和业务并发，我们遇到典型问题及其解决方案；MongoDB如何监控。
MongoDB在58同城的使用情况
MongoDB在58同城的众多业务线都有大规模使用：58转转、58帮帮、58交友、58招聘、58信息质量、58测试应用等，如[图1]所示。
相关厂商内容
华为软件开发云专区全新上线！
Airbnb 的通用数据产品平台架构开发设计思路
Apache Beam 大规模乱序流数据处理
Apache Kafka：大数据的实时处理分析实战
阿里新一代实时计算引擎 Blink 典型的场景应用
图1 MongoDB典型的使用场景：转转
为什么要使用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中的一对一、一对多、多对多关系在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等。前百度高级工程师，参与社区搜索部多个基础系统的设计与实现。
感谢杜小芳对本文的审校。
原文地址:http://www.infoq.com/cn/articles/app-practice-of-mongodb-in-58-ten-billion-scale-data
网友评论