リレーショナルデータベースとグラフデータベースの比較

誰かが、Neo4jなどのグラフデータベースと比較したMySQLなどのリレーションデータベースの利点と欠点を私に説明できますか？

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

実際、両方のスタイルの背後には概念的な推論があります。リレーショナルモデルとグラフデータベースに関するWikipediaは、これについての概要を示しています。

主な違いは、グラフデータベースでは関係が個々のレコードレベルで保存されるのに対し、リレーショナルデータベースでは構造が上位レベル（テーブル定義）で定義されることです。

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

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

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

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

これは、RDBMSユーザーにとって予期せぬ、役に立たない方法で現れます。たとえば、リレーショナルデータベースに再帰的に参加してパス操作（友人の友人など）をエミュレートしようとすると、クエリのレイテンシが予測できないほど大きくなり、メモリ使用量も増加します。SQLを拷問してこれらの種類の操作を表現することは言うまでもありません。賢明なインデックス作成によって痛みを遅らせることができたとしても、データが多いほど、セットベースのデータベースでは遅くなります。

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

なぜあなたは気にする必要がありますか？2つの理由があります。

1. グラフデータベースは、接続されたデータのリレーショナルデータベースよりもはるかに高速です。これは、基礎となるモデルの長所です。この結果、グラフデータベースでのクエリの待機時間は、クエリで探索するグラフの量に比例し、格納されているデータの量に比例しないため、結合爆弾が排除されます。
2. グラフデータベースを使用すると、モデリングとクエリがはるかに快適になり、開発が速くなり、WTFモーメントが少なくなります。たとえば、Neo4jのCypherクエリ言語で一般的なソーシャルネットワークの友だちを表現するのはちょうどMATCH (me)-[:FRIEND]->()-[:FRIEND]->(foaf) RETURN foafです。

Dan1111は、正しいフラグが付けられた回答をすでに提供しています。いくつかの追加のポイントが通過することに注目する価値があります。

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

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

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

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

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

リレーショナルデータベースを使用すると、外部キーと自己結合を使用してグラフをモデル化し、クエリを実行できます。RDBMSにリレーショナルという単語が含まれているからといって、RDBMSが関係の処理に優れているとは限りません。RDBMSでの関係という用語は、関係代数に由来し、関係には由来しません。RDBMSでは、関係自体はそれ自体のオブジェクトとして存在しません。外部キーとして明示的に表すか、リンクテーブルの値として暗黙的に表す必要があります（ジェネリック/ユニバーサルモデリングアプローチを使用する場合）。データセット間のリンクは、データ自体に格納されます。

リレーショナルデータベースで検索の深さを増やすほど、実行する必要がある自己結合が増え、クエリのパフォーマンスが低下します。階層が深くなるほど、結合する必要のあるテーブルが多くなり、クエリが遅くなります。数学的には、リレーショナルデータベースではコストが指数関数的に増加します。つまり、クエリとリレーションシップが複雑になるほど、リレーショナルデータベースと比較してグラフのメリットが大きくなります。グラフをナビゲートするとき、グラフデータベースにパフォーマンスの問題はありません。これは、グラフデータベースが関係を個別のオブジェクトとして格納するためです。ただし、優れた読み取りパフォーマンスでは、書き込みが遅くなります。

特定の状況では、RDBMSよりもグラフデータベースのデータモデルを変更する方が簡単です。たとえば、RDBMSの場合、テーブルの関係を1：nからm：nに変更すると、ダウンタイムの可能性があるDDLを適用する必要があります。

一方、RDBMSには、データの集計やデータのタイムスタンプ付きバージョン管理など、他の領域での利点があります。

データウェアハウジングのためのグラフデータベースに関する私のブログ投稿で、他の長所と短所のいくつかについて説明します

リレーショナルモデルはグラフモデルに含まれるデータを簡単に表すことができますが、実際には次の2つの重大な問題に直面します。

1. SQLには、グラフトラバーサル、特に深度が不明または制限されていないトラバーサルを簡単に実行するための構文がありません。たとえば、SQLを使用して友達の友達を特定するのは簡単ですが、「分離度」の問題を解決するのは困難です。
2. グラフをトラバースすると、パフォーマンスが急速に低下します。トラバーサルの各レベルにより、クエリの応答時間が大幅に増加します。

リファレンス：次世代データベース

グラフデータベースは、それらが得意とするユースケースについて調査する価値がありますが、上記の応答でいくつかの主張を疑問視する理由がありました。特に：

膨大な数のレコードを操作する場合、リレーショナルデータベースははるかに高速です（dan1111の最初の箇条書き）

グラフデータベースは、接続されたデータのリレーショナルデータベースよりもはるかに高速です。これは、基礎となるモデルの長所です。この結果、グラフデータベースでのクエリの待機時間は、クエリで探索することを選択したグラフの量に比例し、格納されているデータの量に比例しないため、結合爆弾が排除されます。（ジムウェバーの最初の箇条書き）

言い換えると、クエリと関係が複雑になるほど、リレーショナルデータベースよりもグラフのほうがメリットが大きくなります。（ウリベスケの2番目の段落）

これらのアサーションには十分なメリットがあるかもしれませんが、私の特定のユースケースをアサーションに合わせる方法をまだ見つけていません。リファレンス：グラフデータベースまたはリレーショナルデータベースの共通テーブル拡張：非循環グラフクエリのパフォーマンスの比較