113

Neo4j などのグラフ データベースと比較した MySQL などのリレーション データベースの長所と短所を説明してもらえますか?

SQL では、それらをリンクするさまざまな ID を持つ複数のテーブルがあります。次に、テーブルを接続するために結合する必要があります。初心者の観点から、グラフデータベースのように最初からエッジとして接続を明示的にするのではなく、結合を必要とするようにデータベースを設計するのはなぜですか。概念的には、初心者には意味がありません。おそらく、これには非常に技術的であるが概念的ではない理由がありますか?

4

7 に答える 7

142

実際、両方のスタイルの背後には概念的な理由があります。リレーショナル モデルとグラフ データベースに関するウィキペディアには、この概要がよく示されています。

主な違いは、グラフ データベースではリレーションシップが個々のレコード レベルで格納されるのに対し、リレーショナル データベースでは構造がより高いレベル (テーブル定義) で定義されることです。

これには重要な影響があります。

  • 膨大な数のレコードを操作する場合、リレーショナル データベースははるかに高速です。グラフ データベースでは、データの構造を決定するためにクエリ中に各レコードを個別に調べる必要がありますが、リレーショナル データベースでは事前にわかっています。
  • リレーショナル データベースは、これらのリレーションシップをすべて格納する必要がないため、使用するストレージ スペースが少なくて済みます。

個々のレコード レベルですべての関係を格納することは、関係に多くのバリエーションがある場合にのみ意味があります。そうしないと、同じことを何度も複製しているだけです。これは、グラフ データベースが不規則で複雑な構造に適していることを意味します。しかし現実の世界では、ほとんどのデータベースは規則的で比較的単純な構造を必要とします。これが、リレーショナル データベースが主流である理由です。

于 2012-10-24T09:51:51.897 に答える
104

グラフ データベースとリレーショナル データベースの主な違いは、リレーショナル データベースはセットを処理するのに対し、グラフ データベースはパスを処理することです。

これは、RDBMS ユーザーにとって予想外で役に立たない形で現れます。たとえば、リレーショナル データベースに再帰的に参加することでパス操作 (たとえば、友達の友達) をエミュレートしようとすると、メモリ使用量と同様に、クエリの待機時間が予想外に大幅に増加します。これらの種類の操作を表現するために SQL を苦しめることは言うまでもありません。賢明なインデックス作成によって痛みを遅らせることができたとしても、セットベースのデータベースではデータが増えると速度が低下します。

Dan1111 が示唆したように、ほとんどのグラフ データベースは、基本的なレベルで関係を表現するため、この種の結合の問題に悩まされることはありません。つまり、リレーションシップはディスク上に物理的に存在し、名前が付けられ、指示され、プロパティで装飾することができます (これはプロパティ グラフ モデルと呼ばれます。https ://github.com/tinkerpop/blueprints/wiki/Property-Graph を参照してください)。 -モデル)。これは、必要に応じて、ディスク上の関係を調べて、エンティティがどのように「結合」されているかを確認できることを意味します。したがって、リレーションシップはグラフ データベースのファースト クラスのエンティティであり、実行時にリレーショナル ストアで具体化される暗黙のリレーションシップよりも意味的にはるかに強力です。

では、なぜ気にする必要があるのでしょうか。理由は 2 つあります。

  1. グラフ データベースは、接続されたデータのリレーショナル データベースよりもはるかに高速です。これは、基盤となるモデルの強みです。この結果、グラフ データベースでのクエリの待機時間は、クエリで探索するために選択したグラフの量に比例し、格納されているデータの量には比例しないため、結合爆弾が解消されます。
  2. グラフ データベースを使用すると、モデリングとクエリがはるかに快適になり、開発が速くなり、WTF の瞬間が少なくなります。たとえば、Neo4j の Cypher クエリ言語で典型的なソーシャル ネットワークの友人の友人を表現するのは、MATCH (me)-[:FRIEND]->()-[:FRIEND]->(foaf) RETURN foaf.
于 2013-07-30T09:17:31.810 に答える
22

Dan1111 は、既に正解としてフラグが立てられた回答を出しています。ついでに、注目に値する追加のポイントがいくつかあります。

まず、グラフ データベースのほとんどすべての実装では、現在の場所にあるレコードを指すポインターの数が不明なため、レコードは "固定" されます。これは、古い場所に転送アドレスを残すか、不明な数のポインターを壊さずに、レコードを新しい場所にシャッフルできないことを意味します。

理論的には、すべてのレコードを一度にシャッフルして、すべてのポインターを見つけて修復する方法を見つけることができます。実際には、これは大規模なグラフ データベースでは数週間かかる可能性がある操作であり、その間、データベースは通信を停止する必要があります。それは実現不可能です。

対照的に、リレーショナル データベースでは、レコードをかなり大規模に再シャッフルすることができ、影響を受けたインデックスを再構築するだけで済みます。これはかなり大規模な操作ですが、グラフ データベースの同等の操作にはほど遠いものです。

ついでに注目すべき 2 番目のポイントは、ワールド ワイド ウェブは巨大なグラフ データベースと見なすことができるということです。Web ページにはハイパーリンクが含まれており、ハイパーリンクは他の Web ページを参照します。参照は、ポインターのように機能する URL を介して行われます。

古い URL に転送アドレスを残さずに Web ページを別の URL に移動すると、不明な数のハイパーリンクが壊れます。これらの壊れたリンクは、恐ろしい「エラー 404: ページが見つかりません」というメッセージを発生させ、多くのサーファーの楽しみを妨げています。

于 2012-10-26T05:12:10.593 に答える