いつMongoDBを使うべきですか？
MongoDBはNoSQLデータベースで、非常に使いやすくなっています。最近、HTTPリクエストを使用してデータを収集し、データを処理した後に結果を保存する必要がある単純なアプリケーションを開発する必要があり、MongoDBを使用してみました。
この経験から、私は従来のリレーショナルデータベースよりも使いやすく、DBAではなく開発者なので、作業が大幅に簡略化されました。
それでも、SQL ServerやMySQLなどの従来のリレーショナルデータベースではなく、MongoDBをいつ使用すればよいかわからない場合があります。
その場合、リレーショナルデータベースの代わりにMongoDBをいつ使用できますか？ MongoDBについて、状況によっては不適切となる、真実なbig警告がありますか？
基本的に：
データを一連のドキュメントの形式で表すことができる場合、MongoDBが適切な選択肢になる可能性があります。
データを相互接続されたテーブルの束として想像したい場合は、MongoDBは適切な選択ではない可能性があります。
ここに私が説明する2つの例があります。
数年前、ブログエンジンを作成しました。その目的は、ブログ記事をホストし、すべての記事について、異なるバージョン、一部のメタデータ、訪問統計などを保存することです。
これは一連のテーブルとして保存できますが、モデルを作成しようとすると、それが非常に高速に成長して数十のテーブルになります。いくつかのSQLクエリは、多くの
joinsで醜くなる可能性があります。ここでの問題は、中心的なもの（ブログ記事）があり、記事の周りにこれらすべてのものがあるため、ドキュメントベースのデータベースに適しているということです。 MongoDBを使用すると、データベースのモデリングが非常に簡単になりました。1つのコレクションにはブログ記事が含まれ、2番目の小さなコレクションには記事の作成を許可されたユーザーのリストが含まれます。最初のコレクション内の各ドキュメントには、記事を表示するときに必要なすべての情報が含まれます。それは、著者の名前またはタグです。
今、非常に異なるプロジェクトを想像してみてください。何かを書いたり、他のユーザーが書いたものを共有したりできるユーザーがいます。ユーザーのページでは、このユーザーが書いたものと彼女が共有したものの両方が見つかるはずです。制約が1つあります。誰かが彼が過去に書いたものを編集すると、変更は元のテキストが共有されていたすべての場所に表示されます。
ドキュメントベースのアプローチでは、ドキュメントがどうなるかを見つけるのは困難です。たぶんユーザー？まあ、それは良いスタートです。ユーザー文書には、このユーザーが書いたすべてのものが含まれます。しかし、彼女が共有したものはどうですか？
可能な方法は、それらを同じドキュメントに入れることです。このアプローチの問題は、誰かがエントリを編集する場合、古いエントリのすべての発生を編集するために、アプリケーションはデータベース内のすべてのユーザードキュメントをウォークスルーする必要があることです。データの重複は数えません。
別の方法として、このユーザーが共有したエントリのリスト（参照されたユーザーとエントリのIDを含む）だけをユーザードキュメント内に保持することもできます。しかし今、別の問題が発生します。ユーザーが数千のユーザーからの数千のエントリを共有した場合、それらのエントリを取得するには数千のドキュメントを開く必要があります。
または、エントリ自体を中心にコレクションをモデル化することもできます。各エントリは作成者を参照し、それを共有したユーザーのリストを持っています。ここでも、特定のユーザーが発行したドキュメントを表示するためにすべてのドキュメントをウォークスルーする必要がある場合、パフォーマンスの問題が顕著になる可能性があります。
では、リレーショナルデータベースを使用している場合、どれだけのテーブルが必要になるでしょうか。そう、3つ。モデル化は簡単で、使用も簡単です。
それぞれのテクノロジーには利点があります。
リレーショナルデータベースの利点は、RDBMSが次のようなことを行うことです。
- 参照整合性の適用（所属する請求書が存在しない場合、請求書の詳細の挿入を許可しない）
- 冗長性を避けてください：物事は一度だけ保存されます。
- 複雑なクエリは、成熟しており、実績があり、広く普及している宣言型言語（SQL）で実行できます。
これは、RDBMSが強制的に実行するため、少ないコードを記述する必要があるという事実に要約されます。
さらに、データの独立性：多くの場合、標準SQL構造を使用し、ベンダー固有の構造を使用しない場合、最小限の手間でデータをあるRDBMSから別のRDBMSに移行できますが、NOSQLデータベースはまったく標準化されていません。
一方、NOSQLデータベースの利点の1つは、数百万行のパフォーマンスを維持しながら、より適切に拡張できることです。ドキュメントベースのストレージ、つまり非構造化データに適しています。しかし、ほとんどのアプリケーションはこれらの機能を必要としません。
あなたの特定のケースでは、MongoDBは良い選択のように聞こえますが、それが最良の選択ではない多くのシナリオ（おそらくそれらのほとんど）があります。
MongoDBは、トランザクションの安全性をそれほど重視せずに、データの読み取り/書き込み大量を必要とするシナリオに適しています（一部のデータがサーバークラッシュで失われることがある場合、それは大した問題ではありません）。規模が大きく、実際に安定したスキーマを持っていない。
MongoDBはnotが必要なシナリオに適しています。
- 強力なACID保証：MongoDBは、重複データの保存、一貫性のない読み取り、さらにはデータ損失さえも可能にします。これらのことは、一部のアプリケーションでは問題ありませんが、ほとんどのアプリケーションでは当てはまりません。
- マルチオブジェクトトランザクション：MongoDBはACIDトランザクションをサポートしていますが、単一のオブジェクト/ドキュメントのみをサポートしています。これは、銀行振込、予約などのより複雑な操作ではそれを削減しません。
- 従来のBI：従来のSQLでしか機能しない多くのBIツールがあります。
- SQL：MongoDBには非常に特定のクエリ言語がありますが、SQLは多くの人々に非常によく知られている（考慮すべき重要な側面かもしれません）が、多くの複雑なことを実行できます（MongoDBを使用すると、単純な参加）、多くの実装間で転送可能です。
MongoDBはより高速であり、整合性チェック（とにかくそのような目的のためにRDBMSを微調整することもできます）など、RDBMSがデフォルトで適用する多くの要素を排除することで、システムのパフォーマンスを向上させることができますが、真実はほとんどのシナリオでは、必要ありません。さらに、トレードオフは信頼性と柔軟性です（後で、既存のデータを使用してより複雑な操作を実行する必要があると判断した場合、問題が発生します）。
それはすべて、構築しているアプリケーションのニーズによって異なります。それは速度と可用性、または安全性、信頼性と柔軟性です。データ（およびデータの接続）のどこに価値があるかを知る必要があります。まだわからない場合は、将来的に隅々まであなたをペイントしないものを選択し、機能を追加してアプリケーションに必要な操作を実行できるようにするのがおそらく最善です。
MongoDBは、データを独立した情報の「パッケージ」として表すことができる場合に最適です。あなたはグーグルマップの郵便番号を持っています、郵便番号に埋め込まれているのは会社であり、会社の内部は従業員です。すべての郵便番号は互いに独立しており、すべての情報をシンプル、きれい、そして高速に取得できます。これは、非SQLソリューションの良いシナリオです。
そうは言っても、MongoDBはRDBMSに対する一種のポストおよび優れたソリューションであり、デフォルトではnoSQLがソリューションである必要があることを意味する、私が探している現在の傾向に完全に同意しません。それはすべてばかげています。 MongoDBはニッチデータベースであり、プロジェクトの90％はリレーショナルであり、SQLのような強力なクエリソリューションでレポートを生成し、分散データを探すため、RDBMSオプションが必要です。さらに、最新のRDBMSはBSONコレクションと地理空間統合をサポートしているため、おそらくnoSQLのニッチはさらに狭くなっています。
MongoDBは、Webページの特定のインスタンスを構築するために必要な構造化データ全体を格納するのに役立ちます。特定のページのデータを取得し、それをクライアントアプリケーションに渡して、レンダリングできるようにすることができます。
このような状況では、MongoDBは非常に高速で信頼性があります。ただし、データベースにリレーショナル情報がないことを忘れないでください。つまり、Webページの構造を変更した場合、必要なデータがないため、既に保存されているページの穴を埋めることができない可能性があります。詳細はこちら： http://www.sarahmei.com/blog/2013/11/11/why-you-should-never-use-mongodb/