最近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的原因:
(上述内容摘自于
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列出了以下理由:
6) Philip团队在花了10个月时间的努力之后,终于把他们系统的数据库迁移到了AWS的PostgreSQL。然后他就发表了bye-bye MongoDB的博客。
好了,至此我们大概了解情况了。
中文社区
有话说
到这里相信读者能够有所甄别。Philip团队真正的痛点是他们无足够的能力,也无意在这方面去增强自己的能力来运维自己的MongoDB集群。这个出发点本身并无诟病,这是SaaS/PaaS 平台存在的意义。MongoDB自己就提供基于AWS的云托管服务 。 Philip确实提到了有一个超出他决策范围的非技术原因(来自编辑部)让他无法选择MongoDB 云托管服务。换句话说,如果没有那个编辑部的外在影响,Philip的完美解决方案就是:
卫报自管理的 AWS MongoDB -> 无缝迁移工具 -> MongoDB AWS 云托管服务
这个方案可以完美解决:
这种迁移由于不涉及到代码改动,所需工作会大大减少。我们不知道Philip开始迁移方案的时候有没有预料到会花他们团队10个月,而且可能是Sleepless的10个月。但是线下Mongo到Atlas的迁移在工具的协助下,可以在数天内就完成并可以轻松的实现无缝切换。
如果我们可以打倒标题党,这篇文章的题目更应该叫做:
别了,自运维数据库,拥抱云托管数据库。
PART 2:58简历泄露事件
原文是:“854GB!MongoDB数据库泄露2.02亿中国求职者履历”
关于这个因为发生在国内,大家还是比较容易辨清是非的。MongoDB中文社区和58工程师非正式的确认了一下,此次泄露和58毫无关系。
结合前年已经发布的58简历事件的文章,我们大概可以猜到事情可能是这样发生的:
所以其实数据泄露源头根本不在于MongoDB。源头在此(感谢徐雷的整理):
其实关于58的简历,国内的安全网站很早2017年就给出了预警,58同城API存在漏洞,导致的网络爬虫程序等攻击,导致的数据泄漏。
原文摘选:
由于58同城网站存在弱加密等设计缺陷,导致攻击者可通过访问该网站的某些数据查询接口,经过简单的解密还原,获取并关联用户关键信息,进而获取用户简历的全部信息。
简而言之,攻击者获取简历全部信息可通过以下三个步骤:
1、攻击者通过某移动端接口获取部分简历信息(求职方向、年龄、期望月薪、工作经验、居住地、学历、用户ID、更新简历时间等内容)和简历ID;
2、攻击者使用简历ID通过另一个接口获取用户的真实姓名;
3、攻击者使用用户ID通过另一个网站页面获取用户的电话号码。
通过用户ID和对应简历ID将三部分信息关联,攻击者就可以获得最完整的用户简历信息,最终实现简历遍历的目的。
原文链接:
https://www.freebuf.com/news/130299.html
防止此类数据泄露其实非常简单, 只要有一些基本的安全意识就好了。 MongoD数据库本身的安全机制已经非常强大,简单来说,你只要执行下述一条或者多条最佳实践,就可以很大程度上保护好你的数据库了:
结论:
大家该怎样使用MongoDB就怎样使用。互联网上信息质量参差不齐,一定要小心标题党,擦亮眼睛不要被哗众取宠的人所误导 。
MongoDB中文社区参与撰稿成员:
徐雷
中文社区联席主席 、MongoDB实战指南译者
刘诚杰
中文社区上海分会长、平安集团高级DBA
李丹
中文社区北京分会长、逻辑思维首席DBA
周李洋
中文社区联席主席、MongoDB Master、Teambition 运维总监
唐建法
中文社区主席
关注一下,精彩不停
本文分享自 Mongoing中文社区 微信公众号,前往查看
如有侵权,请联系 cloudcommunity@tencent.com 删除。
本文参与 腾讯云自媒体同步曝光计划 ,欢迎热爱写作的你一起参与!