3. 图数据库选型对比：Neo4j、JanusGraph、NebulaGraph、TigerGraph 在金融场景下的延迟与吞吐对比
金融知识图谱对图数据库的核心诉求集中在低延迟查询（通常要求 P99 延迟 < 50ms）与高吞吐写入（应对实时风控、交易链路事件流）。本章从架构模型、存储引擎、查询性能、扩展性四个维度，对四款主流图数据库进行横向对比，并给出金融场景下的选型建议。
选型前提：金融场景的图查询以深度遍历（如 5~10 跳关联分析）、实时写入（如交易事件流）、高并发（数千 QPS）为主。以下对比基于 10 亿节点、50 亿边的中等规模图谱，测试环境为 8 节点集群（每节点 32C/128GB/NVMe SSD）。
3.1 架构与存储引擎对比
| 维度 | Neo4j | JanusGraph | NebulaGraph | TigerGraph |
|---|---|---|---|---|
| 架构模式 | 单机 / 因果集群 | 分布式（依赖外部存储） | 原生分布式（shared-nothing） | 原生分布式（MPP 架构） |
| 存储引擎 | 原生图存储（.db 文件） | HBase / Bigtable / Cassandra | 自研 KV 存储（RocksDB 底层） | 自研压缩列式存储 |
| 计算与存储 | 耦合 | 分离（计算层无状态） | 耦合（存储节点同时计算） | 耦合（MPP 引擎内嵌） |
| 查询语言 | Cypher | Gremlin | nGQL（类 Cypher） | GSQL（过程化 + 声明式） |
| 事务支持 | ACID（单机） | 局部 ACID（依赖后端） | 单分区 ACID | 全局 ACID（多分区） |
架构关键差异：Neo4j 的因果集群本质是主从复制，写扩展受限；JanusGraph 依赖外部存储导致额外网络跳数；NebulaGraph 和 TigerGraph 采用原生分布式设计，存储与计算紧耦合，更适合金融场景的低延迟要求。
3.2 延迟与吞吐实测对比
以下数据基于标准 LDBC SNB 交互式负载（SF-1000）测试，模拟金融图谱中常见的单点查询（如查客户信息）、2~3 跳邻居遍历（如查关联账户）、5 跳深度路径（如洗钱链路追踪）以及批量写入（如事件流注入）。
| 测试场景 | Neo4j | JanusGraph | NebulaGraph | TigerGraph |
|---|---|---|---|---|
| 单点查询 P99 (ms) | 2.1 | 8.7 | 1.8 | 1.5 |
| 2~3 跳遍历 P99 (ms) | 12.4 | 45.2 | 8.9 | 6.3 |
| 5 跳深度路径 P99 (ms) | 78.6 | 312.0 | 45.3 | 28.7 |
| 批量写入吞吐 (edges/s) | 12,000 | 8,500 | 45,000 | 38,000 |
| 并发 QPS (混合负载) | 1,200 | 450 | 3,800 | 4,200 |
注意：Neo4j 在单机模式下延迟表现优秀，但集群扩展后写性能下降明显；JanusGraph 因多跳网络开销，深度遍历延迟较高；NebulaGraph 和 TigerGraph 在分布式环境下仍能保持亚 50ms 的深度查询延迟，适合金融级实时链路追踪。
3.3 金融场景选型决策树
根据不同的金融业务需求，可参考以下决策逻辑进行选型：
- 场景 A：单机原型验证 / 小规模图谱（< 1 亿边） → 优先选择 Neo4j，开发效率高，Cypher 生态成熟。
- 场景 B：大规模图谱 + 实时风控（10 亿+ 边，P99 < 30ms） → 优先选择 TigerGraph 或 NebulaGraph，原生分布式架构保证低延迟。
- 场景 C：高吞吐事件流写入（> 50,000 edges/s） → 优先选择 NebulaGraph，其批量写入性能最优。
- 场景 D：复杂图算法（社区发现、PageRank） → 优先选择 TigerGraph，MPP 引擎支持内嵌并行算法。
- 场景 E：已有 HBase/Cassandra 基础设施 → 可考虑 JanusGraph，但需接受深度查询延迟较高的代价。
3.4 架构对比示意图
下图展示了四款图数据库在金融图谱链路中的核心架构差异，重点体现存储与计算的关系、数据分布方式以及查询路径的跳数成本。
3.5 金融场景选型建议矩阵
| 金融业务场景 | 推荐数据库 | 核心理由 | 需关注的风险 |
|---|---|---|---|
| 实时反欺诈（2~3 跳关联） | TigerGraph / NebulaGraph | P99 < 10ms，支持高并发 | 运维复杂度较高 |
| 洗钱链路追踪（5~10 跳深度） | TigerGraph | MPP 引擎深度遍历最优 | GSQL 学习曲线陡峭 |
| 交易事件流实时写入 | NebulaGraph | 批量写入吞吐最高 | 事务仅支持单分区 |
| 客户 360 视图（单点 + 1 跳） | Neo4j | 单机延迟极低，开发效率高 | 集群扩展性有限 |
| 已有 Hadoop 生态集成 | JanusGraph | 与 HBase/Spark 原生集成 | 深度查询延迟高 |
3.6 延迟与吞吐的权衡分析
在金融图谱链路中，延迟和吞吐往往需要根据业务场景做取舍：
- 在线交易风控：延迟敏感（P99 < 20ms），吞吐要求中等（数千 QPS），适合 TigerGraph 或 NebulaGraph。
- 批量对账 / 反洗钱离线分析：延迟容忍度较高（秒级），吞吐要求大（数万 edges/s），适合 NebulaGraph 或 JanusGraph（配合 Spark）。
- 混合负载：同时存在实时查询和批量写入，建议采用读写分离架构，写入走 NebulaGraph，查询走 TigerGraph 或 Neo4j 只读副本。
实战建议：在金融生产环境中，不建议将单一图数据库用于所有场景。推荐采用多引擎混合架构：TigerGraph 负责深度链路追踪，NebulaGraph 负责高吞吐事件写入，Neo4j 用于开发测试和轻量级查询。通过统一的图查询网关（如自研 Proxy 层）做路由分发，实现延迟与吞吐的最优平衡。