图数据库

「用户 A 关注了谁、谁与谁有三度人脉、推荐路径最短几步」——用 SQL 递归 JOIN 能做，但 深度遍历与路径查询 在图库里更自然。Neo4j、DGraph 等 以边为一等公民，适合 关系本身就是核心业务 的场景。

学习目标

• 理解属性图模型：节点、边、属性
• 知道 Neo4j Cypher 与 DGraph GraphQL± 的基本定位
• 判断何时用图库、何时仍用 postgresql-essentials 的递归 CTE

核心概念

属性图 vs 关系表

	图数据库	PostgreSQL
关系表达	边（Relationship）显式存储	外键 + JOIN
遍历	索引无关的局部扩展	递归 CTE，深度大时代价高
查询语言	Cypher、Gremlin、GraphQL±	SQL
典型场景	社交、欺诈环、知识图谱	浅层关联、强事务报表

// Neo4j：三度好友
MATCH (me:User {id: $uid})-[:FOLLOWS*1..3]-(friend:User)
WHERE friend.id <> $uid
RETURN DISTINCT friend

同等 SQL 需多层自连接或递归，可读性与性能随深度恶化。

Neo4j 与 DGraph

	Neo4j	DGraph
部署	单机/集群，生态成熟	分布式原生，GraphQL 友好
查询	Cypher 为主	GraphQL± / DQL
适用	企业知识图谱、推荐	云原生微服务图数据

两者都不是 通用 OLTP 替代品：点边规模上亿时需分区策略，与 scaling-essentials 的分片思路衔接。

何时不选图库

• 主要是 CRUD + 简单外键： orm-essentials 的关系模型足够
• 需要复杂聚合报表：导出到 postgresql-essentials 或 OLAP（见 sdb-analytics）
• 全文搜索为主：用 elasticsearch-essentials

练习

• 画一张「用户-帖子-标签」小图，标出节点类型与边类型
• 用一句话说明：为何 cf_track 与 cf_lesson 仍适合关系库而非图库
• 查 Neo4j 官方文档中 Cypher MATCH 语法一页

小结

下一课宽列存储：写入扩展的另一条路。