MongoDB：逐渐变得无关紧要

以下为译文：

我与MongoDB的关系可分为三个阶段。对于目前处于第三阶段的我来说，这款产品似乎变得无关紧要了。很快你就会明白为什么我这么说。

阶段一：痴迷

我与MongoDB的第一次接触十分神奇：一个poliglot持久性架构用它来处理部分系统，而框架的关系模型却不是很适合。然而它运行得十分漂亮：快速、易于安装和使用，并且运转良好。不得不说，MongoDB很适合应用于此类情况。

它的表现震惊了我：事实上，我主要的查询语言是JavaScript，这已经十分了不起。我从未奢望类似的东西能运行得如此出色。在那段时间里，我详细了解了这款产品以及如何管理它配给的文档模型。

阶段二：现实

也许这个阶段更好的名字应该是成熟。在这个阶段，我知道在什么情况下该使用MongoDB，更重要的是，什么时候不该使用MongoDB。这时，你会发现MongoDB是一款很好却需要谨慎使用的产品。它提供的文档模型强大到能帮你解决很多但却不是全部问题：实际上，只是相当多而已。

我是从自己和别人的失败上意识到了这个问题。很多人非常兴奋的想要把世界简化成一个模式，于是MongoDB就可以成为所有问题最完美的解决方法。但每当这些时刻，一些不符合想象却真实存在的事实就会砸到你脸上证明你的想法是错误的：

• 关系模型并没有它们表现的那么糟糕。事实上，这种模式目前十分流行，而且在未来很长一段时间内它的地位都不会改变，究其原因：它管用。并且与NoSQL相反，我们手里有各种适用于此模式的好的或者坏的的实践方法。
• ACID事务。MongoDB有一点恼人的地方：不能创建一个事务处理多个文档。于是问题来了：多数情况下，你必须同时进行多文档处理。
• 在你知道你的系统需要什么之前，所有以上谈到的强大性能，都和你关系不大。

在这个阶段，所有的激动人心和相见恨晚都消失了，这是所有人都会有的。这时，你会知道这款工具可以做什么以及不能做什么。这是最好的阶段。

阶段三：无关紧要

现在MongoDB对于我来说已经变得无关紧要了。当然不是指文档模型，而是产品。有一天早上我醒来，突然意识到我不再需要MongoDB了，因为对于我的项目来说，其替代品更具吸引力。它们是分批来的。

第一波：TokuMX

TokuMX是MongoDB的一个分支，我喜欢称之为“MongoDB迷人的双胞胎兄弟”。它与MongoDB使用同样的通信协议，采用基本相同的命令，并可与MongoDB 100％兼容。但它具有一些MongoDB没有的强大优势：

• 可以进行多文档ACID处理。
• 快于MongoDB（快50倍速）。
• 存储消耗比MongoDB少90％。
• 与MongoDB 100％兼容。所有你需要做的就是将MongoDB实例更换成TokuMX，然后转移数据（这是相当容易的），这样你就大功告成了。

是的，与MongoDB一样，它也是开源的，而且有运行非常好的免费版本。当然，它也不是完全无懈可击。它有两个局限：

• 没有Windows发布（Distribution ）。
• 目前Java库还不能提供MongoDB ACID执行的本地支持。它可以使用，但仍需要一些样板代码。

TokuMX第一次让我意识到MongoDB对我来说似乎无关紧要。当然，这可能只是暂时的：在日后版本发布后，MongoDB仍有可能击败TokuMX。但是，也只能寄希望于日后版本。目前为止，它做不到。

第二波：PostgreSQL

如果说TokuMX让我觉得MongoDB无关紧要，那么PostgreSQL 9.2则强化了这一印象。自9.2版本，PosetgreSQL开始对JSON和JSONB数据类型提供支持。这是一个有意思的解决方案，因为它，我可以得到关系模型中具有文档灵活性的好的部分。而所有这一切都基于同样的产品。太好了！

但是MongoDB曾比PostgreSQL的具有更高性能。我说“曾”是因为PostgreSQL 9.4版本使其变成了历史：最近的基准显示，PostgreSQL在处理JSON数据类型上比MongoDB更快。我没有想要比较PostgreSQL和TokuMX，但鉴于两者现在都比MongoDB拥有更好的性能，我想大家已经清楚我的观点了。

结论

与 TokuMX 和 PostgreSQL 相比较使得 MongoDB 处于劣势。但它仍然是一款很好的产品，而且会继续改进来与这些替代产品竞争，然而目前来看它最多只能排在第三名。2015年MongoDB的改进和发展，我们拭目以待。

原文链接： The growing irrelevance of MongoDB（翻译/李贻丽 责编/钱曙光）

欢迎订阅“ImapBox云计算”微信号获得更多云信息。

欢迎关注ImapBox@邮箱云存储微博了解最新云计算及大数据资讯。