4. 知识图谱存储技术：图数据库选型与Schema设计

在金融知识图谱的A/B测试体系中，存储层决定了查询性能、扩展能力与运维成本。本章聚焦图数据库选型、Schema设计原则与索引优化策略，为后续实验提供稳定的数据底座。

4.1 图数据库选型：Neo4j vs JanusGraph

金融场景对图数据库的核心要求包括：事务一致性（资金流水）、毫秒级深度遍历（关联交易挖掘）、水平扩展（百亿节点）以及多模态支持（属性图+时序）。下表对比两大主流方案：

4.2 Schema设计原则

金融知识图谱的Schema设计直接影响A/B实验的指标计算效率。遵循以下四项核心原则：

1. 节点标签（Label）扁平化：避免超过3层继承，例如 Person 直接标记为 自然人，不设 客户→个人客户→高净值 多层标签。
2. 关系类型（Relationship Type）语义化：使用动词短语，如 持有股份、担保、交易，避免模糊命名。
3. 属性冗余与分离：高频查询字段（如身份证号、金额）直接作为节点属性；低频大字段（如合同全文）存入外部存储，图内仅存引用ID。
4. 时间维度显式建模：金融数据强依赖时间窗口，关系上增加 start_time、end_time 属性，支持快照查询。

4.3 索引优化策略

索引是图查询性能的命脉。金融场景下，索引设计需覆盖三种访问模式：

• 点查询：通过唯一标识（如身份证号、统一社会信用代码）快速定位节点。
• 范围查询：按时间、金额等数值字段过滤。
• 全文检索：模糊匹配公司名称、地址等文本字段。

以下为Neo4j与JanusGraph的索引配置对比：

4.4 图数据库选型与索引架构总览

下图展示金融知识图谱存储层的核心组件与数据流向：

4.5 索引优化实战：复合索引与查询模式匹配

金融A/B实验中，最常见的查询模式是“按时间窗口+实体ID”检索关联交易。以下为Neo4j与JanusGraph的索引创建示例：

Neo4j 复合索引

// 为交易节点创建复合索引（交易日期 + 金额）
CREATE INDEX transaction_date_amount IF NOT EXISTS
FOR (t:Transaction)
ON (t.trade_date, t.amount);

// 唯一约束（身份证号）
CREATE CONSTRAINT person_id_unique IF NOT EXISTS
FOR (p:Person)
REQUIRE p.id_card IS UNIQUE;

JanusGraph 复合索引

// 通过 ManagementSystem 创建复合索引
mgmt = graph.openManagement()
idCard = mgmt.getPropertyKey('id_card')
mgmt.buildIndex('personIdCardUnique', Vertex.class)
     .addKey(idCard)
     .unique()
     .buildCompositeIndex()

tradeDate = mgmt.getPropertyKey('trade_date')
amount = mgmt.getPropertyKey('amount')
mgmt.buildIndex('transactionDateAmount', Edge.class)
     .addKey(tradeDate)
     .addKey(amount)
     .buildCompositeIndex()
mgmt.commit()

4.6 Schema设计示例：企业担保网络

以下为金融知识图谱中“企业担保网络”的Schema设计，包含节点标签、关系类型及关键索引：

4.7 索引维护与A/B实验注意事项

• 索引创建时机：在数据导入前创建索引，避免导入后重建导致性能抖动。
• 索引监控：定期检查索引命中率（Neo4j: :schema；JanusGraph: mgmt.printIndexes()），未命中索引的查询应记录并优化。
• A/B实验隔离：不同实验组使用独立的图空间或标签前缀，避免索引冲突。例如对照组使用 Company_v1，实验组使用 Company_v2。
• 写放大控制：索引过多会拖慢写入速度。金融图谱中，建议将索引数量控制在节点属性的20%以内，关系属性索引不超过5个。