Neo4j 图数据库入门

1. 一句话简介

Neo4j 是目前最流行的原生图数据库（Graph Database），它以「节点（Node）、关系（Relationship）、属性（Property）」为基本存储模型，将数据按图论的方式组织和关联。与关系型数据库用外键 + JOIN 表达关联不同，Neo4j 把「关系」本身作为一等公民进行存储和索引，遍历关系只需沿边移动，不依赖昂贵的多表连接。

本模块 demo-neo4j 展示了 Spring Boot 通过 spring-boot-starter-data-neo4j 集成 Neo4j 的全过程：它建模了一个「校园人物关系网」，用 @NodeEntity 标注 Student、Teacher、Class、Lesson 四种节点，用 @Relationship 声明学生-班级、学生-课程、班级-班主任、课程-教师四种关系，并通过 Neo4jRepository 和原生 Cypher 查询实现出「谁和谁是同学」「某老师教了哪些学生」这类连通性查询。这类在多跳路径上求关联的问题，正是图数据库的核心发力点。

2. 什么时候使用

• ✅ 数据间关系为主要价值：业务的核心资产是实体之间的关联（如社交网络的好友链、账号的资金流向、知识图谱的实体引用），而不是孤立的单条记录。本模块中「漩涡鸣人 → 螺旋丸 → 自来也」这类多跳路径，用图数据库表达几乎是唯一自然的方式。
• ✅ 深度遍历 / 多跳路径查询：需要查询「A 经过 k 层关系能到达哪些节点」，如共同好友、最短路径、传播链路、推荐链。对应本模块 MATCH (s:Student)-[:R_LESSON_OF_STUDENT]->(l:Lesson)<-[:R_LESSON_OF_STUDENT]-(:Student) 这类对关系边进行匹配的语句。
• ✅ 关系结构频繁演化：关系类型可以随时增加或改变，无需像关系型数据库那样反复写 DDL 建表、加外键。
• ✅ 希望查询性能不随关系深度退化：图数据库的遍历开销与涉及的节点/边数量相关，而不是与全表大小相关，因此在关系密集场景下多跳查询比关系型数据库的深层 JOIN 更快。
• ❌ 纯增删改查、无关系的关键字事务系统：如简单的用户管理、订单明细、配置表，它们的关系很浅或基本无关，用图数据库只会增加不必要复杂度，关系型数据库更合适。
• ❌ 强一致、高并发的 OLTP 事务：Neo4j 的事务能力和水平扩展（Sharding）弱于成熟的 MySQL、PostgreSQL，不适合当作强事务核心库。
• ❌ 复杂、动态的聚合统计与报表：图数据库不擅长多维度 GROUP BY、大范围聚合、联表宽表报表，这些是关系型数据库 / 数仓的强项。
• ❌ 超大单机数据量且缺乏集群运维能力：Neo4j 的社区版运行时无法多实例水平扩展，Enterprise 版对硬件和运维要求高，团队若无图数据库运维经验需谨慎。
• ❌ 团队缺乏 Cypher 和图形建模经验：把关系模型正确地映射成图模型需要一定经验，用错了反而造成数据冗余和查询混乱。

3. 常见业务场景

社交关系网络：存储用户、关注/好友关系，实现「二度人脉」「共同好友」「朋友的朋友推荐」。关系沿用户-关注边遍历，正是本模块中「通过课程找同学、通过班级找同学」这一「经过中间节点求连通」逻辑的同构放大版。

风控与反欺诈：把账户、设备、IP、手机号建模为节点，把转账、登录、绑定建模为关系边，通过「同一设备关联的不同账户」「资金经过几跳流入黑名单节点」来识别团伙欺诈和洗钱路径，属于典型的多跳路径挖掘。

知识图谱与推荐引擎：将实体和实体间的语义关系存入图库，用于智能问答的实体链接、路径推理，以及基于「相似邻居」的内容协同过滤推荐——例如「购买过同一商品的人群还喜欢什么」本质就是本模块 collect(distinct s) 按公共邻居分组取交集的做法。

权限与组织架构：将人员、部门、角色、资源建模为节点，用「隶属于」「拥有权限」「可访问」作为关系边，实现复杂的交叉授权与权限继承推导，优点是从某个用户出发沿边遍历即可快速判断是否可达某资源。

IT 运维与依赖分析：把服务、主机、数据库、中间件建模为节点，把「调用/依赖」关系建成边，做故障根因分析（影响面扩散）和服务依赖拓扑可视化，一图看清调用链。

4. 同类技术对比

维度	Neo4j（图数据库）	MySQL / PostgreSQL（关系型数据库）	MongoDB（文档数据库）	ArangoDB（多模型图数据库）
核心数据模型	节点 + 关系边，关系是一等公民	表 + 外键	文档（JSON 嵌套）	支持文档 + K-V + 图三种模型
深度/多跳关联查询	性能优，沿边遍历，代价与深度线性相关	差，深层 JOIN 递归查询复杂且慢	不支持，需应用层多次查	支持并指向图查询优化
查询语言	Cypher（专为图遍历设计）	SQL（JOIN 表达关联）	类 JSON 查询（MQL）	AQL（多模型查询语言）
事务与一致性	原生 ACID，但横向扩展受限	成熟可靠的 ACID，可主从/分库分表	弱一致性为主，可调	支持 ACID
易用性 / 学习成本	有图形建模门槛 + Cypher 需学习	团队普遍熟悉 SQL，门槛低	门槛低，灵活 schema	多模型概念较多，中等
分布式 / 集群能力	企业版支持集群，社区版受限	生态成熟，分库分表方案多	原生水平分片，扩展性好	支持集群分片
适用规模	关系密集、多跳场景的中型偏上规模	海量 OLTP / 通用业务核心	海量、schema 灵活的非关系数据	需要多种数据模型混合的场景

选型建议：当业务的核心价值在「实体之间的关系」且需要深度遍历、路径查询时，Neo4j 是最合适的选择，例如社交、风控、知识图谱——此时用关系型数据库写深 JOIN 既不自然又慢。若业务是通用 CRUD、强事务和高并发 OLTP，应优先选 MySQL/PostgreSQL，它们的事务、成熟度和横向扩展能力都更可靠。数据量大、结构灵活但不强调关联深度时，选 MongoDB 更省心；如果既要海量文档存储又要偶尔做图遍历、且不想同时维护两套存储，ArangoDB 的多模型能力是一个折中选项。落到 Spring Boot 工程里，Neo4j 的优势在于 spring-data-neo4j 提供的 @NodeEntity/@Relationship 注解和 Neo4jRepository 让图建模与 CRUD 几乎和 JPA 一样顺滑，接入成本远低于想象。