グラフデータベース
グラフデータベースとは
グラフデータベースは、データをノード(点)とエッジ(線)で表現し、つながりをたどる検索を得意とするデータベースです。SNS の友達関係、商品のレコメンド、組織図、路線の乗り換え探索など、「関係そのもの」が主役になるデータに向いています。
- ノード — 人・商品・場所といった実体。プロパティ(名前、年齢など)を持てる
- エッジ — ノード同士の関係。「フォローしている」「購入した」など向きと種類を持つ
RDBとの違い
[[リレーショナルデータベース]] でも関係は表せますが、たどるたびに [[テーブル結合(JOIN)]] が必要です。
| リレーショナルDB | グラフDB | |
|---|---|---|
| 関係の表現 | 中間テーブル+外部キー | エッジそのもの |
| 多段のたどり方 | JOIN を段数だけ重ねる | エッジを順にたどる |
| 段数が増えたとき | 急激に重くなりやすい | 比較的安定 |
| 得意な問い | 「条件に合う行の集計」 | 「AからBへの最短の経路」 |
「友達の友達の友達」を探す場合、RDB では JOIN が3重になりますが、グラフDBは隣接するエッジをたどるだけなので深さが増えても現実的な速度を保てます。
問い合わせの書き方
グラフDB には [[SQL]] とは別の専用クエリ言語があります。代表例が Cypher で、関係を図のような記法で書くのが特徴です。
MATCH (me:User {name: 'Taro'})-[:FOLLOWS]->(f)-[:FOLLOWS]->(fof)
RETURN fof.name
「Taro がフォローしている人が、さらにフォローしている人」を1文で表現できます。
向き・不向き
- 向いている — 推薦、不正検知(不自然なつながりの発見)、権限の継承関係、ネットワーク構成の探索
- 向いていない — 大量データの集計・レポート、単純な一覧表示。この用途は RDB や分析用のデータベースの方が高速
グラフDBは [[NoSQL]] の一種として分類され、用途を絞って RDB と併用するのが実務では一般的です。
初学者向けポイント
- まず [[ER図とデータモデリング]] で「実体と関連」を考える発想は共通 — グラフDBはその関連を一級の存在として扱うもの
- 検索の起点となるノードは高速に見つける必要があり、プロパティに [[データベースインデックス]] を貼る点は RDB と同じ
- 「関係を何段もたどるか?」が採用判断の分かれ目。1〜2段で済むなら RDB で十分なことが多い
関連技術とのつながり
- [[NoSQL]] — グラフDBは非リレーショナル型データベースの一分類
- [[リレーショナルデータベース]] — JOIN による関係表現との比較が理解の近道
- [[SQL]] — グラフDBでは Cypher など専用言語を使う点が対照的
- [[ER図とデータモデリング]] — 実体と関連を考える設計の基礎は共通
- [[データベースインデックス]] — 探索の起点ノードを速く見つけるために使う
- [[力学モデルによるグラフレイアウト]] — 同じノードとエッジを、保存・探索の側ではなく画面へ配置する側から扱う手法
Q: グラフデータベースがデータを表現する2つの要素はどれ?
- [x] ノード(点)とエッジ(線)
- [ ] 行と列
- [ ] キーとバリューのみ
解説: 実体をノード、関係をエッジとして表現し、つながりをたどる検索を得意とします。
Q: 「友達の友達の友達」のように多段の関係をたどる検索で、グラフDBが有利な理由はどれ?
- [ ] データを圧縮して保存しているから
- [x] JOIN を重ねずに隣接するエッジを順にたどれるから
- [ ] 検索結果をすべてキャッシュしているから
解説: RDB では段数だけ JOIN が増えて重くなりますが、グラフDBはエッジをたどるだけなので深さが増えても安定します。
Q: グラフデータベースが向いていない用途として本文で挙げられているのはどれ?
- [ ] 不正検知のための不自然なつながりの発見
- [ ] 商品のレコメンド
- [x] 大量データの集計・レポート
解説: 集計や単純な一覧は RDB や分析用データベースの方が高速で、グラフDBは関係をたどる用途に絞って使います。