虽然 MongoDB 在 Google Trends 上仍然保持强劲势头，但也偶尔听到一些负面意见。我在 Quora 上找到了一篇文章，尽管有点过时但经常有更新。我在文章中做了一些章节的增补，但除此以外都是直译的。

总结

如果需要特定功能，最好使用专门化的数据库，而 MongoDB 则是一种拥有多种特性且易于使用的混合型数据库。

大量のデータをMap/Reduceしたいなら、Hadoop
Key/Value の大量の操作ならスケールする Riak
キャッシュとして使いたいなら、Membase, Redis, HBase
キューとして使いたいなら、RabbitMQ, ActiveMQ, ZeroMQとか
検索用途で使いたいなら Solar & Sphinx とか

翻译

哪家公司为什么停用MongoDB？

首先，让我们阅读这个问题：
关于帖子《不要使用MongoDB》，它有多少可信度？（备注：1.设计上的不足和复杂性问题，2.优先功能满足而非稳定性的方针问题）

放弃使用MongoDB的讨论：

Anonymous: http://pastebin.com/raw.php?i=FD…

Zopyx: Blog of Andreas Jung – Goodbye MongoDB (2012/5/16)

Bump: Bump Dev Blog – From MongoDB to Riak (2012/5/14)

Urban Airship: schmichael’s blog – Failing with MongoDB (2011/11/5)

Shareaholic: Migrating to Riak at Shareaholic (2012/8/31)

DigiDoc: SVS – Why I Migrated Away From MongoDB (2012/9/17)

Etsy: MongoDBでスタートしようとしたプロジェクトが失敗した話
Why MongoDB Never Worked Out at Etsy

Aphyrのトーク: MongoDB 2.4.3 が、あるべき動作をせず一貫性がない話。長い記事です (Call me maybe: MongoDB)。成熟度や品質の不足について話している時に、必ず上がってくるような話題です。

Viber: Membaseに移行してサーバ負荷が半分になった話 Viber Replaces MongoDB with Couchbase

讨论的主题

这些讨论的很多内容可以归纳为几个主题：

製品の成熟度 : 品質の低さ、サブシステムの頻繁なクラッシュ(sub-systems repeatedly breaking)、ドライバーの一貫性のなさ、散財して不完全なドキュメント、複雑なノードの管理。

設計上の決定 : 単一の書き込みロック、メモリにマップされたファイルのせいでサーバーが性能をほとんど制御できない、レプリケーションはプロキシがなくコネクションが馬鹿げた数になる、シャーディングは可能だが幾つかの特別なノードのせいで実装するのがとても面倒、シャーディングが信頼できない、多くの地雷(pitfalls)と暗黙の了解(gotchas)がある。

誤ったトレードオフ : 幾つかのケースでは、MongoDB と RDBMS の違いを把握することなく使い始めています。結合、監査証跡、集計、スキーマ管理、入れ子になったオブジェクトへのクエリ … ある場所では労力がかかるのと引き換えに幾つかのことは簡単にできますが、それらのトレードオフが何であるのか常に明確というわけではありません。

我本人在实际生产环境中使用MongoDB已经有两年以上的经验，在StackOverflow上也是MongoDB领域排名第一的回答者，我也了解和遇到了一些相关的限制。

不是银弹

理解MongoDB的关键是要明白MongoDB并非所谓的“银弹”，就像其他事物一样，它也存在重要的权衡考虑。

我认为MongoDB是对传统的关系型数据库管理系统（RDBMS）的一种“创新”。它既不是Dynamo DB，也不是Bigtable DB，也不是Key-Value DB。它是一个融合了多个不同特点的数据库，这些特点来自于不同的来源。

可以接收复杂查询并具有类似于SQL数据库的二级索引。它具有类似于SQL数据库的复制功能。可以进行类似于Big-Table数据库的Map / Reduce / Aggregation操作。自动分片功能是介于SQL数据库和键值数据库之间的特点。

MongoDB具有与DynamoDB和SimpleDB相似的强一致性，但它没有“MVCC”（详见MongoDB的多版本并发控制，对应关系数据库中的Read Committed）。MongoDB在配置中对于最重要的写操作部分非常灵活，但最初的两种模式“Fire & Forget”和“Safe”实际上没有提交并写入磁盘。

简而言之，MongoDB位于独特的小众领域。要有效地使用它，必须理解其中许多独特的折衷方案。

转向专门化产品

Q.他们转而从事了什么工作？

总而言之，他们朝着更专注于他们的目标的方向前进。

もし、大量の Map/Reduce を実行したいなら、たぶん Hadoop (または新しい Hadoop プラグイン)になるでしょう。MongoDB は、Hadoop の Map/Reduce 速度に対抗するようには作られていません。
もし、本格的なシャーディングを組んでいて、Key/Valueの参照のみなら、Riak でもっと簡単に大規模対応できるでしょう。実際のところ、 Bumpの記事では「私達はRiakに移行することを決めた。なぜなら MongoDB より運用上の品質が高いからだ … 」
もし、主にキャッシュとして使っているなら、Membase、Redis、Hbase に辿り着くかもしれない。
もし、キューとして使っているなら、結果的には、RabbitMQ、ActiveMQ、ZeroMQ のような本格的なキューイングシステムを見たくなるかもしれない。
もし、検索用途に使っているなら、Solr と Sphinx のような検索の全用途をカバーするものに辿り着くでしょう。

这里的关键点是，MongoDB 存在权衡的问题。上述许多数据库都专注于自己的领域。MongoDB 没有太多特化，因此具备适用于许多情况的实用性。

然而，当达到一定规模时，MongoDB 的性能可能不如专门的解决方案。实际上，我在工作中也有这样的经历，正在将一些系统从 MongoDB 迁移到更适合的产品。

截至2014年09月21日，该书的作者是Gaëtan Voyer-Perrault。