MongoDBをいつ使用する必要がありますか？

MongoDBは、非常に使いやすいことがわかっているNoSQLデータベースです。最近、HTTPリクエストを使用していくつかのデータを収集し、データの処理後に結果を保存する必要のある簡単なアプリケーションを開発する必要があり、MongoDBを使用してみました。

この経験から、私は従来のリレーショナルデータベースよりもはるかに使いやすく、DBAではなく開発者であるため、作業が大幅に簡素化されました。

それでも、SQL ServerやMySQLのような従来のリレーショナルデータベースの代わりにMongoDBをいつ使用すべきかわからないことがあります。

その場合、リレーショナルデータベースの代わりにMongoDBを使用できるのはいつですか？MongoDBに関して、状況によっては不適切となる、非常に大きな警告がありますか？

基本的に：

• 大量のドキュメントの形式でデータを表現できる場合、MongoDBが適切な選択になる可能性があります。

• データを相互接続されたテーブルの束として想像したい場合、MongoDBは良い選択ではないかもしれません。

以下に例を示します。

• 数年前、私はブログエンジンを作成しました。その目的は、ブログ記事をホストし、すべての記事について、異なるバージョン、いくつかのメタデータ、訪問統計などを保存することです。

  これはテーブルの束として保存できますが、モデルを構築しようとすると、それ以上ではないにしても、非常に高速で数十のテーブルに成長します。いくつかのSQLクエリは、多くのjoinsでugいものになる可能性があります...そして、よくわかります。

  ここでの問題は、ブログ記事という中心的なものがあり、記事の周りにこれらすべてが存在するため、ドキュメントベースのデータベースに適しているということです。MongoDBを使用すると、データベースのモデリングは非常に簡単でした。1つのコレクションにはブログ記事が含まれ、2番目の小さなコレクションには記事を書くことができるユーザーのリストが含まれます。最初のコレクション内の各ドキュメントには、記事を表示するときに必要なすべての情報が含まれます。これは、著者の名前、またはタグです。

• 今、非常に異なるプロジェクトを想像してください。ものを書いたり、他のユーザーが書いたものを共有したりできるユーザーがいます。ユーザーのページでは、このユーザーが書いたものと彼女が共有したものの両方を見つけることができます。制約が1つあります。誰かが過去に書いたものを編集すると、元のテキストが共有されたすべての場所に変更が表示されます。

  文書ベースのアプローチでは、文書となるものを見つけるのは困難です。多分ユーザー？まあ、それは良いスタートです。ユーザー文書には、このユーザーが書いたすべてのものが含まれます。しかし、彼女が共有したものはどうですか？

  考えられる方法は、それらを同じドキュメントに入れることです。このアプローチの問題は、誰かがエントリを編集した場合、アプリケーションはデータベース内のすべてのユーザードキュメントを調べて、古いエントリをすべて編集する必要があることです。データの重複はカウントしません。

  別の方法として、ユーザー文書内に、このユーザーが共有したエントリのリストのみを保持することもあります（参照されたユーザーとエントリのIDを使用）。しかし、今度は別の問題が発生します。ユーザーが数千のユーザーから数千のエントリーを共有した場合、それらのエントリーを取得するには数千のドキュメントを開く必要があります。

  または、エントリ自体を中心にコレクションをモデル化できます。各エントリは、作成者を参照し、共有したユーザーのリストを持ちます。ここでも、特定のユーザーが公開したドキュメントを表示するためにすべてのドキュメントを確認する必要がある場合、パフォーマンスの問題が顕著になる可能性があります。

  リレーショナルデータベースを使用している場合、どれだけのテーブルが必要ですか？そう、3。モデル化するのは簡単であり、使用するのも簡単です。

それぞれの技術には利点があります。

リレーショナルデータベースの利点は、RDBMSが次のような処理を行うことです。

• 参照整合性を強制する（所属する請求書が存在しない場合、請求書詳細の挿入を許可しない）
• 冗長性を避けます。物は一度だけ保存されます。
• 複雑なクエリは、成熟し、実績があり、広く普及している宣言型言語（SQL）を使用して実行できます。

要するに、RDBMSがあなたのために物事を強制するので、より少ないコードを書く必要があるという事実に要約されます。

さらに、データの独立性：多くの場合、標準のSQL構造を使用し、ベンダー固有の構造を使用しない場合、最小限の手間で1つのRDBMSから別のRDBMSにデータを移行できますが、NOSQLデータベースはまったく標準化されていません。

一方、NOSQLデータベースの利点の1つは、数百万行のパフォーマンスを維持しつつ拡張性が高いことです。ドキュメントベースのストレージ、つまり非構造化データにより適しています。しかし、ほとんどのアプリケーションはこれらの機能を必要としません。

あなたの特定の場合、MongoDBは良い選択のように思えますが、最良の選択ではないシナリオ（おそらくそれらのほとんど）がたくさんあります。

MongoDBは、トランザクションの安全性をあまり重視せずに大量のデータの読み取り/書き込みを必要とするシナリオに適しています（サーバークラッシュでデータが時々失われる場合、それは大したことではありません）。本当に安定したスキーマがあります。

MongoDBは、以下を必要とするシナリオには適していません。

1. ACIDの強力な保証：MongoDBでは、重複データの保存、一貫性のない読み取り、さらにはデータ損失が可能です。これらのことは一部のアプリケーションでは問題ありませんが、ほとんどのアプリケーションではうまくいきません。
2. マルチオブジェクトトランザクション：MongoDBはACIDトランザクションをサポートしますが、単一のオブジェクト/ドキュメントに対してのみです。これは、銀行振込、予約などのより複雑な操作のためにそれをカットしません。
3. 従来のBI：従来のSQLでしかうまく機能しないBIツールがたくさんあります。
4. SQL：MongoDBには非常に特殊なクエリ言語がありますが、SQLは多くの人によく知られています（考慮すべき重要な側面かもしれません）が、多くの複雑なことを行うことができます（一方、MongoDBでは、単純な参加）多くの実装間で転送可能です。

MongoDBは高速であり、整合性チェックなどのようにRDBMSがデフォルトで実施する多くのものを排除することにより、システムからより多くのパフォーマンスを引き出すことができます（とにかくそのような目的のためにRDBMSを調整することもできます）ほとんどのシナリオでは、必要ありません。さらに、トレードオフは信頼性と柔軟性です（後で、既存のデータを使用してより複雑な操作を行う必要があると判断した場合、問題が発生します）。

それはすべて、構築するアプリケーションのニーズに依存します。速度と可用性、または安全性、信頼性、柔軟性です。データ（およびデータの接続）のどこに価値があるかを知る必要があります。まだわからない場合は、将来あなたを隅に追いやることがなく、アプリケーションに必要な機能を追加して操作を実行できるものを選択するのがおそらく最善です。

MongoDBは、データを独立した情報の「パッケージ」として表現できる場合に役立ちます。Googleマップの郵便番号があり、郵便番号に埋め込まれているのは会社であり、会社の内部には従業員がいます。すべての郵便番号は互いに独立しており、シンプルできれいな方法ですべての情報を取得できます。これは、SQL以外のソリューションに適したシナリオです。

一度言ったが、MongoDBはRDBMSに対する一種の優れたソリューションであり、デフォルトではnoSQLがソリ​​ューションである必要があることを示唆している現在の傾向にはまったく同意しません。それはすべてばかげています。MongoDBはニッチデータベースであり、プロジェクトの90％はリレーショナルであり、SQLのような強力なクエリソリューションでレポートを生成し、分散データを探すため、RDBMSオプションが必要です。「結合」は賛否両論ではありません。その上、最新のRDBMSはBSONコレクションと地理空間統合をサポートしているため、noSQLのニッチは今ではさらに狭くなっているかもしれません。

MongoDBは、Webページの特定のインスタンスを構築するために必要な構造化データ全体を保存するのに役立ちます。特定のページのデータを取得し、それをクライアントアプリケーションに渡して、レンダリングできます。

そのような状況では、MongoDBは非常に高速で信頼性があります。ただし、データベースにリレーショナル情報がないことを決して忘れないでください。つまり、ウェブページの構造を変更すると、必要なデータがないため、既に保存されているページの穴を埋めることができなくなる可能性があります。詳細はこちら：http : //www.sarahmei.com/blog/2013/11/11/why-you-should-never-use-mongodb/