グラフDBとは何か

グラフDB は、データを「点（ノード）」と「線（エッジ）」で表現し、データ同士の関係を第一級の概念として扱うデータベースです。RDB がテーブルの行と列でデータを整理するのに対し、グラフDB は「つながり」そのものを記録・探索します。

グラフDBの概要

グラフデータベース（Graph Database）は、データ間の関係性を効率的に保存・検索するために設計された NoSQL データベースの一種です。 RDB では外部キーと JOIN を使って関係を表現しますが、グラフDB ではエッジ（辺）として関係を直接保持します。

名前に含まれる「グラフ」は、棒グラフや折れ線グラフのことではなく、数学のグラフ理論に由来します。 ノード（頂点）とエッジ（辺）からなるデータ構造のことです。

RDB 経験者へのポイント: RDB の「テーブル」「行」「外部キー」にあたるものが、グラフDB では「ノード」「プロパティ」「エッジ」です。外部キーによる間接的な参照ではなく、エッジとして関係を直接表現するのが最大の違いです。

グラフ理論の基本

グラフ理論は18世紀にオイラーが「ケーニヒスベルクの橋」問題を解いたことに始まります。 「すべての橋を一度ずつ渡って元に戻れるか？」という問題を、地点をノード、橋をエッジとしてモデル化しました。

グラフDB で使われるグラフの種類には主に以下があります。

種類説明例
無向グラフエッジに方向がない友人関係（A と B は友人）
有向グラフエッジに方向があるフォロー関係（A が B をフォロー）
重み付きグラフエッジに数値（重み）がある距離、コスト、信頼度
プロパティグラフノードとエッジに属性を持つほとんどのグラフDB が採用

ノード・エッジ・プロパティ

グラフDB の3つの基本要素を整理します。

ノード（Node / Vertex）

エンティティ（実体）を表します。RDB でいえば「テーブルの1行」に近い存在です。 人、商品、場所など、あらゆるものをノードとして表現できます。

エッジ（Edge / Relationship）

ノード間の関係を表します。RDB の外部キーに相当しますが、エッジは方向・型・プロパティを持てる点が大きく異なります。

プロパティ（Property）

ノードやエッジに付与されるキーと値のペアです。RDB の列（カラム）に相当します。

ラベル付きプロパティグラフ

現在の主要なグラフDB のほとんどが採用しているモデルがラベル付きプロパティグラフ（Labeled Property Graph）です。 これは、ノードにラベル、ノードとエッジにプロパティを持たせることで、柔軟で直感的なデータモデリングを可能にします。

具体例で見てみましょう。「Alice が Bob をフォローしている」という関係は次のように表現されます。

(Alice:Person {name:"Alice", age:30}) -[:FOLLOWS {since:"2023-04"}]-> (Bob:Person {name:"Bob", age:28})

この1行で、2つのノード（Alice, Bob）、1つのエッジ（FOLLOWS）、そしてそれぞれのプロパティがすべて表現されています。

RDF（Resource Description Framework）という別のグラフモデルもあります。RDF はトリプル（主語・述語・目的語）で知識を記述するモデルで、W3C が標準化しています。プロパティグラフより厳密ですが、やや記述が冗長になります。本ガイドではプロパティグラフを中心に説明します。

RDB のテーブルとの対比

RDB で「ユーザーのフォロー関係」を表現する場合と、グラフDB で表現する場合を比較します。

RDB の場合

3つのテーブルと JOIN で関係を表現します。

-- users テーブル
| id | name  | age |
|----|-------|-----|
| 1  | Alice | 30  |
| 2  | Bob   | 28  |

-- follows テーブル（中間テーブル）
| follower_id | followee_id | since   |
|-------------|-------------|---------|
| 1           | 2           | 2023-04 |

-- 「Alice がフォローしている人」を取得
SELECT u2.name
FROM users u1
JOIN follows f ON u1.id = f.follower_id
JOIN users u2 ON f.followee_id = u2.id
WHERE u1.name = 'Alice';

グラフDB の場合（Cypher）

関係をそのまま記述できます。

// 「Alice がフォローしている人」を取得
MATCH (a:Person {name:"Alice"})-[:FOLLOWS]->(b:Person)
RETURN b.name

RDB では3テーブルの JOIN が必要な処理が、グラフDB では直感的な1つのパターンマッチで済みます。 関係が深くなるほど（フォローのフォローのフォロー...）、この差は大きくなります。

トラバーサルという考え方

グラフDB の最大の特長はトラバーサル（走査）です。 あるノードから出発して、エッジをたどって関連するノードを次々に探索する操作です。

RDB では関係を探索するたびに JOIN が必要ですが、グラフDB ではエッジがノード間のポインタとして機能するため、深い探索でも性能が劣化しにくいのが特長です。

操作RDBグラフDB
1段階の関係JOIN 1回1ホップ
2段階の関係JOIN 2回2ホップ
N段階の関係JOIN N回（N が不定だと再帰CTEが必要）可変長パスで記述可能
最短経路非常に困難組み込み関数で対応

性能特性の違い: RDB の JOIN はデータ量全体に影響されますが、グラフDB のトラバーサルは「探索する範囲」のみに依存します。そのため、データ全体が巨大でも、関係の探索範囲が限定的であれば高速です。これを index-free adjacency（隣接インデックス不要）と呼びます。

グラフDBの歴史

グラフDB の発展を簡単に振り返ります。

年代出来事
1960年代ネットワーク型DB（CODASYL）が登場。グラフ的な構造だが汎用性に欠けた
2000年Neo4j の開発開始。プロパティグラフモデルの普及に大きく貢献
2007年Neo4j が一般公開。専用クエリ言語 Cypher が後に登場
2010年代SNS・レコメンドの普及によりグラフDB への注目が高まる
2017年Amazon Neptune 発表。クラウドマネージドのグラフDB が一般化
2019年GQL（Graph Query Language）が ISO 標準化プロジェクトとして始動
2024年ISO/IEC 39075（GQL）が国際標準として発行

まとめ

次章「RDB との違いと使い分け」では、両者の得意・不得意をより詳しく比較します。