RDB との違いと使い分け

グラフDB は RDB を「すべて置き換える」ものではありません。それぞれに得意・不得意があり、適材適所で使い分けるのが実務の基本です。この章では RDB 経験者の視点で両者を比較し、選択の判断基準を整理します。

データモデルの違い

同じ「社員と部署」のデータを両者でモデル化すると、設計思想の違いが見えます。

RDB のモデル

-- テーブル設計
employees (id, name, department_id)
departments (id, name)
-- 関係は外部キー department_id で表現

グラフDB のモデル

(:Employee {name:"田中"}) -[:BELONGS_TO]-> (:Department {name:"開発部"})
(:Employee {name:"鈴木"}) -[:BELONGS_TO]-> (:Department {name:"開発部"})
(:Employee {name:"田中"}) -[:REPORTS_TO]-> (:Employee {name:"佐藤"})
観点RDBグラフDB
データ構造テーブル（行と列）ノードとエッジ
関係の表現外部キー（間接参照）エッジ（直接参照）
関係の情報中間テーブルに格納エッジのプロパティに格納
スキーマ事前に厳密に定義柔軟（スキーマレス or スキーマオプション）
正規化設計の中心概念不要（関係を直接表現）

クエリの違い

「田中さんの上司の上司を探す」という3段階の関係を辿るクエリを比較します。

RDB（SQL）

-- 再帰CTE で上司チェーンをたどる
WITH RECURSIVE chain AS (
  SELECT manager_id, 1 AS depth
  FROM employees WHERE name = '田中'
  UNION ALL
  SELECT e.manager_id, c.depth + 1
  FROM employees e JOIN chain c ON e.id = c.manager_id
  WHERE c.depth < 2
)
SELECT e.name FROM employees e
JOIN chain c ON e.id = c.manager_id
WHERE c.depth = 2;

グラフDB（Cypher）

MATCH (:Employee {name:"田中"})-[:REPORTS_TO*2]->(boss)
RETURN boss.name

可変長パスが Cypher の強みです。[:REPORTS_TO*2] は「ちょうど2ホップ」、[:REPORTS_TO*1..5] は「1〜5ホップ」を意味します。RDB の再帰CTE に比べて記述が圧倒的に簡潔です。

スキーマの柔軟性

RDB とグラフDB ではスキーマに対する考え方が大きく異なります。

観点RDBグラフDB
スキーマ変更ALTER TABLE が必要。大規模テーブルでは時間がかかる新しいプロパティやラベルを随時追加可能
多様な関係の追加新しい中間テーブルが必要になることが多い新しいエッジタイプを追加するだけ
型の一貫性列の型が統一されている（強い型付け）同ラベルのノードが異なるプロパティを持てる
データ整合性制約（FK, UNIQUE, CHECK）で厳密に保証製品によっては制約機能が限定的

スキーマレスの注意点: 柔軟性はメリットですが、制約が弱い分、アプリケーション側でデータ整合性を担保する必要があります。RDB で当たり前だった「NOT NULL 制約」「UNIQUE 制約」が暗黙に効かないことを意識しましょう。

性能特性の違い

両者は異なるワークロードで異なる性能特性を示します。

ワークロードRDBグラフDB
単純な CRUD非常に高速同等〜やや遅い
集計・レポート得意（GROUP BY, SUM, AVG）不得意
1〜2段階の JOIN高速同等
4段階以上の関係探索急激に遅くなる安定して高速
最短経路・推薦実装困難組み込みアルゴリズムで対応
全データスキャン得意不得意な場合が多い

なぜ深い JOIN が遅くなるのか: RDB では JOIN のたびにインデックス検索とハッシュ結合が発生します。JOIN が N 段になると中間結果が爆発的に増えます。一方、グラフDB はノードからエッジへのポインタを直接たどるため、全データ量に影響されません。

得意・不得意の比較

観点RDB が得意グラフDB が得意
トランザクション厳密な ACID が標準製品によるが RDB ほど成熟していない
集計・分析SQL の集約関数が強力集計向けではない
構造化データ固定スキーマで効率的オーバースペック
関係の探索浅い関係なら問題なし深い・複雑な関係に圧倒的に強い
パターン検出困難得意（サイクル検出、コミュニティ検出）
スキーマ進化マイグレーションが必要柔軟に対応
ツール・エコシステム非常に充実成長中だが RDB ほどではない

RDB で十分なケース

以下の要件が中心であれば、グラフDB は不要です。無理に導入する必要はありません。

グラフDB が有効なケース

以下のような要件が含まれる場合、グラフDB の導入を検討する価値があります。

共存パターン

実務では RDB とグラフDB を併用するポリグロット・パーシステンスが現実的な選択肢です。

データ格納先理由
顧客マスタ、受注データRDBトランザクション、集計が中心
顧客間の関係、レコメンドグラフDB多段階の関係探索が頻繁
商品カタログRDBCRUD と検索が中心
商品の関連・類似ネットワークグラフDB「一緒に買われる」「代替品」等の関係

導入の目安: まず RDB で構築し、関係探索がボトルネックになった部分だけをグラフDB に切り出すアプローチが堅実です。最初からすべてをグラフDB にする必要はありません。

まとめ

次章「代表的なユースケース」では、グラフDB が実際に使われている具体的な場面を紹介します。