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

在反欺诈图谱应用中，图数据库是承载实体关系与实时推理的核心引擎。针对 Kafka 回放链路产生的海量事件流，图数据库需要具备高吞吐写入、低延迟查询、水平扩展以及灵活的数据模型支持。本章从架构、性能、部署复杂度与反欺诈场景契合度四个维度，对 Neo4j、JanusGraph、NebulaGraph 进行系统性对比。

4.1 三大图数据库核心特性总览

4.2 架构对比：原生图 vs 存算分离

下图展示了三种图数据库在 Kafka 回放链路反欺诈场景下的典型部署架构差异。Neo4j 采用单机或有限集群模式，JanusGraph 依赖外部存储层，NebulaGraph 则实现计算与存储的完全解耦。

4.3 反欺诈场景适用性分析

4.3.1 实时风控链路中的关键能力

• 高吞吐写入： Kafka 回放链路每秒可能产生数万到百万级事件，图数据库需要快速完成顶点/边的 upsert 操作。
• 低延迟多跳查询： 欺诈检测常涉及 3~6 跳的关联查询（如设备→账号→交易→对手账号），查询延迟需控制在 100ms 以内。
• 增量更新与历史回溯： 支持时间窗口内的图谱快照查询，用于回放分析。
• 水平扩展： 随着黑产团伙规模增长，图谱数据量可能从十亿级增长到千亿级，数据库必须能线性扩展。

4.3.2 各数据库在反欺诈场景中的表现

4.4 查询语言与开发效率对比

查询语言的易用性直接影响反欺诈规则的开发效率。以下用同一查询场景（查找某设备关联的所有账号及其交易对手）展示三种语言的差异。

// Neo4j - Cypher
MATCH (d:Device {device_id: 'DEV-001'})-[r:USED_BY]-(a:Account)
OPTIONAL MATCH (a)-[t:TRANSFER_TO]-(target:Account)
RETURN d, a, t, target LIMIT 100

// JanusGraph - Gremlin
g.V().has('Device', 'device_id', 'DEV-001')
 .both('USED_BY')
 .fold()
 .unfold()
 .as('account')
 .bothE('TRANSFER_TO')
 .otherV()
 .as('target')
 .select('account', 'target')
 .limit(100)

// NebulaGraph - nGQL
MATCH (d:Device)-[:USED_BY]-(a:Account)
OPTIONAL MATCH (a)-[:TRANSFER_TO]-(target:Account)
WHERE d.device_id == 'DEV-001'
RETURN d, a, target LIMIT 100;

4.5 选型决策流程

以下决策树帮助团队根据自身条件快速确定图数据库选型方向。

4.6 总结与选型建议