だから私はNoSQLデータベースを調べていました。エコメは彼らにとても魅了されました。だから私の質問は、リレーショナルデータベースをすでに利用している既存のn層エンタープライズWebアプリケーションに2番目のNoSqlデータソースを追加する可能性のある正当な使用法や理由は何ですか？
私はRavenDBブログで、彼らのデータベースの欠点の1つが報告していることを読みました。これは一般的にドキュメントデータベースに当てはまりますか？レポートにSQLServerを、その他のことにNoSqlをどのように利用できるでしょうか。このようなアーキテクチャはどのように見えるでしょうか？
それはあなたのアプリケーションに欠けているものに依存します、私はno-sqldbを追加するこれらの理由を考えることができます：
Webアプリケーションがトラフィックの多いアプリである場合は、ユーザーの行動データの一部をログに記録する必要があります：http ://wiki.apache.org/cassandra/LoggingToCassandra
キャッシングまたはインメモリ使用では、Redis、Riak、Hazelcastなどのインメモリデータベースをいつでもアプリケーションに追加して、パフォーマンスを向上させることができます（memcachedも検討できます）。これは、検索、ユーザーセッション、静的コンテンツの提供に役立ちます。
pub / subサーバーが必要な場合、Redisは良い仕事をしますhttp://redis.io/topics/pubsub
データを構造化された方法で保存する場合。たとえば、mongoDB、OrientDB、neo4j、CouchDBのようにJSON形式やグラフで保存します。couchDBの組み込みRESTAPIを使用して、Webクライアントからデータに直接アクセスできます。
既存のDBに影響を与えずにWebアプリに新しい機能を追加する場合。たとえば、APIを介してデータを公開したい場合や、リアルタイムの検索機能とインデックス機能を追加したい場合。
スケーラビリティの点で、おそらくno-sqlデータベースはリレーショナルデータベースよりも拡張性が高い傾向があります。
ここにたくさんの良い例があります。言及されていないように思われることの1つは、非正規化された高トランザクション読み取りレイヤーを作成することです。これはCQRSの世界に適しています。リレーショナルモデルのデータをクエリして、レポート用の消耗品データを作成するのが難しい場合。代わりに、リレーショナルモデルをフラットモデルに変換することもできます...ドキュメントデータベースがうまく機能します。
キャッシングは一般的な使用法です。たとえば、この他の質問を参照してください。
キャッシングは確かに一般的な使用法です。CouchbaseとRedisは通常これを満たします。
構造化ログストレージも一般的な使用法です。人々は、Mongoを使用して構造化ログ（1つのフラットストリングだけでなく）を保存することを好むようです。
非常に大量のデータを処理するもの。たとえば、ページのヒット/ビュー/ユーザーアクティビティを追跡するために、Webサイトに追跡ピクセルを配置する場合があります。生成されるデータは潜在的に非常に大きくなります。NoSQLデータベースは通常、水平方向に非常にうまくスケーリングします。
また、ドキュメントデータベース（CouchDB、MongoDB、Couchbase）を使用すると、正規化するには苦痛が大きすぎるものをすべて保存できると主張します。テーブルとCRUDストアドプロシージャの作成にすべての時間を費やしていますか？リッチオブジェクトをJSONにシリアル化して保存する方が簡単かもしれません！
これは実際にはNoSQLの下ではありませんが、グラフデータベースは物事間の関係を効率的に保存できます。Facebookのソーシャルグラフ、あるいはレコメンデーションエンジンを考えてみてください。