MongoDBがスケーリングできる簡単な例が必要ですが、リレーショナルデータベースで問題が発生します[終了]

私はMongoDBの使い方を学んでいるだけで、他のプログラマーと話し合うときに、従来のRDBMSと比較してNoSQLが優れた選択肢である理由の簡単な例が必要です。

たとえば、大量のトラフィックを含むブログは関係的に表すことができますが、パフォーマンスのチューニングとテーブル間の結合が必要になります（完全な非正規化が使用されていると想定）。一方、MongoDBでは、1つのコレクションから直接取得して同じ効果を得ることができます。

しかし、私が他のプログラマーから得ている反応は、「なぜそれをリレーショナルに保ち、後で簡単なキャッシングを追加しないのか」です。

MongoDBが実際に輝き、リレーショナルデータベースがはるかに速くフォールオーバーするという、それほど単純な例はありませんか？プロジェクト/システムが小さければ小さいほど、意見の不一致の余地が少なくなるため、優れています。

ブログの例の複雑さの線に沿った何かが本当に役立つでしょう。

ありがとう。

最初に、それはよくスケーリングします。

MongoDBデータベースの頻度が高すぎるか、単一のサーバーに対して大きすぎる場合は、複数のシャードのクラスターまたはレプリカセットを作成することで、サーバーを簡単に追加できます。ほぼ線形にスケーリングします。これは、ほとんどのリレーショナルデータベースではほとんど機能しません。たとえば、クラスターとして機能する場合のMySQLの制限のリストをご覧ください。リストのほとんどのエントリは、MongoDBでは問題ありません（または適用されません）。

第二に、異機種混在のデータを許可します。

たとえば、コンピュータハードウェアストアの製品データベースを想像してみてください。製品にはどのような特性がありますか？すべての製品には価格とベンダーがあります。しかし、CPUにはクロックレートがあり、ハードドライブとRAMチップには容量があり（これらの容量は比較できません）、モニターには解像度があります。リレーショナルデータベースでこれをどのように設計しますか？非常に長いproductID-property-valueテーブルを作成するか、想像できるすべてのプロパティを備えた非常に広くてまばらなproductテーブルを作成しますが、それらのほとんどはNULLほとんどの製品に対応しています。どちらのソリューションも本当にエレガントではありません。しかし、MongoDBを使用すると、コレクション内の各ドキュメントに異なるプロパティセットを設定できるため、これをより適切に解決できます。

問題のいくつかの実世界の例私は、SQLとリレーショナルデータベースのみを使用して合理的な方法で解決する方法がわからないでしょう（おそらく私の過失）。

したがって、約30,000の製品を含む（一般的なリレーショナル）データベースがあります。今のところ大きなことはありません。これらの各製品には多くの属性があります。グループ（ケーブル、アンテナ、iphoneケース...約80）、品揃え（グループにいくらか似ている：車、ハイファイ、mp3、15のみ）、ブランド（30）などの一般的なものがあります。

次に、技術データが表示されます。各アイテムには、色、ケーブルの長さ、重量、体積などの多くのものがあります。約200のそのような値タイプと数千の値。

そして最も複雑なのは、これらの製品の多くは、ある車種（またはそれらのいくつか）またはある種のモバイルデバイスに属していることです。これらは、ブランド（アップル）モデル（ipad）タイプ（1,2,3,4）のような形式で、場合によっては生成された階層になっています。（車の場合も同様ですが、世代の代わりに年を構築しています）

問題のステップ1：

これらの各属性の商品の量が必要です。赤は何枚ですか？ケーブルグループにはいくつありますか？等々。

これは部分的にSQLで解決できます。それは多くのクエリとかなり醜いでしょうが、私は可能だと思います。遅くなるかもしれませんが、それをもっと醜くして、各テーブルにカウンターを保持し、変更のたびに更新することもできます。製品が複数ある可能性がある属性では特に難しい（iPhoneや他の12の携帯電話で動作するなど）

しかし、ここに問題のステップ2があります。

顧客が1つの属性を選択した場合（たとえば、赤い商品のみを表示したい場合）、すべてのカウンターをリアルタイムで更新します。つまり、非常に複雑なクエリを実行するか（とにかく速度が十分でない可能性があります）、属性の可能な組み合わせ（数十億）のカウンターを保持します。

私がこのプロジェクトを始めたとき、彼らはカウンターオプションを試してみて、属性の非常に小さなサブセット（グループ、品揃え、ブランド）に対してこれを行いました。コードは醜く、バグが多く、遅いものでした。さらに、製品のテーブルよりもはるかに大きいカウンターを備えたテーブルができました。

Apache Solrのファセットを使用することが実際の解決策でした。テーブルをドキュメントのリスト（製品ごとに1つ）にフラット化して、はるかに単純なクエリでリアルタイムでこのすべてのデータを取得できるようにします。

EAVテーブルが物事を行うための最良の方法であると考えるときはいつでも考えることができます（現実的なデータベースでは非常に遅く、クエリが難しい）。nosqlデータベースが必要になる場合があります。これは、フィールドがどうなるかを事前に知る方法がない場合に特に当てはまります。例としては、医療検査の詳細の保存があります。新しいテストごとに、格納する必要のあるまったく異なるデータが含まれる場合があります。（理論的には）既存のテストをモデル化することはできますが（数千に及ぶため、多くの時間と労力で）、私たちが持っていないテスト（そしておそらく医療機器）からどのような新しい結果が得られるかをどのようにして知ることができますか？まだ発明されています。

プロジェクト/システムが小さければ小さいほど、意見の不一致の余地が少なくなるため、優れています。

NoSQLは大規模環境でのみ優れているため、これは困難です。私はあなたが簡単な例を意味していると思います、そして私はあなたに完璧なものを持っています。

旅行のウェブサイトを作成していて、ユーザーが他の（同じ）5,170の米国の空港のいずれかを宛先とする5,170の米国の空港から旅行する必要があるとします...

しかし、ここにキッカーがあります。すべてのフライトが直行しているわけではありません。ストップオーバーのオプションもすべてユーザーに伝える必要があります。ストップオーバーは2つか3つになることもあります。また、5時間以内にすべてのオプションをユーザーに通知する必要があります。そして、ユーザーが待っている間、これを10秒未満で計算する必要があります。

これは、リレーショナルDBの悪夢です... NoSqlが来ると、通常、飛行ルートは数週間前に石に設定されます。そのため、単純なNoSql DBクラスターよりも、事前にストアですべてのガジリオンの可能性のあるルーティングを計算できます...

NoSqlは、勝者がそのようなシナリオであることは明らかです。