英国卫报迁移， 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 系统不约而同选用的数据库奠定了基础。

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

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

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

• 这两年在 AWS 云里出了两次运维故障
• MongoDB OpsManager 未能兑现“无障碍数据管理”
• 官方未能及时帮助他解决问题，最终是自己解决了

1. 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 用户。