📚 课程目录第4章主流图数据库产品介绍

主流图数据库产品介绍：Neo4j、JanusGraph、ArangoDB、Amazon Neptune

市面上图数据库产品不少，但真正在生产环境里经得住考验的，其实就那么几个。我个人把常见的分成了两类：原生图存储的和非原生的。这直接影响查询性能和可扩展性。

今天咱们挑四个有代表性的聊聊：Neo4j、JanusGraph、ArangoDB、Amazon Neptune。你想想看，选型本质上就是在「易用性」和「可扩展性」之间做权衡。没有银弹，只有最适合你场景的。

核心观点：选图数据库，先看你的数据规模，再看团队熟悉什么生态。小团队做原型，Neo4j上手快；要做百亿级分布式图，JanusGraph 或 Neptune 更靠谱。

Neo4j — 图数据库界的老大哥

Neo4j 是原生图存储的典型代表。什么叫原生？就是它从磁盘到内存，整个数据模型就是按「节点-关系-属性」设计的，不用把图映射到关系表或者文档里。我最早接触 Neo4j 是在 2016 年做一个知识图谱原型，当时被 Cypher 的直观程度震惊到了。一条路径查询，SQL 要写二三十行，Cypher 两三行搞定。

它的核心优势：

Cypher 查询语言：模式匹配表述非常自然，比如你要查「A的朋友的朋友」，写 MATCH (a:Person)-[:KNOWS*2]->(b) RETURN b 就行。
ACID 事务：OLTP 场景下有保障。我有个做金融风控的朋友，就在 Neo4j 上跑实时交易图谱分析。
生态成熟：有企业版、可视化工具、一大堆驱动程序。

我的习惯：做原型验证时，我通常会开一个 Neo4j Docker 实例，30 分钟就能把 Cypher 跑起来。等确定了图模型，再考虑往分布式方案迁移。

但要注意它的短板：Neo4j 的集群架构在 4.x 之前是主从模式，写扩展性有限。官方推荐单实例处理亿级边以内的场景。你要是遇到百亿级，就得考虑分片方案，但这通常要上企业版。

启动一个本地实例很简单：

docker run \
  --name neo4j \
  -p 7474:7474 -p 7687:7687 \
  -e NEO4J_AUTH=neo4j/password \
  -d neo4j:5-enterprise

连接后执行一个典型的路径查询：

MATCH (alice:Person {name: 'Alice'})
MATCH (bob:Person {name: 'Bob'})
CREATE (alice)-[:KNOWS {since: 2020}]->(bob)
RETURN alice, bob

JanusGraph — 分布式场景的老兵

JanusGraph 前身是 TitanDB，后来由 Linux 基金会托管。它不直接存数据，而是把图数据塞进后端存储（比如 HBase、Cassandra、Bigtable），索引走 Elasticsearch 或 Solr。说白了，它是一个图引擎层，让你在分布式存储之上有一条统一的图查询入口。

我在一个物联网项目里用过 JanusGraph。当时的数据量每天新增上亿个设备间通信关系，Neo4j 单机扛不住，迁移到 JanusGraph + HBase 后，查询能稳定在两三秒以内。嗯，这里要注意：它的学习曲线比 Neo4j 陡，因为你得同时管好几套系统。

维度	Neo4j	JanusGraph
存储方式	原生图存储	后端可插拔（HBase / Cassandra）
查询语言	Cypher	Gremlin（TinkerPop）
写扩展性	有限（主从/RAFT）	强（后端分片）
事务	原生 ACID	后端事务模型决定
适用场景	OLTP、原型	OLAP、大规模图

JanusGraph 的配置稍微麻烦一点。下面是一个基于 HBase 后端的典型配置片段：

storage.backend=hbase
storage.hostname=zk1,zk2,zk3
storage.hbase.table=janusgraph
cache.db-cache=true
cache.db-cache-clean-wait=20
cache.db-cache-time=180000
index.search.backend=elasticsearch
index.search.hostname=es1,es2
index.search.elasticsearch.client-only=true

我曾经踩过的坑——JanusGraph 的事务隔离级别依赖于后端。HBase 本身没有跨行事务，JanusGraph 用锁机制模拟，但高性能场景下容易遇到死锁。建议在生产环境中仔细测试并发写入的冲突率。

ArangoDB — 多模型的瑞士军刀

ArangoDB 挺特别。它原生支持三种模型：文档、键值、图。你想在同一条查询里同时操作文档和图关系？它家 AQL（ArangoDB Query Language）可以做到。

我为什么把它归进来？因为很多场景下，你的数据天生就是混合的。比如电商图谱：用户信息是文档，购买关系是图。用 ArangoDB，你可以在一个库、一条查询里同时处理这两类数据，省去了不同数据库之间的 ETL 开销。

它的图存储用的是「邻接表 + 文档」混合结构。每个顶点是一个文档集合，边是另一个集合，边里存了 _from 和 _to 引用。这种设计让边遍历很快，但做复杂的图分析（比如 PageRank）时，性能不如 Neo4j 的原生存储。

看看 AQL 怎么写一个图遍历：

FOR v, e, p IN 2..3 OUTBOUND 'users/alice' GRAPH 'social'
  FILTER p.edges[0].type == 'friend'
  RETURN { vertex: v, edge: e, depth: p.edges.length }

这段代码从 Alice 开始，向外遍历 2 到 3 层，只保留第一跳是 "friend" 关系的路径。你想想看，在 SQL 里实现同样的逻辑，得写嵌套多深？

我的建议：如果你的数据模型是「文档为主，图关系为辅」，ArangoDB 值得优先考虑。但如果你的核心查询全是图遍历，那还是选原生图数据库更合适。泛用型工具在专项场景下通常会有性能折衷。

Amazon Neptune — 全托管省心方案

Neptune 是 AWS 的托管图数据库服务。它同时支持两种查询语言：Gremlin（属性图）和 SPARQL（RDF 图）。这意味着你可以用同一个集群处理不同的图模型——嗯，这在实际项目中很有用。

我在一个项目里做过这样的切换：上线早期用 Gremlin 做属性图，后来客户要求支持 RDF 数据交换，直接在 Neptune 上开了 SPARQL 端点，数据不用迁移。这灵活性是其他产品很难做到的。

Neptune 的几个关键点：

Serverless 架构：不用操心集群运维、备份、扩容。
高可用：Multi-AZ 部署，故障切换秒级完成。
与 AWS 生态集成：通过 SageMaker 做图机器学习、用 Athena 做分析查询。

但托管服务也有代价：成本相对高，对网络延迟敏感，而且你拿不到底层节点的控制权。对于存敏感数据的场景，有些客户会有合规顾虑。

创建 Neptune 实例后，用 SPARQL 写入一条三元组：

PREFIX ex: <http://example.org/>
INSERT DATA {
  ex:Alice ex:knows ex:Bob .
  ex:Bob ex:worksAt ex:CompanyX .
}

查询 Alice 两跳内的所有关系：

PREFIX ex: <http://example.org/>
SELECT ?s ?p ?o WHERE {
  ex:Alice (ex:knows|ex:worksFor)* ?s .
  ?s ?p ?o .
}

一句话总结：
Neo4j 适合团队规模小、需要快速迭代的场景。
JanusGraph 适合你已经有 HBase/Cassandra 基础设施、需要水平扩展的场景。
ArangoDB 是多模型场景下的平衡选择。
Neptune 是省心方案，尤其适合已经扎根 AWS 的团队。

最后补一句心里话：我见过不少团队在选型上反复纠结。其实没那么复杂——拿真实数据做一次 POC，跑两个你最常用的查询模式，结果就见分晓了。工具是拿来解决问题的，不是拿来供奉的。