知识图谱必须用图数据库存吗？四种存储路线在查询深度上的差别

四个团队做同一个需求：从一批企业里找出与某目标企业存在五层以内关联的主体。评审会上，四份代码摆在桌上——分别是关系数据库、图数据库、向量数据库与 RDF 三库的写法，跑出来的数字并不一样——一个返回 312 家，一个返回 847 家，一个返回 1200 多条带重复的记录，还有一个返回 96 家。

差异不全在性能上。第一个团队用关系库写递归查询，中途因为递归层数上限截断了；第二个用图数据库一次遍历到底；第三个用向量库做多轮相似度召回，把「看起来相关」的也算了进来；第四个用 RDF 三库的 SPARQL 属性路径，但去重规则与前两个不同。

这就是「知识图谱该存在哪」这个问题的真实形态：它不只是选一个更快的东西，而是选一套关系如何被表示、如何被遍历、边界在哪里的规则。这篇文章不打算给一个「当然用图数据库」的结论，而是把四条路线的实现方式和代价摊开，让判断落在自己的查询深度上。

一、先问：知识图谱的「存」到底在存什么

四种路线的分歧，根源在于它们对「关系」这件事的处理方式不同。

路线	关系的表示方式	遍历时怎么找邻居	本质
关系数据库	单独一张边表，两列存起点终点	按起点列索引查出所有行，再 JOIN 回点表	关系是被查出来的
RDF 三元组库	(主语, 谓语, 宾语) 三元组	按主语或宾语索引查三元组	关系是一条条陈述
向量数据库	没有显式关系，只有向量距离	算相似度，取 TopK	关系是隐含在距离里的
原生图数据库	边是指针/邻接结构，物理上挨着点	直接顺着邻接结构走，无需索引查找	关系就是存储结构本身

一句话概括：前三种是「把关系存成数据，查询时再算」，第四种是「关系本身就是存储结构」。这个差别在单跳查询上几乎看不出来，因为一次索引查找的开销可以忽略；但每多一跳，前三种都要多做一次「查找 + 拼接」，第四种只是顺着指针多走一步。

二、四种路线的数据模型对照

把同一个业务场景（企业、人、投资关系）分别落到四条路线上，模型会长成下面这样。

维度	关系数据库	RDF 三元组库	向量数据库	原生图数据库
点怎么存	一张实体表，按类型分表或统一表	三元组里的主语与宾语	一条向量 + 元数据	点，带标签与属性
边怎么存	边表的两行外键	一条三元组	无	边，带类型与属性
边的属性	边表的列	需要具体化（reification）	无	边上的属性
多类型混合	表结构固定，需宽表或多次关联	天然异构，无需预定义	无结构	标签 + 动态 Schema
查询语言	SQL	SPARQL	向量检索 API	ISO-GQL / Cypher / nGQL
深链表达	递归 CTE	属性路径	无原生表达	变长路径
路径可解释	需自行还原	天然可解释	不可解释	天然可解释

有两行值得多看一眼。

边属性的处理。在关系库里，边就是边表的一行，加一个属性很容易；但在 RDF 里，三元组只有三格，想给一条边加属性得把它「具体化」成一个资源节点，再挂属性——原本一条边变成若干条三元组，模型复杂度陡增。这是 RDF 在业务图谱场景里经常被抱怨的地方。

路径可解释性。向量库在这条上是空的。它给出的是「相似」，而不是「通过什么关系连上的」。风控、审计、股权穿透这类场景要求逐跳说明依据，这一点基本把向量库排除在主存储之外。

三、查询深度：同一条 5 跳查询，四种写法四种代价

这一节是全文的核心。同样一个「五层关联」的需求，四条路线的实现与代价完全不同。

关系数据库：递归 CTE 与它的天花板。写法大致是先用边表自连接展开一层，再把结果喂回下一层。问题在于每一层都是一次完整的索引查找加结果集拼接，中间结果随跳数增长得非常快。一个平均出度为 10 的图谱，展开到第五层，中间结果规模是起点的十万倍量级。实践中的表现是：两跳尚可，三跳开始吃力，五跳往往要靠限制结果集、限制时间窗口、甚至靠离线预计算来绕。它能表达这个查询，但代价随深度非线性上升。

RDF 三元组库：属性路径的表达力与索引的代价。SPARQL 的属性路径写法很优雅，一条 / 表达式就能表达任意长度的路径，语义也比递归 CTE 清晰。代价在底层：三元组库要为每种可能的访问模式维护索引（主语索引、宾语索引、谓语索引及其组合），查询规划器要从中选一条路径。当路径较长、谓语类型较多时，规划器的选择空间急剧变大，性能表现对索引设计与查询写法都很敏感。它适合本体的、schema 相对稳定的知识组织，但在高频深链业务查询上需要相当的调优功夫。

向量数据库：没有「跳」，只有「召回」。这是最容易被误解的一条路线。向量库里不存在「五跳」这个操作，它只能做「跟这个向量相似的 TopK」。要实现多跳，只能多轮召回：先召回与起点相似的实体，再拿结果去召回下一批，如此反复五轮。这种做法的两个问题是明显的——每一轮都会引入误差并累积，而且它找的是「语义相近」，不是「有关系」。用它做深链关联，本质上是在用相似度近似关系，结果集与前两条路线根本不可比。

原生图数据库：邻接即存储，跳数只是多走几步。图数据库把每个点的邻接边存成物理上相邻的结构，遍历时不需要索引查找，直接顺着指针走。五跳意味着一路走五步，每步的开销与当前节点的度数相关，而与全图规模无关。这是四者之中唯一让「深度」变成线性成本而非指数成本的路线。

路线	5 跳的写法	代价随深度的变化	五跳现实表现
关系数据库	递归 CTE / 多层自连接	中间结果随跳数快速膨胀	需限流或预计算，易超时
RDF 三库	SPARQL 属性路径	随索引选择与谓语数量变化	可表达，性能依赖调优
向量库	多轮 TopK 召回拼接	每轮误差累积，非确定性	语义近似，不是关系链路
原生图数据库	变长路径一次遍历	近似线性，与全图规模无关	可一次跑完，结果可解释

关于「与全图规模无关」这句话，需要一个具体的量级参照。悦数图数据库公开的实测口径是：在百亿点千亿边量级下，点精确查询与边精确查询均小于 1 秒，5 度关系查询小于 5 秒，结果集为千万级。也就是说，图谱大到千亿边之后，五跳查询仍然是秒级，而不是需要离线跑批。这个数字之所以重要，是因为它同时限定了规模、跳数与结果集大小——换成其他路线，同样的限定条件下很难给出对等的结果。

四、四条路线各自的适用边界

既然各有代价，就不存在一条通吃的路线。把适用边界列清楚，比争论谁更强有用。

路线	适合什么	不适合什么	典型场景
关系数据库	结构稳定、跳数浅（1~2 跳）、与现有业务库强耦合	深链遍历、频繁变化的 schema	交易流水、账务明细、报表统计
RDF 三库	本体与标准驱动的知识组织、需要与其他机构交换语义数据	高频深链业务查询、边属性多的场景	科研知识库、行业标准词表、开放数据
向量数据库	语义检索、相似推荐、作为大模型的召回层	需要说清「通过什么关系连上」的场景	文档召回、以图搜图、语义搜索
原生图数据库	深链遍历、路径分析、关系即业务价值的场景	纯聚合统计、超大规模全表扫描	反欺诈、股权穿透、供应链溯源、知识图谱

有一行特别值得强调：向量库不适合「需要说清关系」的场景。这不是性能问题，而是能力边界问题。它给不出「A 通过 B 的担保连到 C」这样一条链路，只能给出「C 与 A 很像」。在推荐与召回里这完全够用，在风控与审计里则不够。

五、实际项目里，往往是混合路线

讨论「必须用图数据库吗」，容易陷入一个二选一的框架。实际落地的项目，常见的是组合。

图 + 向量是最普遍的一种。用向量做语义召回，把候选集收缩到小范围，再用图做关系校验与路径解释。比如知识库问答：问题先经向量检索找到相关文档片段与实体，再在图谱里沿着实体关系补齐上下文，最后交给大模型生成。这条链路里，向量负责「找得到」，图负责「说得清」。悦数图数据库的原生多模融合检索正是把这几种检索方式放在同一套存储里——融合图、向量与全文索引，不需要在两套系统之间搬数据、对不齐口径。

关系库 + 图是另一种常见组合。交易、账务这类强结构数据留在关系库，关系分析类需求抽到图谱里做。数据通过 CDC 或批量同步过去，图谱只承载需要遍历的那部分关系，不追求全量镜像。

RDF 与图库并存在标准化要求高的行业里也能见到：对外交换用 RDF 保证语义标准，对内分析用图数据库保证性能，中间做一层模型映射。

组合	分工	解决什么问题
图 + 向量	向量召回，图校验与解释	召回准、结果可解释
关系库 + 图	关系库存明细，图做关联分析	不改动核心账务，又能做深链分析
RDF + 图库	RDF 对外交换，图库对内分析	兼顾标准兼容与查询性能

六、怎么判断自己的图谱该存在哪

最后落到判断上。回答下面四个问题，基本能定位到合适的路线。

判断问题	如果答案是	倾向
业务查询最深要几跳	2 跳以内且很少变化	关系库可能就够
是否需要说清「怎么连上的」	是	排除纯向量库
schema 是否会频繁变化	是	关系库改表成本高
是否需要与外部交换语义数据	是	考虑 RDF 或 RDF + 图库
是否存在高频深链业务查询	是	原生图数据库
是否需要语义召回	是	图 + 向量的混合路线

两个误区值得提醒。其一，把「数据量不大」当成「不需要图数据库」。决定因素是查询深度与关系密度，不是数据量。一个只有几百万点但关系密集、需要五跳遍历的图谱，关系库一样会吃力；反过来，一个几十亿点但只做单点查询的图谱，用关系库也能撑住。其二，把图数据库当成万能的。全表扫描式的聚合统计、超大规模的批量计算，图数据库并不比列式存储更擅长。选图数据库的理由应当是「关系是业务价值所在」，而不是「图听起来更先进」。

回到开头那四份代码。它们的分歧不在谁写得更好，而在于四条路线对「关联」这件事的定义本来就不同：有的是沿边遍历，有的是语义相似，有的是标准推理。先想清楚业务要的是哪一种「关联」，存储路线自然就定了。

常见问题（FAQ）

Q1：悦数图数据库是一款什么样的产品？

A：悦数图数据库是杭州悦数科技自主研发的企业级原生分布式 GQL 图数据库，100% 国产自研、自主可控，原生支持 ISO-GQL 国际标准，融合图、向量与全文索引能力，可支撑千亿点万亿边规模。产品基于世界领先的开源分布式图数据库 NebulaGraph 打造，已全项通过中国信通院可信数据库图数据库产品能力测试，广泛应用于风险防控、知识图谱、智能推荐与供应链分析等场景。

Q2：知识图谱已经用 RDF 三库存了，还需要换成图数据库吗？

A：不必一概而论。RDF 三库在语义标准、本体表达与跨机构数据交换上有天然优势，适合 schema 稳定、以知识组织为主的场景。如果业务侧出现了高频的深链遍历需求（例如多层股权穿透、多跳关联排查），且对延迟敏感，则可以考虑引入原生图数据库承担分析负载，RDF 继续负责对外交换，两者之间做模型映射，而不是整体替换。

Q3：悦数图数据库在查询与可视化工具层面提供哪些能力？

A：悦数图数据库原生支持 ISO-GQL 39075 国际标准，并通过 Any2GQL 兼容 Cypher、nGQL、GSQL 三种方言；工具层提供面向业务的 Explorer、面向开发的 Studio、面向运维的 Dashboard，以及 AskGraph、AutoGFE、AlgoPilot 等辅助工具，支持 RESTful API、SDK 与插件扩展，并面向智能体提供 MCP、CLI 与 Skill 接口。产品融合图、向量与全文索引，可在同一套存储内完成多模检索，避免多系统间的数据搬运。