英国卫报迁移， MongoDB 躺枪背锅？MongoDB 中文社区有话说

最近 InfoQ 发布了“别了，MongoDB”（翻译自卫报作者 Philip McMahon 等发表的英文博客 https://www.theguardian.com/info/2018/nov/30/bye-bye-mongo-hello-postgres）  一文引起比较大的反响。如果关心技术社区的朋友们都知道，圈子里时不时会冒出一篇 (MySQL | PostgreSQL | MongoDB ) 迁移到 (MySQL | PostgreSQL | MongoDB ) 的文章。有些时候因为选型不当，有些是因为时间的变迁导致场景变化，有些时候是因为有更先进的技术或者更适用产品出现。这些其实都符合技术正常变革的自然规律。但是卫报的这篇文章加上前不久的 58 简历泄露事件，让 MongoDB 中文社区的核心成员们觉得有必要站出来澄清事实，以防止标题党语不惊人死不休，以流量为目的，完全无顾于技术的科学性和严肃性。

卫报迁移事件解析

其实这是卫报 10 年来第二次数据库迁移，第一次是从 Oracle。我们来看下这几年的事件回放：

1. 2011 年 4 月，卫报成为最早的 MongoDB 用户之一，成功上线其构建在 MongoDB 之上的内容管理系统。

2. 2011 年 11 月，在 QCon 的一次大会上，Guardian 的 Mat Wall 分享了他们选择 MongoDB 的原因：

• 数据库 schema 经常需要升级，升级意味着编辑们无法使用系统

• 基于 Oracle 的老系统 300 多张表，10，000 多行 Hibernate XML 配置，异常复杂

• 关系型数据库难以进行性能扩展

（上述内容摘自于

https://www.infoq.com/presentations/Why-I-Chose-MongoDB-for-Guardian）

这个分享成了当时一个很大的成功案例，为 MongoDB 成为 Gartner CMS 魔力象限中排名第一第二的 Adobe Experience Manager 及 Sitecore 两个 CMS 系统不约而同选用的数据库奠定了基础。

3. 2015 年，卫报因为自己数据中心的备份系统出问题而决定把数据中心迁移到 AWS 云上。注意，此时为止并没有出现什么运维事故。

4. 搬到 AWS 上以后，发生了两次运维事故，一次是因为 NTP 始终服务被中断导致的，一次是因为他们在应用程序启动时创建索引导致的。

5. 2017 年， 以 Philip McMahon 为首的 IT 团队开始了为期 10 个月的迁移工作，从基于 AWS 的 MongoDB 迁移到 AWS 的 PostgreSQL。Philip 列出了以下理由：

• 这两年在 AWS 云里出了两次运维故障

• MongoDB OpsManager 未能兑现“无障碍数据管理”

• 官方未能及时帮助他解决问题，最终是自己解决了

6. Philip 团队在花了 10 个月时间的努力之后，终于把他们系统的数据库迁移到了 AWS 的 PostgreSQL，随后就发表了 bye-bye MongoDB 的博客。

好了，至此我们就了解大概情况了。

中文社区有话要说

1. Philip 的第一个要迁移的原因：NTP 导致的运维故障。 MongoDB 是分布式集群，需要时间统一，你自己在 VPC 里面不小心把 NTP 时钟服务中断了导致集群不能正常工作，这是谁的锅呢？

2. Philip 的第二个要迁移的原因： 应用程序启动时构建索引导致服务不可用。关于这一点，如果是一个读的懂英文文档的开发者都会知道，无论是使用 Spring 或者 Node.js，都会提到并不建议在程序里来创建索引。 构建索引消耗很多资源并且执行时间不可控，按照 MongoDB 最佳实践是要在复制集内进行滚动构建。实际上使用 OpsManager 就可以很容易实现滚动建索引。这一点他自己也意识到了“可能不是一个好主意”。恩，怪我咯？

3. Philip 的第三个要迁移的原因：数据库管理很重要而且很难。所以我们要换一个数据库，从 MongoDB 换到 PostgreSQL。因为 PostgreSQL 不是数据库， 就不用管理了？

4. 没有比较就没有伤害，和上面提到的 Mat Wall 的 Oracle 迁移到 Mongo 的言之凿凿的原因比较，Philip 的 3 大原因没有一条是真正和 MongoDB 数据库本身技术相关的。MongoDB 丢了数据吗？MongoDB 自己崩溃了吗？ 作为卫报这个知名媒体，可以有一点逻辑吗？

5. 在卫报迁移到 AWS 之前，MongoDB 运行都是正常的。所有的问题反而是在 AWS 里发生的，特别是关于 VPC。这说明了卫报 IT 团队在云管理能力上有所欠缺。按照他们的理论，亚马逊多半也没有实现“云让你不用再管理你自己的基础架构”的口号吧？是不是也该从 AWS 迁移走呢？

写到这里，相信读者已经能够有所甄别。Philip 团队真正的痛点是他们无足够的能力，也无意在这方面去增强自己的能力来维运自己的 MongoDB 集群。这个出发点本身并无诟病，这是 SaaS/PaaS 平台存在的意义。MongoDB 自己就提供基于 AWS 的托管服务，支持线下到云中的无缝迁移。Philip 确实提到了有一个超出他决策范围的非技术原因（来自编辑部）让他无法选择该服务。换句话说，如果没有编辑部的外在影响，Philip 的完美解决方案就是：

卫报自管理的 AWS MongoDB   -> 无缝迁移工具  -> 数据库托管服务

这个方案可以完美解决：

1. 1NTP 或类似的问题

2. 数据库管理（托管服务的基本价值）

3. 应用程序构建索引（oops 不行, 这种自己挖坑自己踩的，哪个云平台恐怕都解决不了）

这种迁移由于不涉及到代码改动，所需工作会大大减少。我们不知道 Philip 开始迁移方案的时候有没有预料到会花费整个团队 10 个月的时间，而且可能是 Sleepless 的 10 个月。但如果是在无缝迁移工具的帮助下，那么这个切换可以在数天内完成。

所以，如果我们更客观的来看，卫报作者发的那篇文章的题目其实更应该叫做：

别了，自运维数据库，拥抱云托管数据库。

MongoDB 中文社区参与撰稿成员：

徐雷 中文社区联席主席 MongoDB 实战指南翻译者

刘诚杰 中文社区上海分会长 平安集团高级 DBA

李丹 中文社区北京分会长 逻辑思维首席 DBA

周李洋 中文社区联席主席, MongoDB Master,  Teambition 运维总监

唐建法 中文社区主席

关于 MongoDB 中文社区

MongoDB 中文社区(mongoing.com) 成立于 2014 年，是大中华区获得官方认可的中文社区。社区由来自官方的工程师，阿里腾讯等大型互联网公司及业界 MongoDB 专家和 MongoDB 书籍作者等组成，。经过社区志愿者们的不断努力，目前已经有超过 2 万的线上及线下成员。中文社区由博客、线下活动、技术问答、微信/qq 群、官方文档翻译等版块组成，迄今为止已经举办了数十场线下活动和线上直播，发表了数百篇技术文章及文档，在社区里支持了数以万计的 MongoDB 用户。