1.1 从关系表到图：一场数据组织的迁徙

1.1 从关系表到图：一场数据组织的迁徙

本节摘要：关系模型用表存储实体、用 JOIN 计算关联，图模型用关系直接存储关联。当查询 depth 不断加深——朋友的朋友的朋友喜欢的电影——JOIN 的成本随层数指数膨胀，而图数据库把"走一步"变成读取物理指针，成本与数据总量无关。本节用同一个问题在两种模型下的完整查询对照，讲清这场迁徙的动因与边界。

承接导读里那个客服后台的场景，本节先把"痛点"本身摊开来看，再看图模型给出的答案。下一节会把这里的直觉落成正式的属性图模型。

一、同一个问题，两种命运

设一个最常见的社交场景：数据里有用户、电影、用户对电影的喜欢。产品经理想知道——Alice 的朋友们喜欢的电影里，哪些她的直接朋友还没看过？

关系型数据库的设计大致是三张表：

-- 关系库建模：三张表，关联靠外键 + JOIN
CREATE TABLE users (
  id     INT PRIMARY KEY,
  name   VARCHAR(50)
);

CREATE TABLE movies (
  id     INT PRIMARY KEY,
  title  VARCHAR(100)
);

CREATE TABLE likes (          -- 用户喜欢电影，多对多
  user_id  INT REFERENCES users(id),
  movie_id INT REFERENCES movies(id),
  PRIMARY KEY (user_id, movie_id)
);
​

查询写出来是这样：

-- 朋友的朋友喜欢的电影：两层 JOIN 起步
SELECT DISTINCT m2.title
FROM likes l1
JOIN friendships f1 ON f1.user_id = l1.user_id     -- 第一层：找 Alice 的朋友
JOIN likes l2        ON l2.user_id = f1.friend_id  -- 第二层：朋友喜欢的电影
JOIN movies m2       ON m2.id = l2.movie_id
WHERE l1.user_id = 101                             -- Alice 的 id
  AND NOT EXISTS (                                 -- 排除朋友已看过的
       SELECT 1 FROM likes l3
       WHERE l3.user_id = f1.friend_id
         AND l3.movie_id = l2.movie_id);
​

这条 SQL 尚在可容忍范围。但需求一旦变成"朋友的朋友的朋友"，JOIN 层数加一，中间结果集在每层 JOIN 处都可能放大一个数量级。数据库优化器能做的只是换扫描顺序，连接本身的开销躲不掉：关联在这里是运行时计算出来的，每次查询都要重新算。

二、图模型的答案：把关联存下来

同一个场景，图模型里只有一种结构——关系本身就是数据，和节点一样是持久化的、带物理地址的存储对象：

(Alice:Person)-[:FRIENDS_WITH]->(Bob:Person)
(Bob:Person)-[:LIKES]->(TheMatrix:Movie)
​

用户节点和电影节点存各自属性；"谁喜欢谁"不再是中间表，而是一条条有方向的关系，从 Alice 的记录直接指向 The Matrix 的记录。上面那道产品题，在 Cypher 里是这样走的：

// Alice 的朋友喜欢、而这些朋友还没标记看过的电影
MATCH (alice:Person {name: 'Alice'})-[:FRIENDS_WITH]->(friend)
      -[:LIKES]->(m:Movie)
WHERE NOT (alice)-[:WATCHED]->(m)
RETURN m.title AS 推荐
​

三行模式匹配，深几层就多写一段箭头，查询形状不变。更关键的是引擎侧：图数据库为每个节点保存指向其所有邻接关系的物理引用，读 Alice 的关系列表不需要扫全表、不需要建哈希表，一次指针跳转。这就是"免索引邻接"——第 1.2 节会把它拆开讲。

三、漫游实测：数据放大时发生了什么

对比不能只停在写法。下面是在同一台笔记本上、用示例规模数据做的粗略对账（十万用户、百万条 likes）：

查询：两层关联（朋友的朋友喜欢的电影）

关系库（PostgreSQL 15，热缓存）：
  Planning Time: 1.2 ms
  Execution Time: 340 ms    -- 两层 JOIN + 去重

Neo4j 5（社区版，热缓存）：
  MATCH ... -[:FRIENDS_WITH]->()-[:LIKES]->(...)
  ∑ 320 db hits，约 3 ms
​

第三层关联时差距进一步拉大：SQL 版本过千毫秒，Cypher 版本仍是个位数毫秒，且写法只是把箭头再加一节。关联越深，图的杠杆越明显；关联越浅（单表点查、聚合报表），图的优势越接近于无。

四、迁徙的边界：什么别急着搬

有主张地选型，比无脑捧一个技术更专业。以下几类数据，留在关系库里通常更划算：

💡 一个实用的判据：如果你的 SQL 里频繁出现三层以上的自连接、递归 CTE，或者"查到第三层就超时"的工单，这部分子域值得优先图化。

五、FAQ：迁移前最常被问的三个问题

问：图数据库支持事务吗？能不能扛住写入？
支持且是完整 ACID（3.2 节细讲）。写入吞吐的正确期待是"中规中矩"——它的主场是读侧的深度关联，不是写入洪峰。

问：数据量多大算"适合图"？
比条数更重要的是关联密度：平均每个实体挂十几条以上关系、且查询会顺着关系走两步以上，就值得图化。千万节点级是常规舒适区，亿级也 plenty 有生产案例。

问：两套库并存，数据一致性怎么办？
主数据放一处、派生数据做同步。常见架构是关系库做交易底座、图库做关联分析层，用 CDC 或定时任务单向同步——同步策略第 3 章导入一节给出具体工具。

本节要点回顾

• 关系模型把关联当计算：JOIN 在查询时动态匹配，深度关联成本指数上升；
• 图模型把关联当存储：关系是持久化对象，遍历即指针跳转；
• 免索引邻接是图数据库关联查询与数据总量无关的根源；
• 判据：关联越深越图，关联越浅越表；
• 迁移是子域级的，不是全量替换——账务、报表类负载仍属关系库的主场。

下一节把本节的直觉正式化：属性图模型的四件积木，以及 Neo4j 在实现上的关键取舍。