3. 图数据库选型与对比：Neo4j、JanusGraph、NebulaGraph、TigerGraph 的适用场景

在构建反欺诈图谱回放链路时，图数据库的选型直接决定了链路性能、扩展成本与运维复杂度。当前主流图数据库在存储模型、查询语言、分布式架构和事务支持上存在显著差异。本章从反欺诈场景出发，对 Neo4j、JanusGraph、NebulaGraph 和 TigerGraph 进行系统性对比，帮助你在不同业务规模下做出合理选择。

3.1 四款图数据库核心特性对比

3.2 反欺诈场景适用性矩阵

以下矩阵将反欺诈回放链路拆解为四个典型子场景，评估各数据库的匹配度（★ 表示支持程度，最高 5 星）：

3.3 架构对比：从单机到分布式

下图展示了四款数据库在反欺诈回放链路中的典型部署架构差异，重点体现存储与计算分离程度、数据分区策略以及查询执行路径：

3.4 查询语言与反欺诈模式匹配

反欺诈回放链路中，查询语言的表达能力直接影响规则开发效率。以下通过一个典型的 资金环路检测 场景，对比四种查询语言的实现差异：

场景：检测 5 层以内的资金闭环（A → B → C → … → A）

MATCH p = (a:Account)-[:TRANSFER*1..5]->(a)
RETURN p LIMIT 100

g.V().hasLabel('Account').
  repeat(out('TRANSFER')).
    times(5).path().
  filter{it.get().first() == it.get().last()}.
  limit(100)

FIND ALL PATH WITH length FROM
  "A" TO "A" OVER TRANSFER
  WHERE steps <= 5
  YIELD path AS p;

CREATE QUERY cycle_detect() FOR GRAPH anti_fraud {
  SetAccum<EDGE> @@cycle_set;
  Start = {Account.*};
  Result = SELECT t FROM Start: s -(TRANSFER:e)- :t
    ACCUM @@cycle_set += e;
  PRINT @@cycle_set;
}

3.5 选型决策流程

以下流程图帮助你在实际项目中快速确定图数据库选型方向：

3.6 选型避坑清单

• 坑 1：过度依赖单机性能测试。 Neo4j 在单机 100 万节点下的遍历速度可能优于分布式方案，但一旦数据量突破单机内存，性能会断崖式下降。反欺诈数据通常随时间线性增长，必须预留 2~3 年的扩展空间。
• 坑 2：忽略写入与查询的混合负载。 部分数据库（如 Neo4j 社区版）在纯查询场景下表现优异，但高频写入时锁竞争严重。反欺诈回放链路要求同时写入事件流并响应查询，建议压测时采用 7:3 的读写比例。
• 坑 3：Gremlin 学习曲线被低估。 JanusGraph 的 Gremlin 查询语言虽然功能强大，但团队上手周期通常比 Cypher/nGQL 长 2~3 倍。如果团队没有图遍历语言经验，优先考虑声明式语言。
• 坑 4：TigerGraph 的 GSQL 编译执行虽快，但调试困难。 GSQL 的编译错误信息不够直观，且不支持热更新查询（需重启集群）。在快速迭代的反欺诈规则开发中，这可能成为瓶颈。
• 坑 5：NebulaGraph 的组件运维成本。 存算分离架构带来了弹性扩展的优势，但 Meta 服务、Storage 服务、Graph 服务三个组件的监控和调优需要专门的运维人力。小团队建议优先考虑运维复杂度更低的方案。