每天200亿次查询 – MongoDB在奇虎360【转】

100多个应用，1,500多个实例，每天200亿次查询

奇虎是中国最大的安卓移动发布平台。奇虎也是中国最顶尖的病毒软件防护公司，同时为网络以及移动平台提供产品。自从2011年成为MongoDB的用户之后，奇虎已经在MongoDB上构建了100多个不同的应用，其中包括新服务以及从MySQL和Redis上迁移过来的服务——每天都会在MongoDB上运行超过1, 500个实例并且支持200亿次查询。

我很高兴能够有一个机会与奇虎的高级DBA——杨艳杰进行交流，了解更多关于他们使用MongoDB的过程及原因、他们的最佳实践以及为那些刚开始使用MongoDB的用户提供的建议。

问：请您先向我们简单介绍一下奇虎。

奇虎360技术有限公司是一个领先的中国互联网公司。在2014年6月末，我们已经拥有了大约5亿的月活跃电脑端互联网用户以及6.4亿以上移动用户。

将识别病毒软件防护视为所有互联网及移动用户的一个基本需求，我们通过提供全方位高效、人性化的互联网和移动安全产品及服务来保护用户的电脑及移动设备，以防范病毒软件及网站攻击，最后形成了庞大的用户基础。我们的产品及服务由基于云的安全技术支持，而在我们看来，这项技术是在病毒软件防护产业最先进和健康的技术之一。我们通过为用户集群提供在线广告以及互联网增值服务来盈利。

在市场地位方面，我们是：

• 就用户基数而言，中国前三的互联网公司；
• 中国最大的基于安卓的移动发布平台；
• 中国最大的互联网及移动病毒软件防护产品及服务提供商；
• 中国第二的个人电脑搜索引擎。

问：奇虎是什么时候开始使用MongoDB的？

我们是MongoDB非常早的尝试者，在2011年的时候就已经在MongoDB上构建了第一个应用。我想，那个时候我们使用的是MongoDB 1.8！

问：如今，奇虎如何使用MongoDB？

MongoDB已经成为我们标准的现代数据库平台。我们已经在MongoDB上构建了一百多个应用——包括外部面向用户的服务以及内部商业应用。

总的说来，在我们内部搭建的“HULK”云平台上，每天都运行着1,500多个实例以及共计200亿次查询。

我们业务中三个特别典型的应用为：

1. 基于位置的移动搜索应用。我们通过使用MongoDB的地理空间索引及查询来向移动用户发送基于地理的搜索结果。用户有可能在搜索任何东西：从一个当地的饭店，到一辆车的代理权。该应用将会检测到用户的位置，然后基于距离为用户提供索索结果。在这个应用中，MongoDB每天都会处理12亿次的查询。
2. 用户认证数据的缓存层。对于很多中国网络用户而言，奇虎是一个核心的门户网站。在登录我们的网站之后，我们的用户可以直接连接到其它许多合作网站。我们为用户提供了多重服务的单点登录（SSO），因此在浏览相关网站的过程中，用户可以不需要一直提供他们的安全认证信息。为了更快地读取，用户的单点登录会话被存储到MongoDB中。MongoDB可以支持成千上万的并行用户，每秒钟大致可以处理3万个操作以及每天支撑18亿次的查询。
3. 日志分析平台。我们需要了解业务是否在正常运行。此外，内部业务人员也希望通过新的促销策略和活动来了解用户的参与度。为了实现上述功能，我们从Linux、Apache网页服务器以及Tomcat服务器上收集所有的日志数据，并将其直接流式传输到MongoDB中。从上述数据中，公司内部的业务人员可以使用基于PHP的商务智能（BI）平台生成实时的分析及报表。在任何时候，MongoDB中在18个分片中存储着25亿的文档，并且通过三个节点的复制集保证了实时的可获得性。MongoDB每天都会为其处理10亿次的写操作。

问：您们还使用了什么其它的数据库？

MongoDB是我们使用较多的三种数据库（MySQL,Redis,MongoDB）之一，但在一些场景中MongoDB并不适用。例如我们使用MySQL来解决关系型数据问题及一些需要事务的场景，使用Redis来解决一些高并发及缓存场景。随着时间的推移，我们已经将一些更适合MongoDB的业务从MySQL和Redis迁移到MongoDB中。

问：什么因素推动着这些迁移？

我们始终希望在每个场景中使用最适合该场景的数据库，对于某些场景下的MySQL而言，迁移的原因是我们希望提高该场景下的数据库可扩展性，例如在用户量增长到亿级的时候，在一些场景中MySQL的扩展性可能会成为瓶颈，因为作为一个关系型数据库，MySQL无法简单方便的进行扩展。

而另一些迁移是因为某些场景中的开发需求不够确定或是变更频繁，MongoDB的数据模型非常灵活。在这需求多变的场景中，我们的开发人员们使用MongoDB能够实现更快的开发迭代。

对于Redis而言，迁移的两个主要原因是：成本及灵活性。在一些QPS并不是很高的场景中，我们认为MongoDB能够满足此类需求。因为MongoDB使用磁盘存放数据，所以这对于使用内存来存放数据的Redis，迁移到MongoDB后我们能够存放更多的数据并大大降低服务器成本。此外，相对于Redis的K-V模型我们可以使用MongoDB的文档数据模型实现更多的功能。所以对于那些QPS并不是很高但数据体积很有可能快速增长的应用，我们会优先选择MongoDB。

问：请您介绍一下在MongoDB上运行的平台。

我们的大部分应用都是基于PHP的，我们在x86的硬件上运行CentOS系统。此外，我们的MongoDB全部使用SSD并进行了标准化，这给我们带来的很棒的性能。目前我们使用的是MongoDB 2.4版本以及最新的2.6版本。我们也非常期待即将到来的MongoDB 3.0。

问：您们是如何配置MongoDB的？

视应用的具体情况而定，复制集和分片集我们都有使用。我们的机房分布在全国各地，主要机房在北京。为了提高灾难恢复速度并降低本地机房的读写延迟，我们会将MongoDB部署在多个机房中。

在这种多机房的场景中，网络质量是最不可控的。而MongoDB集群对网络质量要求较高。所以对于关键应用，我们会在多个数据中心部署独立的集群，并使用我们自己开发的集群间数据同步工具来维护多个MongoDB集群数据的一致性，这样就能降低网络质量带来的影响，在机房间网络中断时仍然保持高可用。

问：您们如何管理MongoDB的部署？

我们使用HULK私有云平台对所有的mongodb进行管理，HULK私有云平台是支撑360重要业务线的技术平台，在最初起名的时候，我们希望它能够让我们的工程师踩在巨人的肩膀上成长–借助平台技术优势加速产品开发的流程。所以最终我们使用了HULK这个绿巨人的名字。HULK目前提供了弹性Web、RDS、NoSQL、分布式存储等基础服务，同时以开放平台的理念将360内部各团队的技术成果进行平台化改进，为各业务线提供可以拿来即用的服务，并帮助业务线在效率和技术深度上得到很大提升。

MongoDB是HULK中非常重要的服务之一，为此我们在HULK上做了大量的功能开发，目前已经达到了较高的自动化程度：对于管理者而言，dba能够通过HULK管理端进行一键部署、一键扩容（我们将大部分需要多个复杂步骤才能完成的工作变为了一键完成），而对应的备份、监控模块都是全自动的，例如当你将一个新的mongoDB集群或是节点部署之后HULK会自动的为它们添加对应的监控、备份策略。而对于用户（我们的后端开发工程师）而言，他们能够通过HULK用户端看到mongoDB的多种状态，并能够通过用户端直接提交工单，在大多数场景下我们与工程师们已不需要通过IM、邮件来进行需求沟通，他们只需要在HULK点几下鼠标，填几个选项即可。

问：您们如何备份MongoDB？

我们使用一系列备份策略，具体由应用的恢复点目标及恢复时间目标决定：

• 全量备份：这是默认的备份方式。我们将会关闭一个复制集成员，然后进行备份。
• 增量备份：我们开发了一套基于mongodb OPLOG的增量备份方案，其中有增量备份工具及恢复工具
• 延迟复制：在某些特殊场景中，对数据恢复的时间有着很高的要求。所以对于该场景我们使用延迟复制策略来降低数据恢复时间。

问：您能和我们分享一下在扩展MongoDB基础设施的最佳实践吗？

在这里，我想和大家分享三个小建议：

1. 尽量去了解业务的使用场景、数据量、QPS。开发通常会给出大致的需求，但通常这是非常不准确的，一个非常不准确的评估很可能导致后期手忙脚乱，所以我一般会在他们的需求上增加50%再进行评估。
2. 尽量使用SSD来承载对于请求耗时敏感的业务，因为MongoDB的内存管理原理导致它在大多数场景下很依赖磁盘性能，所以有时候DBA的辛苦调优及开发对于程序逻辑的反复修改得到的收益远不如换一块SSD来的快。
3. MongoDB的数据空间分配、使用方式导致在高写入、删除场景下会产生比较多的磁盘碎片，尽量关注磁盘碎片的体积并在适当的时候进行回收。

问：您是否衡量过MongoDB对您业务的影响？

是的，就业务上线周期而言，MongoDB给我们带来影响的一个例子是一一公司业务线对于2014年发生在云南省地震的响应速度。当时国内每一个人都希望了解到最新的消息，很多人希望能够尽快联系到在地震灾区的朋友及家人。公司认为实现该需求的最好方式是构建一个应用，并整合来自多个消息源的动态信息。

于是我们在地震发生后的那天上午就设计好了这个应用，开发同事们中午就写好了代码，下午该应用就正式发布了。它从一个概念到实际产生只用了不到一个工作日，MongoDB数据结构的灵活性帮了大忙！

问：您是否期待MongoDB 3.0？

在得到第一个候选版本发布之后，我们就立即开始对MongoDB 3.0进行测试并且向MongoDB公司汇报了一些我们发现的BUG。

我们很期待文档级的并发控制。这将进一步提高写操作的可扩展性并满足我们一些写入密集业务的需求。此外，压缩对我们而言也是一个非常好的功能。因为我们的MongoDB服务器全部使用了SSD，所以压缩意味着我们在同一个磁盘上存储更多的数据，这将大大降低我们的成本。

问：对于那些正在考虑在他们下一个项目上使用MongoDB的用户，您有什么建议？

MongoDB的文档数据模型有着很高的灵活性，该特性为开发带来了极大的便捷。但这同样代表着更多的责任一一MongoDB的灵活性会让开发变懒，请绝对不要滥用这种灵活性。我建议大家不要在一个集合中存储多个维度或是数据结构变化太多的文档，因为这将会使后期的维护变得异常复杂。将不同类型及结构的文档分散存放在他们自己的集合中是正确的做法。我们为此开发了一个文档扫描抽样分析工具，它能够找出异常的集合，比如该集合中的平均文档体积过大、结构过于复杂、结构不规范等。然后我们会通知相关的开发人员，并协助他们进行调整。这就是我开始提到的地方。