Leaf in the Wild:MongoDB 助力奇虎扩展

100 多款应用、1500 多个实例、每天 200 亿次查询

奇虎是中国首屈一指的 Android 移动分发平台。奇虎也是中国顶尖的恶意软件防护公司,同时为 Web 和移动平台提供产品。自从 2011 年成为 MongoDB 的用户以来,奇虎已在 MongoDB 上生成了 100 多种不同的应用程序(包括新服务以及从 MySQL 和 Redis 迁移的服务),在 1500 多个实例上运行,并且支持每天 200 亿次查询。

我有机会能够与奇虎高级 DBA 杨艳杰进行交流,详细了解他们使用 MongoDB 的方式及原因、他们的扩展最佳实践以及为那些刚开始使用 MongoDB 的用户提供的建议。

请您先向我们介绍一下奇虎。
奇虎 360 科技有限公司是中国领先的互联网公司。在 2014 年 6 月末,我们已经拥有了大约 5 亿的月活跃电脑互联网用户以及超过 6.4 亿的移动用户。

将恶意软件防护视为所有互联网及移动用户的基本需求后,我们通过提供全方位高效、人性化的互联网和移动安全产品及服务来保护用户的计算机及移动设备,以防范恶意软件及网站攻击,最终形成了庞大的用户群。我们的产品及服务由基于云的安全技术支持,在我们看来,这项技术是在恶意软件防护产业最先进和最可靠的技术之一。我们通过为用户群提供在线广告以及互联网增值服务来盈利。

在市场地位方面,我们是:

  • 中国前三的互联网公司(就用户基数而言)
  • 中国最大的基于 Android 的移动分发平台
  • 中国最大的互联网及移动恶意软件防护产品及服务提供商
  • 中国第二的 PC 搜索引擎

奇虎从什么时候开始使用 MongoDB?
我们很早就开始使用 MongoDB,2011 年就已经在 MongoDB 上生成了第一个应用程序。我想,那个时候我们使用的应该是版本 1.8。

如今奇虎如何使用 MongoDB?
MongoDB 已经成为我们标准的现代数据库平台。我们现在有 100 多个应用程序均由 MongoDB 提供支持,其中包括对外面向用户的服务以及内部业务应用程序。

总的说来,在我们内部搭建的“HULK”云平台上运行着 1500 多个 MongoDB 实例以及每天共计 200 亿次查询。
我们业务中三个特别关键的应用程序为:
  1. 基于位置的移动搜索应用程序。我们通过使用 MongoDB 的地理空间索引及查询来向移动用户提供基于地理的搜索结果。用户有可能搜索任何内容:从本地餐馆、商店,到汽车经销商。此应用将检测到用户位置,然后根据距离远近为用户提供搜索结果。在这个应用程序中,MongoDB 每天都会处理 12 亿次查询。
  2. 用户身份认证数据的缓存层。 对于许多中国互联网用户而言,奇虎是一个核心门户。在登录我们的网站之后,用户可以直接连接到许多合作伙伴网站。我们为用户提供了多重服务单一登录 (SSO),因此在浏览相关网页时,用户无需反复提供安全凭据。为更快地访问,用户的 SSO 会话会缓存在 MongoDB 中。MongoDB 可以支持数百万并发用户,每秒可以处理 3 万个操作,每天处理 18 亿次查询。
  3. 日志分析平台。 我们需要了解基础结构是否运行良好。此外,内部业务人员也希望通过新的促销策略和活动来衡量用户参与度。为实现上述目的,我们从所有的 Linux、Apache Web 服务器以及 Tomcat 服务器上收集日志数据,并将其直接流式传输到 MongoDB 中。从上述数据中,我们的内部业务人员可以使用基于 PHP 的商业智能 (BI) 平台生成实时的分析及报表。在任一时刻,MongoDB 都在 18 个分片中存储着 25 亿份文档,并且通过三个节点的复制集配置保证了实时的可获取性。MongoDB 每天都会处理将近 30 亿次查询,包括 10 亿次写操作。
你们还使用了其他什么数据库?
MongoDB 是我们在公司中使用的三种数据库之一。但它不一定适合所有应用领域,所以我们也使用 MySQL 处理关系型数据问题,使用 Redis 处理某些缓存用例。随着时间的推移,我们已经将十几个项目从 MySQL 和 Redis 迁移到 MongoDB 中。

是什么因素推动了这些迁移?
我们的目标是将最好的技术用在最适合的地方。就 MySQL 而言,迁移原因是扩展性和开发人员生产力。作为一个关系型数据库,MySQL 无法横向扩展。因此,随着用户群增长到 1 亿活跃用户时,我们就达到了 MySQL 可以承载的上限。MongoDB 自动分片支持我们使用商用硬件按需扩展。

MongoDB 数据模型也更加灵活。相较于关系模型,使用 MongoDB 能够让我们的开发人员完成更多任务,实现更快的迭代开发。

对于 Redis 而言,迁移原因是成本及灵活性。我们发现 MongoDB 能够满足许多应用程序的低延迟缓存要求,同时它的磁盘暂留使我们无需部署配有高内存占用量的高成本系统。此外,相对于 Redis 的“键值”模型,我们可以使用 MongoDB 的文档数据模型实现更多功能。这可直接转换为更丰富的应用程序功能。对于数据量会快速增加的应用程序,我们会选择 MongoDB 而非 Redis。

请介绍一下你们运行 MongoDB 的平台。
我们的大部分应用程序都基于 PHP。我们在 x86 硬件上运行 CentOS。我们对本地 SSD 存储进行了标准化,因为这会给我们带来最佳性能。我们运行的是 MongoDB 2.4 以及最新的 2.6 版本。我们也非常期待 MongoDB 3.0。

你们如何配置 MongoDB?
我们运行了单复制集和分片集群,具体视应用程序而定。我们的数据中心分布在全国各地,主要的数据中心在北京。为了提高灾难恢复速度并降低本地读写延迟,我们将 MongoDB 部署到多个数据中心的私有云上。

我们并未控制自己的光纤,因此网络质量不可控制。对于最关键的应用,我们在多个数据中心内部署相同集群,并使用我们自己的消息队列在它们之间进行复制,这可保证在面临网络分区时维持可用性。

你们如何管理 MongoDB 部署?
我们开发了名为 HULK 云平台的集中式业务流程 Web 平台。我们几乎所有的技术工程师都用它来控制关键任务型基础结构和服务。它是一项复杂的工程,我们对此深感骄傲。最初启动云平台项目时,我们希望它能够让我们的工程师站在巨人的肩膀上成长,借助此平台将应用程序加速推向市场。因此我们我们将其命名为“HULK”(美国漫画超级英雄)。

HULK 目前提供了 Web、关系型数据库、NoSQL 及分布式存储等弹性服务。同时,开放平台的理念吸引了各内部团队将他们的应用程序移动到该平台上。为这些应用程序重新改造平台可支持各团队从内部直接访问其他 LoB,并且在此过程中我们可以帮助业务组在效率和技术专长方面得到很大提升。

MongoDB 是 HULK 中最重要的服务之一,并且它已完全集成到高度自动化的平台,让我们可以仅使用 1.5 个 DBA 即可操作 1500 多个 MongoDB 实例。DBA 能够通过 HULK 管理界面执行“一键部署”和“一键升级”任务。所有备份和监视完全自动执行。例如,当你添加了一个新的 MongoDB 节点或集群后,HULK 将自动配置监视和备份策略,并且部署所需代理。而对于开发人员而言,他们可以监视大量的 MongoDB 指标和状态。此外,他们已不再需要使用电子邮件或者 IM 进行沟通,只需要在管理门户上打开一个工单,点几下鼠标即可。

你们如何备份 MongoDB?
我们结合使用了一系列方法,具体由应用程序的 RPO 和 RTO 目标决定:

  • 文件系统备份。这是默认方法。我们将关闭一个次要的复制集成员,然后捕获文件系统映像的快照
  • 增量复制。对于连续备份,我们生成了一个跟踪 MongoDB Oplog 的工具。我们将此方法用于需要更快还原服务的更为关键的应用
  • 延迟复制。我们使用此方法以提供额外保证,依然由需要恢复数据的速度决定是否使用

您能分享一下扩展 MongoDB 基础结构的最佳实践吗?
在这里,我想分享三个技巧:

  1. 从 DBA 的角度而言,应花费时间去了解应用程序使用情况。开发人员会提供指导,但我们通常会在采用他们提供给我们的任何数字后,在此基础上再增加 50%。
  2. 如果遇到了性能问题,从硬件着手解决。我们发现从硬盘升级到 SSD 能够快速提升性能,而不用进行任何其他优化。
  3. 对于高度动态、写入密集的工作载荷,确保定期监视存储碎片并根据需要进行压缩。

你们是否衡量过 MongoDB 对业务的影响?
是的,在推向市场的时间方面衡量过。MongoDB 给我们带来影响的一个示例是我们对 2014 年云南地震的反应速度。当时国内每一个人都希望了解到最新消息,很多人希望能够尽快联系到当地的朋友和家人。公司认为实现此需求的最好方式是生成一个应用,并整合来自多个消息源的信息流。

于是我们在地震发生的那天上午就设计好了这个应用、下午就写好了代码,晚上正式发布。从一个概念到实际生产只用了一个工作日。只有 MongoDB 可以支持这种开发速度。

您是否期待 MongoDB 3.0?
在我们获取第一个候选版本后,我们就立即开始对 MongoDB 3.0 进行测试并且反馈了一些 Bug。

我们非常期待文档级的并发控制。这将进一步提升写入操作的扩展性,并完全融入我们现在使用的最新一代的密集多核心系统。此外,压缩也能够为我们带来巨大优势。由于我们对 SSD 进行了标准化,因此压缩意味着我们可以在一个驱动器上存储更多数据,从而降低成本。这也将提升性能,因为从磁盘读取的位数会减少,从而更好地利用磁盘 I/O 周期。

对于那些考虑将 MongoDB 用于下一个项目的用户,您有什么建议?
MongoDB 的文档数据模型和动态架构带来了很高的灵活性和强大的功能。但这同样带来了更多的责任。我建议不要在一个集合中存储许多不同的文档类型和格式,因为这会使正在进行中的应用程序维护变得复杂。将不同类型的文档拆分并组织到它们自己的集合中。我们已实现了在每个集合中对文档进行扫描并抽样检查的工具。如果结构中的方差超出了最佳实践范围,我们将向开发人员告警,于是他们就会采取行动来解决问题。这就是我开始提到的地方。

杨先生,感谢您抽出时间与 MongoDB 社区分享您的见解。


还在艰难地扩展关系型数据库?下载我们的“迁移白皮书”:
迁移白皮书

关于作者 - Mat Keep

Mat 是 MongoDB 产品营销团队的一员,负责为 MongoDB 产品和服务构建愿景、定位和内容,包括分析市场趋势和客户要求。加入 MongoDB 前,Mat 是 Oracle Corp. 的产品管理主管,负责与 Web、电信、云和 Big Data 工作负荷有关的 MySQL 数据库。下属职位包括技术供应商和最终用户公司的一系列销售、业务发展和分析员/程序员职位。