图数据库

图数据库以节点和关系作为核心数据模型，适合处理实体之间的连接、路径和网络结构。与关系型数据库通过外键和 JOIN 临时还原关系不同，图数据库会把关系作为一等公民存储和查询，因此在多跳查询、路径发现、关系权重和网络分析场景中更直接。

概念边界

图由节点、边和属性组成。节点表示实体，例如用户、账户、设备、订单、商品、知识条目；边表示实体之间的关系，例如购买、关注、转账、登录、归属、依赖；属性保存节点或边上的业务字段，例如时间、金额、权重、来源、状态。

图数据库适合回答“谁和谁有关”“通过哪些路径相关”“某个节点影响了哪些对象”“关系网络中是否存在异常模式”这类问题。如果查询主要是按主键读取、范围分页、事务写入和复杂聚合报表，关系型数据库或分析型数据库通常更合适。

适用场景

风控关系网络

金融、支付和电商风控经常需要识别设备、账号、手机号、银行卡、地址、IP 之间的复用关系。单次查询可能需要从一个用户出发，沿设备、支付工具、收货地址做多跳扩散，并计算关联节点的风险分。图数据库能直接表达这类关系链路。

用户 -> 登录设备 -> IP 地址 -> 其他用户 -> 支付账户

如果这条链路使用关系型数据库实现，通常需要多张关系表连续 JOIN 或由应用层循环查询，关系层数增加后查询复杂度和延迟都会上升。

权限与组织层级

组织、角色、资源、策略之间经常存在继承和覆盖关系。图模型可以把用户、部门、角色、菜单、接口、数据范围建成节点，把拥有、继承、授权、禁止建成关系，用路径查询解释某个权限来自哪里。

知识图谱

知识图谱关注实体、概念和语义关系，常用于搜索增强、问答、推荐和数据治理。例如“组件属于哪个系统”“指标由哪些字段计算”“报表依赖哪些数据表”等血缘问题，都适合用图结构表达。

推荐与相似关系

用户、商品、标签、行为之间天然形成网络。图数据库可以通过共同邻居、路径权重、PageRank、社区发现等算法辅助召回和解释推荐结果。对于大规模在线推荐，图数据库常作为关系探索或离线特征来源，而不是完整替代推荐引擎。

不适用场景

• 以强事务写入、账务对账、订单状态流转为核心的系统，应优先使用关系型数据库保存权威数据。
• 以大批量扫描、复杂聚合、宽表报表为核心的分析任务，应优先使用列式数据库、数据仓库或湖仓体系。
• 关系层数固定且数据量较小的普通后台查询，没有必要为了两三张表的关联引入图数据库。
• 对团队运维能力要求较高的场景，需要先评估备份恢复、监控告警、查询限流、数据导入和权限隔离能力。

数据建模

图建模应从查询问题反推，而不是把所有表机械转换成节点。节点和边的粒度会直接影响查询复杂度和写入成本。

建模问题	判断方式
什么建成节点	需要被独立查询、聚合、扩散或复用的对象
什么建成边	需要表达方向、权重、时间、来源或路径的关系
属性放节点还是边	描述实体本身放节点，描述一次关系事实放边
是否保留关系型主键	保留，用于和业务主库、日志、搜索索引对齐
是否冗余属性	高频过滤字段可以冗余，但要有同步和校验策略

例如风控场景中，用户、设备、手机号、银行卡适合作为节点；登录、绑定、支付、收货适合作为边；登录时间、支付金额、绑定来源适合作为边属性。

查询示例

不同图数据库的查询语言不完全相同。Neo4j 常用 Cypher，Apache TinkerPop 生态常用 Gremlin。下面示例使用 Cypher 表达建模意图。

CREATE (u:User {id: 'U1001', risk: 'normal'})
CREATE (d:Device {id: 'D9001'})
CREATE (p:Phone {number: '13800000000'})
CREATE (u)-[:LOGIN {time: datetime('2026-05-17T10:00:00')}]->(d)
CREATE (u)-[:BIND]->(p);

查询与某个用户在两跳内相关的设备和账号：

MATCH (u:User {id: 'U1001'})-[*1..2]-(n)
RETURN DISTINCT labels(n) AS type, n
LIMIT 100;

查询多个账号共用同一设备的风险线索：

MATCH (d:Device)<-[:LOGIN]-(u:User)
WITH d, collect(DISTINCT u.id) AS users
WHERE size(users) >= 3
RETURN d.id AS deviceId, users
ORDER BY size(users) DESC;

工程落地

图数据库通常不是唯一数据源。更稳妥的做法是以业务主库保存权威事实，通过 CDC、消息队列或离线任务同步到图数据库，再由图数据库服务关系查询和风险分析。

业务写入 -> MySQL/PostgreSQL -> CDC/Kafka -> 图构建任务 -> 图数据库
                                      |
                                      +-> 校验任务与补偿任务

同步链路要处理幂等、乱序、删除、重复消息和补数。节点主键要稳定，边最好有业务唯一标识或可重复计算的唯一键，否则重复边会污染路径查询和关系计数。

排查入口

现象	检查点
多跳查询变慢	起点是否命中索引、扩散层数是否过大、是否缺少关系方向过滤
查询结果爆炸	是否限制路径长度、关系类型、时间窗口和返回数量
关系缺失	同步任务是否失败、消息位点是否滞后、删除和更新是否被正确处理
关系重复	边唯一键是否稳定，导入任务是否幂等
结果解释困难	边上是否保留来源、时间、业务单号和置信度

选型

Neo4j 生态成熟，适合知识图谱、路径查询和中小规模关系网络探索。JanusGraph 更偏分布式图存储，常与 Cassandra、HBase、Elasticsearch 等组件组合，适合更大规模但运维复杂度更高的场景。ArangoDB 等多模型数据库适合同时需要文档和图能力的系统，但要评估图查询深度、事务范围和生态工具是否满足生产要求。

选型时不要只比较查询语言和产品功能，还要验证导入速度、索引能力、备份恢复、权限模型、监控指标、查询超时控制和数据一致性策略。