RDBMSと何が違う？図解で学ぶグラフDBと“つながり”の価値

知識グラフ×LLMで自然言語分析してみたを勉強会で発表してみたところ、参加者の方から『そもそもグラフDBって何がいいの？』とコメントをいただき、改めて整理してみました。
RDBMSしか使ったことない方向けに、グラフDBの基本的な価値や使いどころをまとめています。図解多めで書いたので、ご参考になれば。🙏

## はじめに

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2648069/6be4fdbd-9d38-4f43-8147-31464b33cce8.png)

「知識グラフ・グラフDB面白いよ！」って言われても、「うん、それで？🤔」ってなりますよね。
私も最初はそうでした。でも使ってみると「あ、これは確かに便利かも」と思える場面に出会えました。

この記事では「グラフDBって実際何に使えるの？」という素朴な疑問に、具体例を交えて答えてみたいと思います。

## グラフDBの良いところ

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2648069/142b49b5-fe19-43e8-a709-bd776a42faef.png)

### 1. 「つながり」を扱うのが上手

例えば、こんな場面で力を発揮します：

- 「友達の友達を探したい」（SNSでよくありますよね）
- 「この商品を買った人は、他に何を買ってる？」（ECサイトでおなじみ）
- 「上司の上司は誰？」（組織図を扱うとき）

通常のデータベースだと、これらを実現するのに複雑なJOINが必要になります。
でもグラフDBなら、こんな感じでシンプルに書けます：

```cypher
// 友達の友達を探す
MATCH (me)-[:FRIEND]->(friend)-[:FRIEND]->(friendOfFriend)
RETURN friendOfFriend;

// この商品を買った人が買った他の商品
MATCH (p:Product {id: 'A'})<-[:BOUGHT]-(user)-[:BOUGHT]->(other)
RETURN other;
```

### 2. 複雑な関係性を自然に表現できる

例えば、システムの依存関係を考えてみましょう：

```mermaid
graph LR
    A[認証システム] --> B[ユーザー管理]
    C[決済システム] --> B
    C --> D[在庫管理]
    E[配送システム] --> D
```

「このシステムが止まったら、どのサービスに影響があるんだろう？」
こういう分析が得意です。

### 3. 新しい関係性を柔軟に追加できる

普通のデータベースだと、新しい関係を追加するのに：
1. テーブル設計を変更
2. 外部キーを追加
3. アプリケーションコードも修正
...と大変です。

グラフDBなら：
```cypher
// 新しい関係性を即座に追加
CREATE (a)-[:NEW_RELATIONSHIP]->(b);
```
これだけ！

## 実際のユースケース

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2648069/a4c89bed-99f1-4e2d-af56-aa5ecfafe68b.png)

### 1. 不正検知

例えば、こんなパターンを見つけるのが得意：

```plaintext
User1 --> IP1 --> Transaction1 --> Card1
User2 --> IP1 --> Transaction2 --> Card2
```

「同じIPアドレスから異なるユーザーが異なるカードで取引...？🤔」
というパターンを簡単に検出できます。

### 2. レコメンデーション

「おすすめ」機能の裏側でも使われています：
- 「この映画を見た人は、こんな映画も見ています」
- 「この商品を買った人は、こんな商品も買っています」

### 3. ネットワーク分析

例えば：
- SNSでの影響力のある人を見つける
- システム障害の影響範囲を調べる
- 最適な配送ルートを見つける

### 4. 知識の整理

最近だと：
- 社内ナレッジの関連性を可視化
- 文書間のつながりを管理
- AIの学習データの整理
にも使われています。

## グラフDBが向いているのはこんなとき

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2648069/277ff591-efc1-439d-9f9a-7107d3d36070.png)

こんな特徴があるデータを扱うときは、グラフDBを検討する価値があります：

1. 「つながり」が重要
   - 人間関係
   - システムの依存関係
   - 商品の関連性

2. 複雑な関係を扱う
   - 友達の友達の...
   - システムの影響範囲
   - 商品のレコメンド

3. 関係性が頻繁に変わる
   - 組織の変更
   - システム構成の更新
   - 新しい関連の発見

## 所感：RDBMSと比べて

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2648069/e6db6186-ac83-482c-803f-c9471bcf724d.png)

正直なところ：

- RDBMSでもできること
  - でも、複雑なJOINが必要
  - パフォーマンスが気になる
  - コードが読みにくくなる

- グラフDBの方が楽なこと
  - 関係性の表現が自然
  - クエリが書きやすい
  - パフォーマンスが安定

## まとめ

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2648069/14ad25fe-45b1-410e-a5bc-d32ce7bff1bf.png)

グラフDBは、特に以下のような場合に真価を発揮します：

1. データ間の「つながり」が重要なとき
2. その「つながり」が複雑なとき
3. 「つながり」を分析したいとき

最初は「RDBMSでもできるじゃん」と思うかもしれません。
でも、実際に使ってみると「あ、確かにこっちの方が楽」という場面に出会えるはずです。

興味を持った方は、Neo4jのサイトに無料の学習リソースがあります。クラウド環境でグラフDBを構築して試せるので、実際にグラフ構造をUIで確認しながらクエリを実行してみると、より理解が深まると思います。

## 参考

- [Neo4j - グラフデータベースのユースケーストップ5](https://go.neo4j.com/rs/710-RRC-335/images/Neo4j-Top-Use-Cases-JP.pdf)
- [Neo4j AuraDB: Fully Managed Graph Database](https://neo4j.com/product/auradb/)
- [Netflixの屋台骨　「AIレコメンド」技術最前線](https://www.nikkei.com/article/DGXZQOUC193PM0Z10C21A4000000/)
- [How LinkedIn, Uber, Lyft, Airbnb and Netflix are Solving Data Management and Discovery for Machine Learning Solutions](https://neo4j.com/news/how-linkedin-uber-lyft-airbnb-and-netflix-are-solving-data-management-and-discovery-for-machine-learning-solutions/)

## マインドマップ

![マインドマップ (21).png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2648069/2a2ccb48-cf14-4b8c-b23f-f36988a6db44.png)