是时候跟 MongoDB 说再见了

在过去的两到三年的时间内，我一直在一个中等规模的项目中使用 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 合法的目标，但其技术的基础却是摇摇欲坠的