グラフデータベースとリレーショナルデータベースの違い
グラフデータベースとリレーショナルデータベースはどちらも、事前定義された関係を持つデータ項目を格納します。ただし、データの関係性を表す方法は大きく異なります。リレーショナルデータベースは、行と列を含む表形式でデータを保存します。関連データもテーブルに格納され、データポイントが元のテーブルにリンクされます。データの関係性に関連する操作は複数のデータテーブルルックアップを必要とするため、非効率的になります。これとは対照的に、グラフデータベースはデータをエンティティと関係性のネットワークとして保存します。数学グラフ理論を使用し、データの関係性を保存して操作を実行します。グラフデータベースは、関係性のモデリングにおいてはるかに効率的です。複雑なデータ相互接続を伴うユースケースのアプリケーションパフォーマンスが大幅に向上します。
データモデル: グラフデータベースとリレーショナルデータベース
グラフデータベースとリレーショナルデータベースはいずれも情報を格納し、データ間の関係を表します。しかし、リレーショナルモデルがデータエンティティを優先するのに対し、グラフモデルはエンティティ間の関係を優先します。
リレーショナルデータベースモデル
リレーショナルデータベースは、情報を行と列に整理するデータテーブルを使用します。列はデータエンティティの特定の属性を保持し、行は個々のデータレコードを表します。
リレーショナルデータベースの固定スキーマでは、プライマリキーと外部キーでテーブル間の関係を前もって示しておく必要があります。
例
お客様のプロフィールで互いに友達になれるソーシャルメディアアプリケーションを考えてみましょう。データをモデル化するには 2 つのテーブルが必要です。
お客様テーブルは次のようになります。
| ID |
名前 |
位置 |
| C1 |
Alejandro |
米国 |
| C2 |
Ana |
米国 |
| C3 |
Kwaku |
米国 |
| C4 |
Pat |
米国 |
友達テーブルは次のようになります。
| お客様 ID |
友達 ID |
| C1 |
C2 |
| C1 |
C3 |
| C2 |
C4 |
| C2 |
C1 |
| C3 |
C1 |
| C3 |
C4 |
お分かりのように、複雑な関係を表すときには冗長や重複があります。ストレージ要件が増加し、規模が大きくなるとパフォーマンスが低下する可能性があります。
グラフデータベースモデル
一方、グラフデータベースは、プロパティ、エッジ、およびノードを含むグラフ構造を使用してデータを表します。ノードはオブジェクトであり、エッジはそれらのノード間の関係を示し、プロパティはノードとエッジの属性を記述します。この動的な構造により、グラフデータベースは連結データの表現に有用です。関係とデータ型に関する柔軟性が向上します。
例
前のセクションで説明したソーシャルメディアアプリケーションのデータは、次のように表示されます。
{customer_id:「C1」
名前:「Alejandro」
場所:「米国」
友達:「C2、C3」}
関係をモデル化する際の、データレコードの冗長や重複はもはやありません。
主な相違点: グラフデータベースとリレーショナルデータベース
リレーショナルデータベースとグラフデータベースは、データモデルが異なるだけでなく、機能とユーティリティの点で多くの相違点があります。
運用担当
グラフトラバーサルアルゴリズムを使用してグラフデータモデルをクエリします。これらのアルゴリズムは深度優先か幅優先のどちらかであり、これは接続されたデータを迅速に検索して取得するのに役立ちます。グラフデータベースは、データ間の関係を理解できるため、複雑な相互接続やクエリに役立ちます。
対照的に、リレーショナルデータベースは、SQL を使用してデータを取得、操作します。ユーザーは、SQL を使用することで、SELECT、INSERT、UPDATE、DELETE など、さまざまなタイプのクエリをテーブルに対して実行することができます。リレーショナルデータベースは、テーブル間の関係が明確に定義されている構造化データの処理において優れています。複数のテーブルで複雑なフィルタリング、集計、および結合を行う場合に特に効果的です。
スケーラビリティ
リレーショナルデータベースをスケールする場合、通常は垂直方向にスケールします。垂直スケーリングとは、CPU、ストレージ、またはメモリなどのハードウェアをアップグレードして、サーバーが処理できるワークロードを増やすことです。垂直スケーリングには限界があり、コスト要件に加えて課題が生じる可能性があります。
リレーショナルデータベースでは、シャーディングを使用して水平方向にスケールすることもできます。この場合、データは多数のサーバーに分散されます。ただし、シャーディングはデータストレージを複雑にするため、一貫性の問題につながる可能性があります。
対照的に、グラフデータベースは水平スケーリングに優れており、その際にはパーティショニングを使用します。パーティションはすべて異なるサーバー上にあるため、多くのサーバーでグラフクエリを並行処理することができます。多数のノードに分散することで、データベースエンジンは大規模であってもデータを効果的にクエリできます。
パフォーマンス
グラフデータベースは、インデックスフリーの隣接関係を提供するため、パフォーマンスが向上します。インデックスフリーの隣接関係により、システムは関連するエンティティ間をトラバースできます。グラフデータベースは、ノード間の参照またはポインタとして関係性を保存するので、データベースはメモリポインタをトラバースしてエンティティ間をすばやくナビゲートできます。この場合、データベースにはインデックスやマッピングテーブルは必要ありません。
このインデックスフリーの隣接システムにより、グラフデータベースは一定時間の関係性トラバーサルを実現できます。一定時間とは、データサイズに関係なく、同じ時間でグラフデータベース内の関係性を一貫してトラバースできることを意味します。ノード間の直接接続によりすぐにアクセスできるため、関係性を迅速にクエリしてトレースできます。これらの機能により、グラフデータベースは非常に効率的です。
代わりにリレーショナルデータベースは、インデックスルックアップを使用するため、テーブルをスキャンしてエンティティ間の関係性を識別する必要があります。複数のテーブルを結合できますが、システムがより多くのデータに対してより大きなインデックスをスキャンする必要があるため、時間がかかります。このため、リレーショナルデータベースは、グラフデータベースと同じパフォーマンスを提供することはできません。
使いやすさ
グラフデータベースは、関係中心なため、接続されたデータを使用する場合でも簡単に操作することができます。複数の関係を持つパスをトラバースするマルチホップクエリに優れています。Gremlin や Cypher などのグラフクエリ言語を使用して、関係を視覚的に示すこともできます。これらの言語を使用して相互接続されたデータを調べることができるため、ネストされたデータや結合されたデータを調べるための構文が簡略化されます。
リレーショナルデータベースは、SQL を使用し、マルチホップクエリを管理する際に違和感を感じることがあります。クエリに複数の結合があり、ネストされたサブクエリにまたがっていると、SQL を書き込むのが難しくなります。注意しないと、読み取りにくく維持しにくい、かさばるクエリになりかねません。
とはいえ、リレーショナルデータベースは成熟しており、さまざまなユースケースで広く利用されています。システムを最適化するために利用できるツールやリソース、コミュニティサポートがいくつもあります。同様に、リレーショナルデータベースは信頼性が高く ACID 準拠の方法で構造化データを管理する場合にも優れています。ACID の特性は、不可分性、整合性、分離性、耐久性であり、データの有効性を確保するのに役立ちます。
使用する場面: グラフデータベースとリレーショナルデータベース
グラフデータベースとリレーショナルデータベースには、効果的な使用例が多くあります。データモデルや、いくつか核となる特徴もそれぞれ異なるため、得意とする分野も異ります。
グラフデータベース
グラフデータベースは、データの動的な変更と適応を可能にする柔軟なスキーマを提供します。データ関係に重点を置いているため、分析、セマンティック検索、またはレコメンデーションエンジンに役立ちます。次のようなシナリオでは、グラフデータベースの方が適しています。
- ソーシャルネットワーク、不正検知、ナレッジグラフ、および検索エンジンなど、複雑な関係を持つデータを処理している
- データベース構造の他の部分に影響を与えることなく、エッジ、ノード、プロパティを修正するため、進化するスキーマを必要としている
- 相互接続されたデータを使用しており、関係間で 3 回以上のホップを実行する必要がある (Friend-of-Friend タイプのクエリ)
グラフデータベースは、柔軟性があり、スケーラブルで、動的で、かつデータ間の関係を示すのに優れています。
リレーショナルデータベース
リレーショナルデータベースは、データの完全性をしっかりとサポートする構造化されたスキーマを提供します。次のようなシナリオでは、リレーショナルデータベースの方が適しています。
- 金融取引のように、ACID 準拠と高いレベルのデータの完全性と整合性が必要な場合
- エンタープライズリソース管理のように、表形式のデータモデルにうまく適合する高度に構造化されたデータを扱っている場合
- 扱っているデータに限られた関係しかない場合
相違点のまとめ: リレーショナルデータベースとグラフデータベース
| リレーショナルデータベース |
グラフデータベース |
|
| モデル |
行と列を含む表形式。 |
データが JSON ドキュメントとして表される相互接続ノード。 |
| 運用担当 |
作成、読み取り、更新、および削除 (CRUD) などの SQL 操作。 |
操作には、数学的グラフ理論に基づく CRUD およびグラフトラバーサル操作が含まれます。 |
| スケーラビリティ |
従来のリレーショナルデータベースは垂直方向にスケールができますが、水平方向のスケーリングには適していません。 |
グラフデータベースは水平方向のスケーリングに優れています。パーティショニングを使用して、データを多数のノードに分散できます。 |
| パフォーマンス |
リレーショナルデータベースは、関係をトラバースする際に複雑なクエリに直面し、パフォーマンスが低下する可能性があります。 |
グラフデータベースは、データ間の関係の表現とクエリに優れています。 |
| 使いやすさ |
リレーショナルデータベースは、大規模なデータセットや構造化データに適しています。マルチホップクエリには適していません。 |
グラフデータベースは、関係中心のデータを扱う際に簡単に使用できます。グラフクエリ言語を使用すると、複数のホップデータを迅速にクエリできます。 |
AWS はリレーショナルデータベースやグラフデータベースの要件にどのように役立ちますか?
Amazon Web Services (AWS) には、リレーショナルデータベースとグラフデータベースの両方のユースケースに対応するソリューションがあります。
Amazon Relational Database Service (Amazon RDS) はマネージドサービスを集めたものであり、クラウド内でリレーショナルデータベースを簡単にセットアップ、運用、およびスケールできるようにします。Amazon RDS では次のようないくつかのデータベースエンジンをサポートしています。
- SQL Server の複数のエディション (2014、2016、2017、および 2019) をデプロイするための Amazon Relational Database Service (Amazon RDS) for SQL Server
- MySQL Community Edition のバージョン 5.7 および 8.0 をサポートする、Amazon Relational Database Service (Amazon RDS) for MySQL
- MariaDB Server バージョン 10.3、10.4、10.5、10.6 をサポートする、Amazon Relational Database Service (Amazon RDS) for MariaDB
同様に、Amazon Neptune は、目的別の高パフォーマンスグラフデータベースエンジンです。何十億もの関係を保存し、数ミリ秒のレイテンシーでグラフをクエリするように最適化されています。
Neptune は、プロパティグラフと W3C の Resource Description Framework (RDF) という一般的なグラフモデルをサポートしています。また、Gremlin や SPARQL などのクエリ言語もサポートしているため、高度に結びつけられたデータセットをナビゲートするクエリを構築できます。
Neptune にはいくつもの機能があります。
- リードレプリカ、ポイントインタイムリカバリ、継続的バックアップ、およびアベイラビリティーゾーン間のレプリケーションにより、高い可用性を備えています。
- 保存時の暗号化をサポートし、安全に保護されています。
- フルマネージドです。そのため、ハードウェアのプロビジョニング、ソフトウェアのパッチ適用、セットアップ、設定、またはバックアップなどのデータベース管理タスクについて心配する必要はもはやありません。
今すぐアカウントを作成して、AWS でグラフデータベースとリレーショナルデータベースの使用を開始しましょう。
