最近InfoQ发布了“别了，MongoDB”  一文引起比较大的反响。如果关心技术社区的朋友们都知道，圈子里时不时会冒出一篇 (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配置，异常复杂
  • 关系型数据库难以进行性能扩展


这个分享成了当时一个很大的成功案例，为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   -\u0026gt; 无缝迁移工具  -\u0026gt; 数据库托管服务
这个方案可以完美解决：

  1. 1NTP 或类似的问题
  2. 数据库管理（托管服务的基本价值）
  3. 应用程序构建索引（oops 不行, 这种自己挖坑自己踩的，哪个云平台恐怕都解决不了）

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

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

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

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

徐雷 中文社区联席主席 MongoDB实战指南翻译者
刘诚杰 中文社区上海分会长 平安集团高级DBA
李丹 中文社区北京分会长 逻辑思维首席DBA
周李洋 中文社区联席主席, MongoDB Master,  Teambition 运维总监
唐建法 中文社区主席