是时候跟 MongoDB 说再见了 - 开源中国社区
是时候跟 MongoDB 说再见了
oschina 2012年05月20日

是时候跟 MongoDB 说再见了

oschina oschina 发布于2012年05月20日 收藏 33 评论 59

有免费的MySQL,为什么还要买? >>>  

在过去的两到三年的时间内,我一直在一个中等规模的项目中使用 MongoDB。

但因为各种技术上的原因,到了和 MongoDB 说再见的时候了,我的原因有以下几点:

  • MongoDB 当前的内存模型基于内存映射文件,这是一项已经宣布脑死亡的技术。在实际应用过程中,不具备伸缩性,没有方法来控制内存的使用情况。
  • 锁机制: 一个可伸缩性的数据库解决方案使用全局的服务器锁是一个糟糕的设计,特别是因为当 MongoDB 支持原子操作。应该有更精细的锁操作。
  • 查询引擎:目前 MongoDB 的每个查询只允许使用一个索引,不知道为什么会有这样的限制,完全没有理由。其实 MongoDB 的索引模型和关系数据库是差不多的。
  • 查询语言:使用 JSON 作为查询语言是一个糟糕的决定,尽管当前 JSON 查询语言支持标准查询,但对一些操作确实有限制,无法在 JSON 中执行一些类似 SQL 的复杂查询。
  • Map-Reduce: MongoDB 的 Map-reduce 相似一个无用的赠送品。
  • 数据分片:这是 MongoDB 的另外一个糟糕的功能,从一个单一的服务器到分区设置的步骤是非常巨大的,你需要最少两个复制集才能做分片,三个配置服务器和负载均衡,有点像小镇上的小房子旁建了一栋摩天大厦。
  • 数据中心的意识:这是另外一个拼凑在一起的特性,复制集只支持一个主节点和多个从节点,只能去写一个从节点。可以在跨多个数据中心运行复制集,但写操作只能在一个数据中心的从节点。
  • 默认关闭“安全”模式: 是谁做出这样白痴的决定呢?看到很到报道称数据丢失,多数是因为这个问题。
  • 日志: MongoDB 预先分配了 3G 的数据用于日志记录,这个数据是独立于数据库大小的,3G大小对一些小型系统来说简直是疯了。

社会化组件:10gen 和 MongoDB 试图让构建一个大型的可伸缩系统变得很简单,但实际上并不如此。在过去,构建大型的可伸缩性系统是非常复杂的,需要专业的知识和经验。尽管很多人觉得构建这样一个系统很酷。有一点很清楚的是,如果你正在构建一个小型或者中型的系统,那么使用 MongoDB 将会是徒劳的,因为性能不佳的问题以及收效甚微。很多人不愿意深入去了解和挖掘 SQL 数据库本身的功能和性能,轻易的作出了使用一些非 SQL 数据库系统的决定,这样的做法是不明智的,而且充满危险。我这样说可能太苛刻,不符合多样性,但却非常现实。

MongoDB 目前更多的是市场营销和炒作,10gen 主要的目标是为了告诉全世界说 MongoDB 是如何的酷,原因很清楚:10gen 正试图发挥在数据库这一市场上与其他产品进行竞争,以便能更好的说服投资人支付更多的钱来帮助其发展,这当然是 10gen 合法的目标,但其技术的基础却是摇摇欲坠的。

英文原文OSCHINA原创翻译

本站文章除注明转载外,均为本站原创或编译。欢迎任何形式的转载,但请务必注明出处,尊重他人劳动共创开源社区。
转载请注明:文章转载自 开源中国社区 [http://www.oschina.net]
本文标题:是时候跟 MongoDB 说再见了
分享
评论(59)
最新评论
0
这一个mongodb比其他SQL,NOSQL不知道高多少,不会用就说它不好。你们黑都黑不到点子上,要黑也只能说他不是用java写的,简直low爆了。另外说一下php是最狗屎的语言,没有之一,嗯
0

引用来自“千珣”的评论

作者明显扯蛋,不用mongo用MYSQL更好? 过来人说,我情愿用mongo,至于mongo的内存占用问题是可以去优化的.
求优化方案
0
说实话 你说的话一无是处
0
mongodb的数据结构和mysql不同,这使它处理更现代的需求的能力甩mysql几条街,作为mongodb的使用者,应当抛弃关系数据库的那些古老的数据库设计理论了,完全过时
0
这是个选择性错误!
0
打击我,正在学呢,不过还是好好学正在
0
一直在用,目前软件使用情况良好,已经用2000家用户在用。
0
我觉得“MongoDB 当前的内存模型基于内存映射文件”这点确实应该重新设计一下,毕竟靠文件系统本身的热点不能解决真正的数据热点;至于“全局锁”我想这个将来会慢慢改进,其它的并不是改进的,作者言重了,毕竟mongodb出来的较晚,它还有很大的上升空间
0
那只是一个中等规模的项目...
0
Great cmomon sense here. Wish I'd thought of that.
0
At last! Somethnig clear I can understand. Thanks!
0
呵呵,本来就是用来做快速消费的数据库
0

引用来自“kubbvip”的评论

引用来自“SamChi”的评论

好吧,最近刚好还在看啥《MongoDB权威指南》

买了好几个月还没看过的路过。

忽然发现我也有一本 -_-#看了 忘了...
0
这帖子很火么,正准备试试呢。

看到说它不好的,刚好参考一下。
0

引用来自“谭明智”的评论

每种技术要解决的问题领域不同,大部分是我们选型不对,你用mongo的特性解决他不擅长的领域,只能说明使用者的弱智,而不是技术的弱智

+1
0

引用来自“onlykc”的评论

是时候跟作者说再见了

+1
0
别人的失败阻止你成功的脚步,可笑~~
0
嗯,选择适合的
0
每种技术要解决的问题领域不同,大部分是我们选型不对,你用mongo的特性解决他不擅长的领域,只能说明使用者的弱智,而不是技术的弱智
0
这也是根据项目需求来看的吧!没有硬性龟腚必须你用,谁和用谁用就好!
顶部