最近InfoQ发布了“别了，MongoDB”（翻译自卫报作者Philip McMahon等发表的英文博客 ） 一文引起比较大的反响。如果关心技术社区的朋友们都知道，圈子里时不时会冒出一篇 (MySQL | PostgreSQL | MongoDB ) 迁移到 (MySQL | PostgreSQL | MongoDB ) 的文章。有些时候因为选型不当，有些是因为时间的变迁导致场景变化，有些时候是因为有更先进的技术或者更适用产品出现。这些其实都是符合技术正常变革的自然规律的。但是卫报的这篇文章加上前不久的58简历泄露事件，让MongoDB中文社区的核心成员们有必要站出来澄清下事实，以防止标题党语不惊人死不休，以流量为目的的时候无顾于技术的科学性和严肃性。
PART 1：卫报迁移事件解析
其实这是卫报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的博客。
好了，至此我们大概了解情况了。
中文社区
有话说
- Philip的第一个要迁移的原因：NTP导致的运维故障。 MongoDB是分布式集群，需要时间统一。 Oracle RAC集群的时钟服务出问题也会导致集群问题。你自己在VPC里面不小心把 NTP时钟服务中断了导致集群不能正常工作，这是谁的锅呢？？
- Philip的第二个要迁移的原因： 应用程序启动时构建索引导致服务不可用。关于这一点，如果是一个读的懂英文文档的开发者都会知道，无论是使用Spring或者Nodejs，都会提到并不建议在程序里来创建索引。 构建索引消耗很多资源并且执行时间不可控，按照MongoDB最佳实践是要在复制集内进行滚动构建。实际上使用 OpsManager就可以很容易实现滚动建索引。这一点他自己也意识到了“可能不是一个好主意”。恩，怪我咯
- Philip的第三个要迁移的原因：数据库管理很重要而且很难。恩恩，所以我们要换一个数据库，从MongoDB换到PostgreSQL。因为PostgreSQL不是数据库， 就不用管理了？
- 没有比较就没有伤害。和上面提到的Mat Wall的Oracle迁移到Mongo的言之凿凿的原因比较，Philip的3大原因没有一条是真正和MongoDB数据库本身技术相关的。MongoDB丢了数据吗？MongoDB自己崩溃了吗？ 作为卫报这个知名媒体，可以有一点逻辑吗？
- 在卫报迁移到AWS之前，MongoDB运行都是正常的。所有的问题反而是在AWS里发生的，特别是关于VPC的那个。这个说明了卫报IT团队在云管理能力上有所欠缺。按照他们的理论，亚马逊多半也没有实现“云让你不用再管理你自己的基础架构”的口号吧？是不是也该从AWS迁移走呢？
到这里相信读者能够有所甄别。Philip团队真正的痛点是他们无足够的能力，也无意在这方面去增强自己的能力来运维自己的MongoDB集群。这个出发点本身并无诟病，这是SaaS/PaaS 平台存在的意义。MongoDB自己就提供基于AWS的云托管服务 。 Philip确实提到了有一个超出他决策范围的非技术原因（来自编辑部）让他无法选择MongoDB 云托管服务。换句话说，如果没有那个编辑部的外在影响，Philip的完美解决方案就是：
卫报自管理的 AWS MongoDB -> 无缝迁移工具 -> MongoDB AWS 云托管服务
这个方案可以完美解决：
- NTP 或类似的问题
- 数据库管理（托管服务的基本价值）
- 应用程序构建索引。。。（oops 不行, 这种自己挖坑自己踩的哪个云平台恐怕都解决不了）
这种迁移由于不涉及到代码改动，所需工作会大大减少。我们不知道Philip开始迁移方案的时候有没有预料到会花他们团队10个月，而且可能是Sleepless的10个月。但是线下Mongo到Atlas的迁移在工具的协助下，可以在数天内就完成并可以轻松的实现无缝切换。
如果我们可以打倒标题党，这篇文章的题目更应该叫做：
别了，自运维数据库，拥抱云托管数据库。
PART 2：58简历泄露事件
原文是：“854GB！MongoDB数据库泄露2.02亿中国求职者履历”
关于这个因为发生在国内，大家还是比较容易辨清是非的。MongoDB中文社区和58工程师非正式的确认了一下，此次泄露和58毫无关系。
结合前年已经发布的58简历事件的文章，我们大概可以猜到事情可能是这样发生的：
- 若干年前，某黑客使用58网站的公开API，使用爬虫把数以亿级的简历信息爬下来
- 爬下来的数据存在MongoDB（恩恩，爬虫很喜欢水果）
- 然后在淘宝上几百元一套出售
- 某位兄弟买了这样一套数据，可能也存放在MongoDB里面
- 这位兄弟当然无须为这些数据的安全性负责，于是连最基本的安全措施都没有使用，导致数据泄露
所以其实数据泄露源头根本不在于MongoDB。源头在此（感谢徐雷的整理）：
其实关于58的简历，国内的安全网站很早2017年就给出了预警，58同城API存在漏洞，导致的网络爬虫程序等攻击，导致的数据泄漏。
原文摘选：
由于58同城网站存在弱加密等设计缺陷，导致攻击者可通过访问该网站的某些数据查询接口，经过简单的解密还原，获取并关联用户关键信息，进而获取用户简历的全部信息。
简而言之，攻击者获取简历全部信息可通过以下三个步骤：
1、攻击者通过某移动端接口获取部分简历信息（求职方向、年龄、期望月薪、工作经验、居住地、学历、用户ID、更新简历时间等内容）和简历ID；
2、攻击者使用简历ID通过另一个接口获取用户的真实姓名；
3、攻击者使用用户ID通过另一个网站页面获取用户的电话号码。
通过用户ID和对应简历ID将三部分信息关联，攻击者就可以获得最完整的用户简历信息，最终实现简历遍历的目的。
原文链接：
https://www.freebuf.com/news/130299.html
防止此类数据泄露其实非常简单， 只要有一些基本的安全意识就好了。 MongoD数据库本身的安全机制已经非常强大，简单来说，你只要执行下述一条或者多条最佳实践，就可以很大程度上保护好你的数据库了：
- 启用鉴权！不管是本地鉴权，还是LDAP 、 Kerberos第三方验证
- MongoDB尽可能不要部署在公网上
- 如果一定要部署在公网，那就要设定防火墙 – 端口只开放给授权的应用或者客户端
- 使用bind_ip限定监听的网卡，一般只监听内网甚至本地网卡端口
- 尽可能使用SSL/TLS协议来访问MongoDB
- 使用角色和权限来微调管理用户权限
- 启用审计功能（需要MongoDB企业版）
结论：
大家该怎样使用MongoDB就怎样使用。互联网上信息质量参差不齐，一定要小心标题党，擦亮眼睛不要被哗众取宠的人所误导 。
