NoSQL：それが簡単だったら 、作者はMongoDBについて書いています：
MongoDBはキー/バリューストアではなく、かなり多くの機能を備えています。間違いなくRDBMSでもありません。私は本番環境でMongoDBを使用していませんが、テストアプリを作成するために少し使用しました。これは、非常に優れたキットです。非常にパフォーマンスが高いようで、フォールトトレランスと自動シャーディング（別名、スケーリング）を備えているか、まもなく備えます。 Mongoは、これまでに見たRDBMSの代替品に最も近いものかもしれないと思います。すべてのデータセットとアクセスパターンで機能するわけではありませんが、一般的なCRUD用に構築されています。本質的に巨大なハッシュを保存し、それらのキーのいずれかを選択できることは、ほとんどの人がリレーショナルデータベースを使用する目的です。 DBが3NFで、結合を行わない場合（テーブルの束を選択し、すべてのオブジェクトをまとめるだけです。これは、ほとんどの人がWebアプリで行うことです）、MongoDBはおそらくあなた。
次に、結論として：
指摘すべき本当のことは、データベースを選択できないために非常に優れたものを作成することを妨げられている場合、それは間違っているということです。 mysqlを知っている場合は、それを使用してください。実際に必要なときに最適化します。 k / vストアのように使用し、rdbmsのように使用しますが、神のために、キラーアプリを作成してください。これはほとんどのアプリにとって重要ではありません。 FacebookはまだMySQLをたくさん使っています。ウィキペディアはMySQLをよく使用しています。 FriendFeedはMySQLをよく使用します。 NoSQLは優れたツールですが、競争力になるわけではなく、アプリを熱くすることもありません。何よりも、ユーザーはこれを気にしません。
次のアプリは何で作成しますか？おそらくPostgres。 NoSQLを使用しますか？多分。 HadoopとHiveも使用する可能性があります。すべてをフラットファイルに保存する場合があります。たぶん私はマグレブをハッキングし始めるでしょう。 仕事に最適なものを使用します。 レポートが必要な場合は、NoSQLを使用しません。 キャッシュが必要な場合は、おそらくTokyoTyrantを使用します。 ACIDityが必要な場合は、NoSQLを使用しません。 大量のカウンターが必要な場合は、Redisを使用します。 トランザクションが必要な場合は、Postgresを使用します。 1種類のドキュメントが大量にある場合は、おそらくMongoを使用します。 1日に10億個のオブジェクトを作成する必要がある場合は、おそらくヴォルデモートを使用します。全文検索が必要な場合は、おそらくSolrを使用します。揮発性データの全文検索が必要な場合は、おそらくSphinxを使用します。
私はこの記事が好きです。非常に有益であり、NoSQLの展望と誇大宣伝の概要を説明しています。しかし、それが最も重要な部分であり、RDBMSとNoSQLのどちらを選択するかについては、自分自身に正しい質問をすることが非常に役立ちます。私見を読む価値があります。