图数据库与关系数据库对比

做选型之前，先把两个老对手拉出来遛遛。我最早接触图数据库是在一个社交推荐项目里，当时团队用MySQL做关系模型，联表查询动不动就几十毫秒，改了图数据库之后降到微秒级。嗯，但别急着下结论——关系数据库在事务和报表场景里依然是硬骨头。下面我从数据模型、查询语言、适用场景三个角度，掰开揉碎讲清楚。

数据模型差异

关系数据库用表、行、列。图数据库用顶点（Vertex）、边（Edge）、属性（Property）。

关系模型：数据通过外键连接，查询时靠JOIN把多个表拼起来。你想想看，一个人和他的好友关系，在关系库里要建用户表、好友关系表，然后JOIN两次才能拿到好友列表。数据量一大，JOIN就炸了。

图模型：用户是一个顶点，好友关系是一条边，边可以直接指向另一个顶点。查询时从用户顶点出发，沿着边一步到位。不需要中间表，也不需要JOIN。

我在项目中遇到过这样一个坑：用关系库存好友关系，每次查询都要经过好友关系表做两次JOIN。线上数据到千万级时，一个简单的“好友的好友”查询就超时了。换成图数据库后，同样的查询变成两步遍历，响应时间下降了两个数量级。

对比维度	关系数据库	图数据库
基本单元	表、行、列	顶点、边、属性
关系表达	外键 + JOIN	边（直接指向）
数据冗余	一般需要多个关联表，冗余较少	边自带关系，冗余较少
模式变更	需要ALTER TABLE，可能有锁表	无模式或灵活模式，加属性/边类型不影响已有数据
多跳查询	多层JOIN，性能指数级下降	深度遍历，性能线性增长

查询语言差异

关系数据库用SQL，图数据库主流用SPARQL（RDF图）或Cypher/Gremlin（属性图）。这里我重点讲SPARQL和SQL的对比，因为后续章节会深入SPARQL优化。

先说SQL。它基于关系代数，核心是SELECT-FROM-WHERE。查询朋友的朋友，你得写三四个JOIN，还要处理笛卡尔积膨胀。

SELECT u2.name
FROM users u1
JOIN friendships f1 ON u1.id = f1.user_id
JOIN users u2 ON f1.friend_id = u2.id
JOIN friendships f2 ON u2.id = f2.user_id
JOIN users u3 ON f2.friend_id = u3.id
WHERE u1.name = 'Alice';

再看SPARQL。它基于图模式匹配，用三元组（主语、谓语、宾语）描述顶点和边。同样的查询，写起来像在描述图上的路径：

PREFIX foaf: <http://xmlns.com/foaf/0.1/>
SELECT ?friendName
WHERE {
  ?alice foaf:name "Alice" .
  ?alice foaf:knows ?friend .
  ?friend foaf:knows ?friendOfFriend .
  ?friendOfFriend foaf:name ?friendName .
}

看出来没？SPARQL把查询写成一系列图结构片段，查询引擎沿着边匹配模式，不需要显式JOIN。我个人习惯用SPARQL做深层路径查询，尤其是当关系可以分类型、带属性时，图模式匹配比SQL直观得多。

适用场景对比

我总结了三个关键维度：关系深度、数据一致性要求、查询模式。

• 关系深度：图数据库擅长2跳以上的关联查询（社交关系、推荐系统、反欺诈路径）。关系数据库更适合1跳以内的简单关联（订单-用户、文章-作者）。
• 数据一致性：关系数据库有ACID事务，强一致性强。图数据库（尤其是分布式图库）往往只支持最终一致性或受限的事务。银行转账、库存扣减请用关系库。
• 查询模式：如果查询以“按某个属性筛选+固定JOIN”为主，关系库的B树索引更快。如果查询是“从一个点出发，沿着边探索不定深度的网络”，图库更合适。

举个例子。我做过的知识图谱项目，实体间关系深达5-8层，关系库根本扛不住。但换成图数据库后，深度6跳的查询仍在几十毫秒内。反过来，做一个CMS应用，文章和标签的关系只有1层，关系库加个索引就够了，没必要上图库。

小结：怎么选？

我给出一个简洁的判断流：

1. 你的查询模式是否固定（比如始终查某个字段）？是 → 关系库更高效。
2. 你的数据关系深度是否超过2层？是 → 图库能省掉大量JOIN。
3. 是否需要强事务？是 → 关系库为主，图库可以辅助读。
4. 是否需要遍历可变路径、发现社区、计算中心度？是 → 图库几乎是唯一选项。

好了，这一章帮你把图数据库和关系数据库的差异理清了。接下来我们会深入图数据库的存储引擎选型——那才是真正决定性能的硬仗。