3. 知识图谱存储选型：图数据库与关系型数据库的对比及 SQL on Graph 方案

在金融知识图谱的构建中，存储选型直接决定了查询性能、扩展能力和开发复杂度。本章将系统对比图数据库（Neo4j、JanusGraph）与关系型数据库（PostgreSQL）在知识图谱场景下的核心差异，并介绍“SQL on Graph”这一融合方案。

3.1 三大存储引擎核心对比

以下从数据模型、查询语言、事务支持、扩展性及金融场景适用性五个维度进行对比：

对比维度	Neo4j	JanusGraph	PostgreSQL
数据模型	属性图（节点+关系+属性）	属性图（节点+关系+属性）	关系模型（表+行+外键）
查询语言	Cypher（声明式图查询）	Gremlin（遍历式图查询）	SQL（结构化查询）
事务支持	ACID（单实例）	ACID（依赖后端存储）	ACID（强一致性）
扩展性	单机为主，企业版支持集群	原生分布式（HBase/Cassandra）	主从复制/分片（需中间件）
金融场景适用性	实时风控、关联查询	超大规模图谱、离线分析	交易记录、结构化报表

3.2 图数据库 vs 关系型数据库：多跳查询性能对比

以“查询某账户两跳以内的所有交易对手及路径”为例，对比 Cypher 与 SQL 的实现差异：

3.2.1 Neo4j Cypher 实现

MATCH (a:Account {id: 'ACC001'})-[r:TRANSFER*1..2]->(target)
RETURN a.id AS source, target.id AS target, 
       collect(r.amount) AS amounts, 
       length(r) AS hops

3.2.2 PostgreSQL SQL 实现（递归 CTE）

WITH RECURSIVE path AS (
    -- 初始查询：从源账户出发
    SELECT id AS source, target_id, amount, 1 AS depth
    FROM transfers
    WHERE source_id = 'ACC001'
    UNION ALL
    -- 递归：连接下一跳
    SELECT p.source, t.target_id, t.amount, p.depth + 1
    FROM path p
    JOIN transfers t ON p.target_id = t.source_id
    WHERE p.depth < 2
)
SELECT * FROM path;

3.3 SQL on Graph 方案介绍

“SQL on Graph”旨在让熟悉 SQL 的团队也能高效查询图数据，降低学习成本。目前主流方案包括：

• Apache AGE（基于 PostgreSQL）： 以 PostgreSQL 扩展形式提供图查询能力，支持 Cypher 语法与 SQL 混合查询。
• Neo4j JDBC + SQL 映射： 通过 APOC 过程将 Cypher 结果映射为虚拟表，支持 JDBC 驱动用 SQL 查询。
• JanusGraph + GraphQL： 通过 GraphQL 中间层封装 Gremlin 遍历，对外暴露类 SQL 的查询接口。

3.4 存储选型决策流程

以下 SVG 图展示了金融知识图谱存储选型的决策路径：

3.5 混合存储架构实践

在大型金融知识图谱项目中，常采用“图数据库 + 关系型数据库”的混合架构：

• 图数据库（Neo4j/JanusGraph）： 存储实体间的关联关系，支撑实时风控、反欺诈、关联交易挖掘等深度遍历查询。
• 关系型数据库（PostgreSQL）： 存储实体属性、交易流水、财务报表等结构化明细数据，支撑精确查询和报表生成。
• 同步机制： 通过 Kafka 消息队列或 CDC（Change Data Capture）工具实现两库间的增量数据同步。

3.6 选型建议总结

场景	推荐方案	理由
实时风控、反欺诈（深度 < 5 跳）	Neo4j + Cypher	低延迟、高并发、图遍历性能最优
超大规模图谱（百亿级节点）	JanusGraph + Gremlin	原生分布式、水平扩展能力强
结构化报表、精确查询	PostgreSQL + SQL	强一致性、成熟生态、BI 工具兼容
团队 SQL 技能固化、查询深度浅	Apache AGE（SQL on Graph）	零学习成本、兼容现有 SQL 基础设施