リレーショナルデータベースとグラフデータベースの比較
Neo4jなどのグラフデータベースと比較した、MySQLなどの関係データベースの長所と短所を誰かが説明できますか？
SQLには、それらをリンクするさまざまなIDを持つ複数のテーブルがあります。次に、テーブルを接続するために結合する必要があります。初心者の観点から、グラフデータベースのように最初からエッジとして明示的な接続を持たせるのではなく、結合を要求するようにデータベースを設計するのはなぜですか。概念的には、初心者には意味がありません。おそらく非常に技術的ではあるが概念的ではない理由がありますか？
実際には、両方のスタイルの背後に概念的な推論があります。 リレーショナルモデル および グラフデータベース のウィキペディアに、この概要が説明されています。
主な違いは、グラフデータベースでは、関係が個々のレコードレベルで保存されるのに対し、リレーショナルデータベースでは、構造がより高いレベル（テーブル定義）で定義されることです。
これには重要な影響があります。
- 膨大な数のレコードを操作する場合、リレーショナルデータベースは非常に高速です。グラフデータベースでは、データの構造を決定するためにクエリ中に各レコードを個別に調べる必要がありますが、これはリレーショナルデータベースで事前に知られています。
- リレーショナルデータベースは、これらの関係をすべて保存する必要がないため、使用するストレージ領域が少なくなります。
個々のレコードレベルですべてのリレーションシップを保存するのは、リレーションシップに多くのバリエーションがある場合にのみ意味があります。それ以外の場合は、同じものを繰り返し複製しているだけです。これは、グラフデータベースが不規則で複雑な構造に適していることを意味します。しかし、現実の世界では、ほとんどのデータベースには、通常の比較的単純な構造が必要です。これが、リレーショナルデータベースが優勢な理由です。
グラフとリレーショナルデータベースの主な違いは、リレーショナルデータベースはセットで機能し、グラフデータベースはパスで機能することです。
これは、RDBMSユーザーにとって予期しない、役に立たない方法で現れます。たとえば、リレーショナルデータベースに再帰的に参加することでパス操作（友人の友人など）をエミュレートしようとすると、クエリの待機時間が、メモリ使用量と同様に予測できないほど大きく増加します。もちろん、これらの種類の操作を表現するためにSQLを拷問します。賢明なインデックス作成によって苦痛を遅らせることができたとしても、セットベースのデータベースではデータが多いほど遅くなります。
Dan1111が示唆したように、ほとんどのグラフデータベースは、基本的なレベルで関係を表現するため、この種の結合の苦痛を受けません。つまり、リレーションシップはディスク上に物理的に存在し、名前が付けられ、指示され、それ自体がプロパティで装飾されます（これはプロパティグラフモデルと呼ばれます： https://github.com/tinkerpop/blueprints/wikiを参照してください/ Property-Graph-Model ）。つまり、選択した場合、ディスク上の関係を調べて、エンティティがどのように「結合」するかを確認できます。したがって、関係はグラフデータベースのファーストエンティティであり、リレーショナルストアの実行時に具体化される暗黙の関係よりも意味的にはるかに強力です。
なぜ気にする必要があるのですか？ 2つの理由：
- グラフデータベースは、接続されたデータのリレーショナルデータベースよりもはるかに高速です-基礎となるモデルの強みです。この結果、グラフデータベースのクエリ待機時間は、クエリで選択するグラフの量に比例し、保存されるデータの量に比例しないため、 join bomb =。
- グラフデータベースを使用すると、モデリングとクエリがより快適になり、開発期間が短縮され、WTFの瞬間が減ります。たとえば、Neo4jのCypherクエリ言語で一般的なソーシャルネットワークの友だちを表現するのは
MATCH (me)-[:FRIEND]->()-[:FRIEND]->(foaf) RETURN foafです。
Dan1111は、すでに正しいとフラグ付けされた回答を提供しています。いくつかの追加の点に注意する価値があります。
まず、グラフデータベースのほぼすべての実装では、現在の場所のレコードを指すポインタの数が不明であるため、レコードが「固定」されます。これは、古い場所に転送アドレスを残すか、不明な数のポインターを壊さずに、レコードを新しい場所にシャッフルできないことを意味します。
理論的には、すべてのレコードを一度にシャッフルし、すべてのポインターを見つけて修復する方法を見つけ出すことができます。実際には、これは大規模なグラフデータベースでは数週間かかる可能性がある操作であり、その間はデータベースをオフエアにする必要があります。それは実行不可能です。
対照的に、リレーショナルデータベースでは、レコードをかなり大規模にシャッフルすることができ、実行する必要があるのは、影響を受けたインデックスを再構築することだけです。これはかなり大規模な操作ですが、グラフデータベースに相当するものほど大きくはありません。
通過する際に注意する価値のある2番目のポイントは、World Wide Webが巨大なグラフデータベースとして見ることができるということです。 Webページにはハイパーリンクが含まれており、ハイパーリンクは、他のWebページなどを参照します。参照は、ポインターのように機能するURLを介して行われます。
転送アドレスを古いURLに残さずにWebページを別のURLに移動すると、不明な数のハイパーリンクが破損します。これらの壊れたリンクは、非常に多くのサーファーの喜びを妨げる恐ろしい「エラー404：ページが見つかりません」というメッセージを引き起こします。
リレーショナルデータベースを使用すると、外部キーと自己結合を使用してグラフをモデル化およびクエリできます。 RDBMSにWordリレーショナルが含まれているからといって、RDBMSが関係の処理に長けているという意味ではありません。 RDBMSのWordリレーショナルは、関係ではなく関係代数に由来します。 RDBMSでは、関係自体がオブジェクトとして存在することはありません。これは、明示的に外部キーとして、または暗黙的にリンクテーブルの値として表す必要があります（汎用/ユニバーサルモデリングアプローチを使用する場合）。データセット間のリンクはデータ自体に保存されます。
リレーショナルデータベースの検索の深さを増やすほど、実行する必要のある自己結合が増え、クエリのパフォーマンスが低下します。階層を深くするほど、結合する必要のあるテーブルが増え、クエリが遅くなります。数学的には、リレーショナルデータベースではコストが指数関数的に増加します。つまり、クエリとリレーションシップが複雑になるほど、グラフとリレーショナルデータベースのメリットが大きくなります。グラフをナビゲートする際のグラフデータベースのパフォーマンスの問題はありません。これは、グラフデータベースが関係を個別のオブジェクトとして保存するためです。ただし、優れた読み取りパフォーマンスを実現するには、書き込み速度が遅くなります。
特定の状況では、RDBMSよりもグラフデータベースのデータモデルを変更する方が簡単です。 RDBMSで、テーブルの関係を1：nからm：nに変更すると、ダウンタイムが発生する可能性があるDDLを適用する必要があります。
一方、RDBMSには他の分野での利点があります。データの集約、またはデータのタイムスタンプ付きバージョン管理を行います。
データウェアハウジングのグラフデータベース に関するブログ投稿で、他の長所と短所について説明します。
リレーショナルモデルはグラフモデルに含まれるデータを簡単に表すことができますが、実際には2つの重要な問題に直面しています。
- SQLには、グラフトラバーサル、特に深さが不明または無制限のトラバーサルを簡単に実行するための構文がありません。たとえば、SQLを使用して友人の友人を特定するのは簡単ですが、「分離度」の問題を解決するのは困難です。
- グラフを走査すると、パフォーマンスが急速に低下します。各レベルのトラバーサルにより、クエリの応答時間が大幅に増加します。
参照：次世代データベース