开源中国

我们不支持 IE 10 及以下版本浏览器

It appears you’re using an unsupported browser

为了获得更好的浏览体验,我们强烈建议您使用较新版本的 Chrome、 Firefox、 Safari 等,或者升级到最新版本的IE浏览器。 如果您使用的是 IE 11 或以上版本,请关闭“兼容性视图”。
为什么你不应该使用 MongoDB - 技术翻译 - 开源中国社区

为什么你不应该使用 MongoDB 【已翻译100%】

标签: MongoDB
oschina 推荐于 4年前 (共 40 段, 翻译完成于 12-12) 评论 36
收藏  
132
推荐标签: MongoDB 待读

回到我们的例子。当作者修改现存的帖子(post)时,更新过程在本质上与创建是一样的,唯一不同的是它不是增加到缓存,而是更新一个已经存在的条目。

如果步骤2的后台作业中途失败会怎样呢?机器重启了,网络线缆插头被拔掉了,应用重启了。在我们的工作中,不稳定是唯一不变的变量。当那些事情发生的时候,你将会被缓存中的非法数据整崩溃。一些帖子的拷贝是旧的标题,而另一些拷贝却是新的标题。这是一个严重的问题,但是对于缓存而言,经常会有这种毁灭式的情况。

经常的一种情况 >_<

super0555
 翻译得不错哦!

你完全可以从缓存中删除整个活动流记录,并从持久化的后台存储中重新生成它。这或许很慢,但至少这是可能的。

如果没有后台存储又会怎样呢?如果你跳过了步骤1呢?如果你仅仅只有缓存呢?

假如你只有MongoDB的话,它就是没有后台存储的一个缓存。它将会产生不一致。不是最终的一致——而一直都是纯粹的、彻头彻尾的不一致。就这一点而言,你没有选择。即使毁灭式的也没有。你没有任何办法重新生成一致状态的数据。

当Diaspora项目决定将关系型数据存储于MongoDB的时候,我们将数据库与缓存合并起来。数据库与缓存是非常不一样的两种事物。对于持久化、瞬态、复制、引用、数据完整性和速度,它们有完全不一样的思想。

super0555
 翻译得不错哦!

转变

一旦我们理解了我们一不小心给数据库选择了一个缓存,那么我们是怎样使用这个缓存的呢?

好吧,这是一个价值百万美元的问题。但是我们已经回答了价值十亿美元的问题。在这篇文章中,我已经谈到了我们是如何使用MongoDB的,相对应的是,它是如何设计其使用方法的。我已经谈过这一点了,就仿佛所有的信息都是显而易见的,只是Diaspora团队在做出选择之前没有做充足的研究。

super0555
 翻译得不错哦!

但是这些东西一点也不显而易见。MongoDB文档告诉你它擅长什么,却没有强调它不擅长什么。这很好理解。所有项目都是这么做的。但是其结果是,这使我们花费了大约六个月,听到许多的用户埋怨,并且做了大量的调查,才由此断定我们使用MongoDB的方式不对。

没有什么别的办法,只有将数据从MongoDB中取出来,将它们迁移到一个关系型的存储设备,在此过程中要尽我们最大努力处理我们发现的不一致的数据。数据转变本身——由MongoDB导出,再导入到MySQL——非常简单明了。其中的技术细节,可以看看《你所有的基础配置2013》中幻灯片 。

super0555
 翻译得不错哦!

损害

我们有八个月的生产数据,这大约对应于MySQL中的120万行。我们耗费了四个双周来开发这个转换代码,当我们开始实际实施的时候,主站有大约两个小时的宕机时间。对于一个处于初期测试版的项目来说,这实在令人无法接受。我们应该缩短这个宕机时间的,但是却预估了八个小时的宕机时间,这样的话两个小时看起来似乎还很漂亮。

还不坏

super0555
 翻译得不错哦!

尾声

还记得电视剧(TV show)的应用吗?它是MongoDB的完美用例。每个剧集都是一个文档,完全独立的文档。它不引用任何东西,没有副本,而且数据没有不一致的可能。

距离开发约过了三个月后,电视剧应用仍然在MongoDB基础上很好的运行着。后来的一个星期一,在每周计划会议上,有委托人告诉我们,有个投资人想要一项新的功能:当他们在某一集节目中看到某个演员的时候,他们想要可以点击该演员的名字,并看到这个人的整个电视职业生涯。他们想要该演员曾经出现过的所有不同剧集的一个时间排序的列表。

super0555
 翻译得不错哦!
我们将每个剧集保存为MongoDB中的一个文档,其中包含了所有嵌套的信息,包括 整个演员班底。如果同样的演员出现于两个不同的戏,甚至是出现于同一个剧集,他们的信息在两个地方都有保存。除了比较他们的名字,我们没有办法识别出他们是否是同一个人。所以为了实现这个功能,我们必须搜索每个文档,找寻用户点击的演员,并删除重复记录。啊,对了。最起码,我们需要删除一次重复记录,然后再维护演员信息的一个外部索引,就像任何其它的缓存一样,它同样也具有失效问题。
super0555
 翻译得不错哦!

你来看看这是怎么回事

客户期待的功能是如此微不足道。如果数据已经在关系存储,它会一直在哪里。由于这是我们第一次尝试说服项目经理,客户并不需要它MongoDB。失败后,我们提供了一些便宜的替代品,如链接到IMDB搜索演员的名字的产品。这个公司从广告赚钱,虽然如此,他们希望用户留在自己的网站上,而不是去上IMDB 。

此功能要求最终促使该项目的转换到PostgreSQL。当有更多的与客户交流后,我们意识到,客户企业看到把电视节目连接在一起很多价值。他们期望能够看到——正在看的节目的导演的其他节目。也希望能够看到——类似正在看的节目的其他本周发布的同一主题的节目。

这从根本上是一个沟通的问题,而不是技术问题。如果这些沟通已经提前发生了,如果我们花时间去真正了解客户端是怎么看到数据的和他们想要对数据做什么的话,我们可能会早些时候做这样一个沟通,那个时候有较少的数据,并且变更也较容易。

黄劼
 翻译得不错哦!

一直在学习中

我从经验学到:MongoDB的理想使用场景是比我们的电视数据更窄。唯一的事情是擅长的是存储任意个JSON数据。“任意”,在此背景下,意味着你不稀罕什么是JSON里面。你甚至不看。没有模式,甚至没有一个隐含的模式,就犹如我们的电视节目数据。每个文件仅仅是一个blob数据,其内部数据是什么完全不在意。

在RubyConf这个周末,我跑进康拉德欧文,谁提出这个用例。他用MongoDB的存储JSON的任意位的是来自客户通过一个API。这是合理的。这种帽子理论是完全不在意你的数据内容是否有意义。很有趣的是在应用程序中,你的数据很有意义的。

黄劼
 翻译得不错哦!
我已经听到很多人谈论到自己的web应用下探的MongoDB来替代MySQL或PostgreSQL。任何情况下,这都不是一个好主意。架构的灵活性听起来像一个伟大的想法,但只有一次,它是真正有用的是当你的数据的结构没有任何价值。如果你有一个隐含的模式 - 这意味着,如果你期待返回JSON的数据 - 那么MongoDB是错误的选择。我建议采取看看PostgreSQL的hstore(现在比MongoDB的速度快的),并学习如何进行更改架构。他们真的并不难,即使是在大表。

寻找价值 

当你选择一个数据存储,应该了解最重要的事情就是你的数据在哪里,你的数据如何连接,你的数据的商业价值所在。如果你还不知道(这是正常的),那么选择不会画你陷入了困境的数据存储。推JSON数据到你的数据库听起来很灵活,但真正的灵活性是很容易添加业务需求de 功能。 

让有价值的东西做起来更加容易。

黄劼
 翻译得不错哦!
本文中的所有译文仅用于学习和交流目的,转载请务必注明文章译者、出处、和本文链接
我们的翻译工作遵照 CC 协议,如果我们的工作有侵犯到您的权益,请及时联系我们
评论(36)
Ctrl/CMD+Enter

ok
题目与示例脱节:通过两个用法错误的失败案例来“反”MongoDB太没说服力了。
写的很好
呵呵,好东西顶起来
"例如,如果你在一个关闭了外接网络而无法访问Facebook和Twitter的国家,你的pod依旧会在本地运行,并和你所在国家内的其他人相连接,即使无法访问外部。"
这是在说明技术选型的重要性
任何脱离正确的应用场景和靠谱的运营的使用都是瞎JB扯淡。
为什么我觉得这不是一篇讨论MongoDB技术博客,而是一篇推广Diaspora的软文?
貌似就说了一句话:MongoDB在无引用的文档存储领域具备很大优势,但是不适用于多引用的场合。

引用来自“带刀的麦兜”的评论

请问楼主 这是什么鸡巴玩意

+1
当你选择一个数据存储,应该了解最重要的事情就是你的数据在哪里,你的数据如何连接,你的数据的商业价值所在。如果你还不知道(这是正常的),那么选择不会画你陷入了困境的数据存储。推JSON数据到你的数据库听起来很灵活,但真正的灵活性是很容易添加业务需求de 功能。

这句话很深刻.

对创业来说, 先快速做起一级建筑以后有钱了再玩高级的是正确的即时战略思路. 应该先选择自己熟悉的能够控制的,低成本的组合, facebook能崛起和起手用php+mysql分不开. 像ruby+mongodb这种事后发现不对的,有玩火的危险.
怎么理解MongoDB的缓存失效问题?这是说MongoDB不支持完整的ACID事务特性吗?
请问楼主,这是什么鸡巴玩意? 和mongodb有半毛钱关系?
很受用,讲出了md的不擅长部分;强调沟通的重要性。
典型的不明觉厉
一两个失败的案例就推翻mongodb,只能说作者选择错误,并不说明mongodb不行
像这种冗余在一开始的时候就能够预料到。
尼玛 刚买了本书 准备好好学学
受益匪浅,给一直想尝试mangodb的我学到很多
对于文档数据库存储了关系数据不合适的话,关系数据库应用了反范式,那是不是说明这样的数据结构同样不适合关系数据库?

目前来讲文档数据库完全代替关系数据库确实很牵强,我认为文档数据库的重点是无模式,而不是能不能有关联数据
顶部