私は非リレーショナルデータベースでは本当に面白いですが、その小さな部分にしか慣れていない多くの理由があります。だから、基本的なユースケース、賛否両論で使用するすべてのNoSQLテクノロジーをリストしたいと思います。あなたには、いくつかのいくつかの技術で作業中、特定の問題、興味深い経験などをお持ちの場合はNoSQLテクノロジ、ユースケース、長所と短所
あなたがコミュニティとそれを共有するために歓迎されています。
は個人的に私が働いていた：
のMongoDB：
ユースケース：あなたは良い集約機能、自動レプリケーションが必要な場合は、私の意見表明のための最高の一つです。スケールが良い。日常使用データベースのように使用できる多くの機能があります。何らかの理由でSQLソリューションを使用したくない場合は、Mongoを選択することができます。動的クエリが必要な場合は、mongoも素晴らしいです。また、mongodbもインデックス作成をサポートしています。重要な機能です。
賛否：高速、良いスケール、使いやすく、内部地理空間インデックス
短所：比較的遅い書き込み操作、アトミック操作は、多くの問題を作ることができ、ブロッキング。メモリを消費するプロセスは、使用可能なすべてのメモリを「食べる」ことができます。
CouchDBの：
ユースケース：私はウィキでそれを使用するには、プロジェクトを好きで、私はその例のための完璧なデータベースだと思います。更新中に各文書が新しいリビジョンに自動的に保存されるという事実は、すべての変更を見るのに役立ちます。累計、時折変化するデータに対して、事前定義された照会が実行される。
プロ：使いやすい、REST指向のインターフェイス、バージョン。
短所：パフォーマンスの問題ドキュメントの量は（Luceneのを追加することで解決することができる）
のSimpleDB（万人以上）、ビット純粋なクエリ機能は、非常に巨大である：
用途：これはAmazonのデータサービスで、提供するすべてのものの中で最も安いものです。非常に機能が限られているため、Amazonのサービスを使用したいが、可能な限り少ない費用で支払いたい場合は、メインのユースケースがそれを使用しています。
プロフェッショナル：安価で、すべてのデータがテキストのように保存されています。操作が簡単で使いやすいです。
短所：：非常に制限があります（ドキュメントサイズ、コレクションサイズ、属性数、属性サイズ）。テキストのように保存されたすべてのデータが、日付または数値による並べ替え中に追加の問題を引き起こす方法（日付または数値を保存するときに回避策が必要な辞書順ソートを使用するため）。書き込みは、あなたの主な目標である場合