Google Trends でも引き続き勢いのある MongoDB ですが、一方でちらほらネガティブな意見も聞かれます。Quora に記事を見つけたので訳してみました (ちょっと古いですが時々更新されています)。章立てを少し追加していますが、それ以外は直訳です。

まとめ

MongoDB は色々な特徴があって使いやすいハイブリッドなDB。でも、特定の機能を重視するなら特化したDBを使いましょう。

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

翻訳

Q.どの企業がなぜMongoDBをやめたんですか？

A.まず、この質問を読みましょう:
How much credibility does the post "Don't use MongoDB" have? (訳注: 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 を2年以上本番環境で使っており、StackOverflow では MongoDB で No.1 の回答者に位置しており、これらの制限の幾つかも見てきました。

「銀の弾丸」ではない

MongoDB を理解するキーは、MongoDBが「銀の弾丸」ではないということです。他のすべてと同じく
重要なトレードオフがあります。

MongoDBは典型的なRDBMSに対する「ひねり」(訳注：原文は"twist"。ここでは意外な進展、新方式、曲解というような意味か) のようなものだと思うのです。Dynamo DB でもなく、Bigtable DB でもなく、Key-Value DB でもありません。複数の場所から持ち込まれた複数の異なる特徴を持つハイブリッドなデータベースなのです。

SQL DB のようにセカンダリインデクスをもち複雑なクエリを受け付けます。SQL DB に似たレプリケーション機能があります。Big-Table DB のような Map/Reduce/Aggregation ができます。自動シャーディング機能は、SQL DB と Key-Value DB の中間的な特徴です。

DynamoDB や SimpleDB のように強い一貫性をもちますが、「MVCC」（MongoDbによる詳細) (訳注：多重バージョン並行処理制御、RDB での 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 からより適した製品に移行しています。

Gaëtan Voyer-Perrault 著
as of 2014.09.21