誰かがリレーショナルDBMSでMongoDB（または同様の）を使用するのはいつですか？

私は、NoSQL全体などについて少し混乱しています。OracleやMySQLのようなものよりもMongoDBのようなものを使用することを選択するのはいつですか？使い方がそれらの間で異なる限り、私は「違い」を本当に理解していません。

私の理解では、NoSQLタイプのデータベースはRDBMSに代わるものではありませんが、正確には何を意味するのでしょうか？

3つのペットプロジェクトでCouchDBを使用したことがあります。

• マイクロブログシステム。
• 私が作った小さなメモを取るアプリの情報を保存するため。
• 汎用のブレーンストーミングアプリケーション。

MSSQLやMySQLのようなものよりもこれを選んだ主な理由は、それを使用するときに得られる柔軟性です。厳格なスキーマはありません。3か月後、特定のテーブルに追加のフィールドが必要であり、これとそれが必要な場合は、それを変更するだけで、そこから波及します。

私が使用し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タイプのアイデアを読んでください。
  • NoSQL：簡単だったら
  • （上記のリンク先）MongoDBまたは他のドキュメント指向のデータベースシステムを使用する場合 ^{SOで現在削除されています}（詳細）
  • https://softwareengineering.stackexchange.com/questions/5354/are-nosql-databases-going-to-take-the-place-of-relational-databases-is-sql-going
  • CouchDBとRDBMSを使用する場合
• RDBMSはパフォーマンスのためにインデックス作成を多用します。非常に大規模なデータベースでは、これはパフォーマンスに悪影響を及ぼしたり、DB /シャードあたりの最適な行数を減らしたり、より多くのハードウェアを必要とする可能性があります
• 大量のデータを保存しているが、読み取り頻度が少ない場合は理想的ではありません
• 外国の関係があまりない場合、リレーショナルデータベースは理想的ではないかもしれません（ドキュメントストレージ）

データがリレーショナルでない場合、パフォーマンスやスケーラビリティなどの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 Data Servicesが先頭にあるSQL Server dbを引き続き使用します。ほとんどの場合、クエリにはリレーショナルDBのパワーが本当に必要になると思います。

MongoDBとRDBMSの直接的な根本的な違いは、基礎となるデータモデルです。リレーショナルデータベースはデータをテーブルと行に構成し、MongoDBはデータをJSONドキュメントのコレクションに構成します。JSONは、自己記述的で人間が読み取り可能なデータ形式です。元々はブラウザとサーバー間の軽量な交換用に設計されたもので、多くの種類のアプリケーションで広く受け入れられています。

JSONドキュメントは、いくつかの理由でデータ管理に特に役立ちます。JSONドキュメントは、それ自体がキーと値のペアである一連のフィールドで構成されます。つまり、各JSONドキュメントは、どこにいても人間が読める独自のスキーマ設計を持ち、意味を失うことなく、データベースとクライアントアプリケーション間でドキュメントを簡単に移動できます。

JSONは、アプリケーション層で使用するための自然なデータ形式でもあります。JSONは、列と行で構成されるテーブルよりも豊富で柔軟性のあるデータ構造をサポートします。JSONフィールドは、数値、文字列、ブール値などのフィールドタイプをサポートすることに加えて、配列またはネストされたサブオブジェクトにすることができます。これは、アプリケーションが動作するオブジェクトをより厳密に表現した一連の洗練された関係を表現できることを意味します。データベースでJSONドキュメントを使用するということは、データベースとそれが提供するアプリケーションの間にオブジェクトリレーショナルマッパーが必要ないことを意味します。適切な形式でデータを保持できます

データに大量のクエリが必要な場合、NoSQLソリューションは適切ではなく、トランザクションサポート（ACID）が必要な場合、NoSqlは最適ではありません。NoSQLは、高速にする必要がある読み取りが多く、構造がある程度アドホックで、ドキュメントまたはページ構造などで取得する場合に優れていると思います。しかし、多くのNoSQLソリューションは非常に速く改善されるため、すぐに欠点がなくなるかもしれません。とにかく、ほとんどのアプリケーションにリレーショナルデータベースが適していると思います。