誰かがリレーショナルDBMS上でMongoDB（または同様のもの）を使用するのはいつですか？
私はNoSQL全体などについて少し混乱しています。 OracleやMySQLのようなものよりもMongoDBのようなものを使用するのはいつですか両者の使い分けに関しては、「違い」がよくわかりません。
私の理解から、NoSQLタイプのデータベースはRDBMSに取って代わるものではありませんが、正確には何をするつもりですか？
これまでに3つのペットプロジェクトでCouchDBを使用しました。
- マイクロブログシステム。
- 私が作成した小さなメモを取るアプリの情報を保存するため。
- 汎用のブレーンストーミングアプリケーション。
MSSQLやMySQLなどを選択した主な理由は、MSSQLやMySQLを使用するときに得られる柔軟性です。厳密なスキーマはありません。 3か月後、特定のテーブルに追加のフィールドが必要になる場合、これとそれだけであれば、それを変更するだけで、そこから外に波及します。
A-pressの Beginning CouchDB を使用して、使い方を学びました。
たとえば、CouchDBはjsonを使用してデータベースとの通信を行います。言語がPOSTデータを送信できる場合は、それを使用してDBと通信できます。
また読んでください： なぜリレーショナルデータベースの代わりにドキュメントベースのデータベースを使用する必要があるのですか？ StackOverflow
別の回答を追加して申し訳ありませんが、ここでの回答はどれも非常に満足のいくものではありません。この回答はMongoDBに固有のものです（リレーショナルデータベースではない他の膨大な数のデータストレージオプションとは対照的です）。
長所：
- MongoDBはクエリごとのレイテンシが低く、実行する作業がはるかに少ないため（結合やトランザクションがないなど）、クエリごとのCPU時間も少なくて済みます。その結果、1秒あたりのクエリ数でより高い負荷を処理できますであり、ユーザー数が多い場合によく使用されます。
- MongoDBは、トランザクションと一貫性について心配する必要がないため、シャード（クラスターでの使用）が容易）です。
- MongoDBには速い書き込み速度があります。トランザクションやロールバックを心配する必要がないためです（したがって、ロックを心配する必要がないため）。
- MongoDB スキーマがないこれを利用できる特別なユースケースがある場合。
短所：
- MongoDB トランザクションをサポートしていません。これは、ほとんどの利点を得る方法です。
- 一般に、MongoDBはクライアントサーバーにより多くの作業（たとえば、より多くのCPUコスト）を作成します。たとえば、データを結合するには、複数のクエリを発行して、クライアントで結合を行う必要があります。
- ここ2017年でさえ、MongoDBの方がリレーショナルデータベースよりもツールのサポートが少ないの方が新しいという理由だけです。 MongoDBの専門家も少ないリレーショナルの対応者よりも少ない。
よく誤解されているポイント：
- MongoDBとリレーショナルデータベースの両方がインデックス作成をサポートしています。 これらのクエリのパフォーマンスは、大規模なクエリを実行するという点では似ています。
- MongoDBは移行の必要性を排除しませんまたはより具体的には、スキーマの進化に合わせて既存のデータを更新します。例：ユーザーテーブルに依存して特定のデータを含めるアプリケーションがあり、そのテーブルを変更して別のデータを含める場合（たとえば、プロフィール写真フィールドを追加するとします）、次のいずれかを行う必要があります。
- このプロパティが定義されていないオブジェクトを処理するアプリケーションを記述しますOR
- このプロパティのデフォルト値を入力する1回限りの移行を記述しますOR
- このフィールドが存在しない場合、クエリ時にデフォルト値を提供するコードを記述しますOR
- 欠落しているフィールドを別の方法で処理する
Renesis から恥知らずに盗むには（実際に私はこの答えをCWにしています）：
他のタイプの代わりにRDBMSを使用する：
- 「NoSQL」およびその他のDBタイプのアイデアについて読んでください。
- RDBMSは、パフォーマンスのためにインデックスを多用しています。非常に大規模なデータベースでは、このcanはパフォーマンスに悪影響を与えるか、さらに多くのハードウェアを必要とするDB /シャードあたりの最適な行数を削減します
- 大量のデータを保存しているが、読み取り頻度が低い場合は、理想的ではありません。
- 多くの外部関係がない場合、relationalデータベースは理想的ではない可能性があります（ドキュメントストレージ）
データがリレーショナルでない場合、パフォーマンスやスケーラビリティなどのNoSQLデータベースを使用することには大きなメリットがあります（もちろん、状況によって異なります）。 CQRSのような一部の設計パターンにより、従来はSQLデータベースの排他的使用を要求する領域で、非リレーショナルデータを活用することがはるかに容易になります。
キャッシュされたデータには、mongoなどのデータベースを使用するのが一般的です。たとえば、レポートを生成する必要がある場合、一連のデータをその場で結合して集計する複雑なSQLクエリを実行するか、mongoデータベースから生成する必要のあるすべてのものが既に含まれている単一のjsonドキュメントをフェッチするだけです。レポート。これにより、データの読み取りは非常に簡単（かつ高速です）になりますが、データの書き込みが非常に複雑になる可能性があります（CQRSの出番です）。
MongoDBのようなデータベースは、データがどこにあるかをよく知っている場合に便利です（いくつかの複雑なクエリを記述する必要があるのとは対照的です）。 Mongoでは、「関連」データは親データにネストされているか、主キー/外部キーがあります。これは、たとえば、投稿やコメントがある場合に便利です。通常、投稿のコンテキスト外にコメントを表示することはないため、投稿内にコメントを含めることは理にかなっています（そうすることで、別のテーブルをクエリする必要なく、投稿のすべてのコメントを取得できます）。
MongoDBはスキーマレスです。これは、ほとんどの場合、スローするデータの構造をとることを意味します。
一方、集約関数を使用する必要があり、Mongoの埋め込みや単純な関係では実現できない複雑な方法でデータをクエリする必要があると感じた場合は、MySQLやPostgreSQLなどのRDBMSを使用するときです。
MongoDBは、SQLを置き換えるものではありません。単に異なるニーズを満たし、MongoDBとRDBMSを組み合わせて使用できます。私の意見では、データを柔軟にしたり、親ドキュメントに埋め込んだりする必要がない場合、MongoDBはそれほど必要ではありません。 MongoDBを使用した開発は、プロジェクト（Railsなど）を稼働させるために必要な手順がはるかに少ないため、とても楽しいです。変更する必要がありますか？問題ない。モデルに属性を追加するだけです。できました。
他の多くのNoSQLデータベースについて話すことはできませんが、それらは通常、RDBMSでは満たすことができない特定のニーズを満たすように同様に設計されていることを知っています。一部は完全にメモリ内に常駐するか、非常に簡単にシャーディングまたはスケーリングできます。 Cassandraは、ノードがダウンしてもデータを失うことなく動作を継続するように設計されています。Redisは基本的にメモリ内に常駐するキー値ストアです（永続的なディスク書き込みにより）。また、セットなどのデータ型を保存してソートする機能もあります。
主なメリットは、データをシャーディングしたり、マルチマスターデータベースを作成したりする場合です。 MySQLでデータをシャーディングできますが、それは大きな痛みに変わります。多くの書き込みを行っている場合、複数のサーバー間でデータをシャーディングすると便利なことがよくあります。これを行う際に強い参照整合性が必要な場合、CAPの定理を不可能ではないにせよ非常に困難にすることができます。
SQLデータベースは一貫性は非常に優れていますが、パーティショニングのサポートは非常に悪く、NoSQLデータベースは逆の傾向があります。分割は簡単ですが、多くの場合、結果整合性と呼ばれます。大丈夫なメッセージングサイトを構築している場合、銀行にとってはおそらく大丈夫ではありません。
プラスは、データを格納する方法に複数のモデルがあり、SQLデータベースを使用する前は、データの実装方法に選択肢があることです。
SE Radioはこのテーマに関していくつかの良いエピソードを持っています。
MongoDBは、大量のデータを書き込む場合、およびクエリのニーズがそれほど複雑でない場合にうまく機能します。したがって、MongoDBは、コマンドサイドでイベントソーシングを使用してCQRSを実装する場合に適しています。つまり、イベントストアはMongoDBデータベースです。
クエリの側では、柔軟性があるため、ビューとWCFデータサービスを上に置いたSQL Serverデータベースを使用します。ほとんどの場合、クエリにはリレーショナルDBの機能が本当に必要になると思います。
MongoDBとRDBMSの直接の根本的な違いは、基礎となるデータモデルです。リレーショナルデータベースはデータをテーブルと行に構造化し、MongoDBはデータをJSONドキュメントのコレクションに構造化します。 JSONは、自己記述型の人間が読めるデータ形式です。もともとはブラウザとサーバー間の軽量交換用に設計されたもので、多くのタイプのアプリケーションで広く受け入れられています。
JSONドキュメントは、いくつかの理由でデータ管理に特に役立ちます。 JSONドキュメントは、それ自体がキーと値のペアであるフィールドのセットで構成されています。つまり、各JSONドキュメントは、人間が読める独自のスキーマ設計をどこにでも持ち運び、意味を失うことなく、データベースとクライアントアプリケーション間でドキュメントを簡単に移動できます。
JSONは、アプリケーション層で使用するための自然なデータ形式でもあります。 JSONは、列と行で構成されるテーブルよりも豊富で柔軟なデータ構造をサポートしています。数値、文字列、ブール値などのフィールドタイプをサポートすることに加えて、JSONフィールドは配列またはネストされたサブオブジェクトにすることができます。これは、アプリケーションが使用するオブジェクトのより詳細な表現である高度な関係のセットを表すことができることを意味します。データベースでJSONドキュメントを使用すると、データベースとそれが提供するアプリケーションとの間にオブジェクトリレーショナルマッパーが不要になります。適切な形式でデータを保持できます
データに多くのクエリが必要な場合、NoSQLソリューションは適切ではなく、トランザクションサポート（ACID）が必要な場合、NoSqlは最適ではありません。 NoSQLは、高速である必要がある多くの読み取りがあり、構造がややアドホックである場合に、ドキュメントまたはページ構造などで取得すると優れていると思います。しかし、多くのNoSQLソリューションはかなり速く改善されるため、欠点はすぐになくなるでしょう。とにかく、リレーショナルデータベースはまだほとんどのアプリケーションに適していると思います。