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

栏目: 数据库 · 发布时间: 5年前

内容简介:最近 InfoQ 发布了“别了,MongoDB”(翻译自卫报作者 Philip McMahon 等发表的英文博客其实这是卫报 10 年来第二次数据库迁移,第一次是从 Oracle。我们来看下这几年的事件回放:(上述内容摘自于

最近 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 用户。


以上就是本文的全部内容,希望对大家的学习有所帮助,也希望大家多多支持 码农网

查看所有标签

猜你喜欢:

本站部分资源来源于网络,本站转载出于传递更多信息之目的,版权归原作者或者来源机构所有,如转载稿涉及版权问题,请联系我们

Code Complete

Code Complete

Steve McConnell / Microsoft Press / 2004-6-19 / GBP 40.99

在线阅读本书 Widely considered one of the best practical guides to programming, Steve McConnells original CODE COMPLETE has been helping developers write better software for more than a decade. Now......一起来看看 《Code Complete》 这本书的介绍吧!

随机密码生成器
随机密码生成器

多种字符组合密码

HTML 编码/解码
HTML 编码/解码

HTML 编码/解码

XML、JSON 在线转换
XML、JSON 在线转换

在线XML、JSON转换工具