第1章 图数据库概述

做课程之前，我先问大伙一个问题：为什么我们需要图数据库？ 十年前我刚接触数据存储时，用的是 MySQL + 中间表做好友关系。用户量一上来，那个 SQL 嵌套查询慢得让人抓狂。后来换 Neo4j，一条 Cypher 搞定，性能差距能干到两个数量级。嗯，图数据库不是银弹，但在关联数据密集型场景下，它就是最趁手的工具。

1.1 图数据库发展史

图数据库的底子其实很老。上世纪 60 年代就有类似图结构的数据模型，但直到 2000 年初期，主流还是关系型。我 2012 年第一次用 Neo4j 1.8，社区版连事务都没完全支持。那年的图数据库市场就几个玩家：Neo4j 带头，OrientDB、ArangoDB 多模型跟进。

真正的转折在 2015 年前后：Apache TinkerPop 成为图计算的事实标准，Gremlin 遍历语言统一了多厂商接口；RDF 派系的 SPARQL 也在知识图谱领域站稳脚跟。我记得 2017 年帮一家金融客户做反欺诈系统，对比了 Neo4j 和 JanusGraph，最后选了后者——因为需要集成 HBase 做海量存储。这些经历让我意识到：选图数据库，不能只看名气，得看你的数据模型和查询习惯。

1.2 图数据库应用场景

说实话，图数据库不是用来取代关系型数据库的。它只解决一类问题：数据之间的关联查询。我总结下来，适合图数据库的场景有四个特征：

• 深度关联遍历：比如社交网络里的“朋友的朋友的朋友”
• 可变路径：比如金融风控中找出最短交易路径
• 复杂关联推荐：用图算法算节点相似度
• 知识图谱推理：基于 RDF 三元组的逻辑推理

拿实际案例说话。我曾经帮一个电商平台做商品推荐，如果按传统做法，用 MySQL 做用户-商品二部图，每次推荐都要扫几万行中间表。换了 Neo4j 后，用 Collaborative Filtering 在图上跑 PageRank，推荐响应从 500ms 降到 15ms。你想想看，这差距。

1.3 图数据库核心概念

讲概念之前，我先划个重点：图数据库不是用“表”存图，而是用“顶点”和“边”存图。这个区别决定了你能做什么姿势的查询。

• 节点（Vertex）：实体，比如人、商品、订单
• 边（Edge）：关系，比如关注、购买、包含
• 属性：键值对，贴在节点或边上
• 标签（Label）：给节点分类，比如 :Person :Product
• 图遍历：从某个节点出发，沿着边依次访问相邻节点的过程
• 索引：加速属性查询，类似关系库的 B+Tree

咱们用一个例子串起来。你写 Cypher 创建一个简单网络：

CREATE (alice:Person {name:'Alice', age:30})
CREATE (bob:Person   {name:'Bob',   age:28})
CREATE (alice)-[:KNOWS {since:2019}]->(bob)

这里 Person 是标签，name/age 是节点属性，KNOWS 是边类型，since 是边属性。你看，关系型数据库需要三张表（person、relationship、还需 third table 存属性），图数据库一条边就把所有关联信息锁死了。这就是“关联即查询”的精髓。

本章知识体系

最后说一个我的习惯。每次新项目评估图数据库，我都会先画一张“实体关系图”，然后问自己三个问题：

1. 数据深度（跳数）是不是超过 3？
2. 查询路径是否固定？
3. 需不需要支持复杂图算法（如最短路径、社区检测）？

如果三个答案里有两个是“是”，那就果断上原生图数据库。如果只是简单的一度查询，关系数据库加上索引完全够用，别过度设计。