グラフデータベースとリレーショナルデータベースの違い
グラフデータベースとリレーショナルデータベースは両方とも、関係を持つ関連データ項目を保存しますが、データ関係の表現方法は非常に異なります。リレーショナルデータベースは、行と列を含む表形式でデータを保存します。すべてのデータもテーブルに保存され、データ間の関係は元のテーブルへの参照として保存されます (外部キーとも呼ばれます)。実行時に、リレーショナルデータベースは JOIN ステートメントを使用してこれらの参照を明示的に解決します。ほとんどのリレーショナルデータベースは、特定の規模ではこれを効率的に実行できますが、ソーシャルネットワークで 2 人の関係を調べるなど、不明な数のつながりを通じて関連を検索する場合など、多数または不明な数のこれらの参照を処理する必要がある場合、これらのオペレーションは非効率的になります。
これとは対照的に、グラフデータベースはデータをエンティティと関係性のネットワークとして保存します。グラフデータベースは、データを参照として保存するのではなく、エンティティデータと関係データの両方を明示的に保存します。実行時に、グラフデータベースは数学的なグラフ理論を活用して、エンティティと関係に対するオペレーションを効率的に実行します。エンティティ間の関係は、計算されるのではなく、明示的に保存されるため、複雑なデータ相互接続を伴うユースケースでは、データベースを使用することでクエリとメモリ管理がより効率的になり、アプリケーションのパフォーマンスが大幅に改善される場合があります。
データモデル: グラフデータベースとリレーショナルデータベース
グラフデータベースとリレーショナルデータベースはいずれも情報を格納し、データ間の関係を表します。しかし、リレーショナルモデルがデータエンティティを優先するのに対し、グラフモデルはエンティティ間の関係を優先します。
リレーショナルデータベースモデル
リレーショナルデータベースは、情報を行と列に整理するデータテーブルを使用します。列はデータエンティティの特定の属性を保持し、行は個々のデータレコードを表します。
リレーショナルデータベースの固定スキーマでは、プライマリキーと外部キーでテーブル間の関係を前もって示しておく必要があります。
例
お客様のプロフィールで互いに友達になれるソーシャルメディアアプリケーションを考えてみましょう。通常のモデルでデータをモデル化するには 2 つのテーブルが必要です。
お客様テーブルは次のようになります。
ID |
名前 |
位置 |
C1 |
Alejandro |
米国 |
C2 |
Ana |
米国 |
C3 |
Kwaku |
米国 |
C4 |
Pat |
米国 |
友達テーブルは次のようになります。
お客様 ID |
友達 ID |
C1 |
C2 |
C1 |
C3 |
C2 |
C4 |
C2 |
C1 |
C3 |
C1 |
C3 |
C4 |
クエリ時に、「Alejandro の友達の名前は何ですか?」などの質問に答える場合、データベースエンジンはまず、[お客様] テーブルで Alejandro の行を見つけます。
ID |
名前 |
位置 |
C1 |
Alejandro |
米国 |
次に、エンジンは Alejandro の ID を使用して、Alejandro の [友達] テーブルのすべての行の結合を作成します
ID |
名前 |
位置 |
お客様 ID |
友達 ID |
C1 |
Alejandro |
米国 |
C1 |
C2 |
C1 |
Alejandro |
米国 |
C1 |
C3 |
その後、エンジンは各行について、[友達 ID] ごとに結合を作成して [お客様] テーブルに戻します
ID |
名前 |
位置 |
お客様 ID |
友達 ID |
ID |
名前 |
位置 |
C1 |
Alejandro |
米国 |
C1 |
C2 |
C2 |
Ana |
米国 |
C1 |
Alejandro |
米国 |
C1 |
C3 |
C3 |
Kwaku |
米国 |
最後に、エンジンは Alejandro の友達の名前を返します。
名前 |
Ana |
Kwaku |
ご覧のとおり、リレーショナルデータ内のつながりを使用する際には、取得しようとしている情報を表すために大きなデータ構造を構築することになります。リレーショナルデータベースには、これらの構造の影響を最小限に抑えるための最適化が組み込まれていますが、結合の数が増えると、必要なデータ量が大幅に増加して、パフォーマンスが低下し、メモリ使用量が増加します。
グラフデータベースモデル
一方、グラフデータベースは、属性、関係、およびオブジェクトを含むグラフ構造を使用してデータを表します。ノードはオブジェクトであり、エッジはそれらのノード間の関係を示し、プロパティはノードとエッジの属性を記述します。この動的な構造により、グラフデータベースは連結データの表現に有用です。関係とデータ型に関する柔軟性が向上します。
例
上記と同じソーシャルネットワークデータの例を使用すると、グラフデータベースは、それぞれ 4 つのプロパティと 2 つのエッジを持つ 3 つのノードを使用してデータを格納します。
では、グラフデータベースがクエリ「Alejandro の友達の名前は何ですか?」を処理する方法を見てみましょう。
まず、Alejandro を表す [お客様] ノードを探します (以下で強調表示されています)。
次に、友達のエッジをトラバース、つまり移動します。グラフデータベースでのトラバースは、リレーショナルデータベースでの JOIN の実行に似ていますが、明示的にリクエストされない限り、クエリで前に取得された情報は保持されません。以下の例では、2 つの友達のエッジのみがメモリに保持されます。
3 番目に、隣接するノードへのトラバースを続行します。
最後に、エンジンは Alejandro の友達の名前を返します。
名前 |
Ana |
Kwaku |
ご覧のとおり、両方のエンジンは同じ情報を返すことができますが、多くのつながりをトラバースする場合、グラフデータベースで関係を明示的に保存すると、このリクエストをより効率的に処理できます。この利点は、ここに示すようなシンプルなクエリでは重要ではありませんが、この最適化とグラフクエリ言語の構造により、多数の、または不明な数のこれらの関係トラバーサルを必要とする質問を処理する際の複雑さとメモリ使用量が大幅に削減される場合があります。
主な相違点: グラフデータベースとリレーショナルデータベース
リレーショナルデータベースとグラフデータベースは、データモデルが異なるだけでなく、機能とユーティリティの点で多くの相違点があります。
クエリ実行
グラフデータベースは、コネクテッドデータを迅速に検索して取得するように最適化されたカスタムクエリ言語を使用します。これらの言語 (TinkerPop Gremlin、openCypher、SPARQL など) は、再帰データアクセス、パス検索、グラフアルゴリズムなどのオペレーションに必要となる、複雑なデータ相互接続を活用するクエリの記述を簡素化するために特別に構築されています。
対照的に、リレーショナルデータベースは、SQL を使用してデータを取得、操作します。ユーザーは、SQL を使用することで、SELECT、INSERT、UPDATE、DELETE など、さまざまなタイプのクエリをテーブルに対して実行することができます。リレーショナルデータベースは、テーブル間の関係が明確に定義されている構造化データの処理において優れています。複数のテーブルで複雑なフィルタリング、集計、および結合を行う場合に特に効果的です。
パフォーマンス
グラフデータベースは、オブジェクトと関係の両方をデータとして保存し、インデックスを使用して関連するエンティティ間を効率的にトラバースします。グラフデータベースは関係をデータとして保存するため、データベースはこれらの接続を動的に計算することなく、エンティティ間を迅速に移動できます。ノード間の直接接続により即時アクセスが可能になるため、関係を迅速にクエリしてトレースできます。これらの機能により、グラフデータベースは非常に効率的です。
あるいは、リレーショナルデータベースは、インデックス検索と動的に計算された結合を使用して、エンティティ間の関係を識別します。複数のテーブルを結合できますが、システムがより多くのデータに対してより大きなインデックスをスキャンする必要があるため、時間がかかります。このため、必要なデータを取得するために多数の接続が必要なユースケースでは、リレーショナルデータベースはグラフデータベースと同じパフォーマンスを提供しません。
使いやすさ
グラフデータベースは、関係中心なため、接続されたデータを使用する場合でも簡単に操作することができます。複数の関係を持つパスをトラバースするマルチホップクエリに優れています。また、SPARQL、Gremlin、openCypher などのグラフクエリ言語を使用して、相互接続されたデータを、シンプルなグラフ固有の構文で探索するクエリを表現することもできます。
リレーショナルデータベースは、SQL を使用し、マルチホップクエリを管理する際に違和感を感じることがあります。クエリに複数の結合があり、ネストされたサブクエリにまたがっていると、SQL を書き込むのが難しくなります。注意しないと、読み取りにくく維持しにくい、かさばるクエリになりかねません。
とはいえ、リレーショナルデータベースは成熟しており、さまざまなユースケースで広く利用されています。システムを最適化するために利用できるツールやリソース、コミュニティサポートがいくつもあります。
使用する場面: グラフデータベースとリレーショナルデータベース
グラフデータベースとリレーショナルデータベースには、効果的な使用例が多くあります。データモデルや、いくつか核となる特徴もそれぞれ異なるため、得意とする分野も異ります。
グラフデータベース
グラフデータベースは、データの動的な変更と適応を可能にする柔軟なスキーマを提供します。データ関係に重点を置いているため、分析、セマンティック検索、またはレコメンデーションエンジンに役立ちます。次のようなシナリオでは、グラフデータベースの方が適しています。
- ソーシャルネットワーク、不正検出、ナレッジグラフ、セキュリティグラフ、パーソナライズされたレコメンデーションエンジンなど、複雑な関係を持つデータを扱っている
- データベース構造の他の部分に影響を与えることなく、エッジ、ノード、プロパティを修正するため、進化するスキーマを必要としている
- 相互接続されたデータを利用しており、関係間で複数または不明な数のホップを実行する必要がある (Friend-of-Friend タイプのクエリ)
グラフデータベースは、柔軟性があり、スケーラブルで、動的で、かつデータ間の関係を示すのに優れています。
リレーショナルデータベース
リレーショナルデータベースは、データの完全性をしっかりとサポートする構造化されたスキーマを提供します。次のようなシナリオでは、リレーショナルデータベースの方が適しています。
- 金融取引のように、ACID 準拠と高いレベルのデータの完全性と整合性が必要な場合
- エンタープライズリソース管理のように、表形式のデータモデルにうまく適合する高度に構造化されたデータを扱っている場合
- 扱っているデータに限られた関係しかない場合
相違点のまとめ: リレーショナルデータベースとグラフデータベース
リレーショナルデータベース |
グラフデータベース |
|
モデル |
行と列を含む表形式。 |
データがノードおよびエッジとして表される相互接続ノード |
運用担当 |
作成、読み取り、更新、および削除 (CRUD) などの SQL オペレーション。 |
オペレーションには、CRUD およびグラフトラバーサルオペレーションが含まれます |
パフォーマンス |
リレーショナルデータベースは、関係をトラバースする際に複雑なクエリに直面し、パフォーマンスが低下する可能性があります。 |
グラフデータベースは、コネクテッドデータ間の関係の表現とクエリで優れたパフォーマンスを発揮します。 |
使いやすさ |
リレーショナルデータベースは、大規模なデータセットや構造化データに適しています。マルチホップクエリには適していません。 |
グラフデータベースは、関係中心のデータを扱う際に簡単に使用できます。グラフクエリ言語を使用すると、複数のホップデータを迅速にクエリできます。 |
AWS はリレーショナルデータベースやグラフデータベースの要件にどのように役立ちますか?
Amazon Web Services (AWS) には、リレーショナルデータベースとグラフデータベースの両方のユースケースに対応するソリューションがあります。
リレーショナルデータベース
Amazon Relational Database Service (Amazon RDS) は、クラウド内でリレーショナルデータベースをより簡単にセットアップ、運用、スケールできるようにするマネージドサービスです。これにより、費用対効果が高く、サイズ変更が容易なデータベース容量が提供されるほか、時間のかかるデータベース管理タスクが処理されます。Amazon RDS では次のようないくつかのデータベースエンジンをサポートしています。
- Amazon Relational Database Service (Amazon RDS) for SQL Server
- Amazon Relational Database Service (Amazon RDS) for MySQL
- Amazon Relational Database Service (Amazon RDS) for MariaDB
- Amazon Relational Database Service (Amazon RDS) for Oracle
- Amazon Relational Database Service (Amazon RDS) for PostgreSQL
- Amazon Relational Database Service (Amazon RDS) for Db2
Amazon Aurora は、パフォーマンスと高可用性を大規模に提供する最新のリレーショナルデータベースサービスで、完全にオープンソースの MySQL および PostgreSQL 互換エディションです。Aurora は、ハードウェアプロビジョニング、データベース設定、パッチ適用、バックアップなど、時間のかかる管理タスクを自動化すると同時に、1/10 のコストで商用データベースのセキュリティ、可用性、信頼性を提供するフルマネージドサービスでもあります。
グラフデータベース
Amazon Neptune は、高性能な専用グラフデータベースエンジンです。何十億もの関係を保存し、数ミリ秒のレイテンシーでグラフをクエリするように最適化されています。
Neptune は、プロパティグラフと W3C の Resource Description Framework (RDF) という一般的なグラフモデルをサポートしています。また、Gremlin や SPARQL などのクエリ言語もサポートしているため、高度に結びつけられたデータセットをナビゲートするクエリを構築できます。
Neptune にはいくつもの機能があります。
- リードレプリカ、ポイントインタイムリカバリ、継続的バックアップ、およびアベイラビリティーゾーン間のレプリケーションにより、高い可用性を備えています。
- 保存時の暗号化をサポートし、安全に保護されています。
- フルマネージドです。そのため、ハードウェアのプロビジョニング、ソフトウェアのパッチ適用、セットアップ、設定、またはバックアップなどのデータベース管理タスクについて心配する必要はもはやありません。
今すぐアカウントを作成して、AWS でグラフデータベースとリレーショナルデータベースの使用を開始しましょう。