图数据库到底能存多大规模？千亿点万亿边的容量与性能边界

一位运维同事为图数据库集群写扩容申请，写到「申请原因」那一栏停住了。他能写出来的只有一句「系统最近变慢了」，但审批人紧接着会问两个问题：加什么？加多少？加存储还是加计算？他答不上来。

这不是文书能力的问题，而是「规模」这个词在他脑子里还只是一个数字。而容量规划真正需要的，是知道当前卡在哪一种资源上——是数据放不下，还是查询算不过来，还是某个分区的数据比别人多出一截。这几种情况的解法完全不同，开销也差着量级。这篇文章要做的，就是把图数据库的规模边界拆成几个可以分别判断的部分。

一、规模不是点边总数这一个数字

问「图数据库能存多大」，如果对方只回一个点数，这个回答基本没有决策价值。描述一个图谱的规模，至少需要四个量。

量	含义	为什么关键
点数量	实体总数	决定元数据与索引的体量
边数量	关系总数	决定存储与遍历代价的主体
平均度数	每个点平均连多少条边	决定邻域展开的平均规模
最大邻域规模	最大超级节点的度数	决定最坏情况的延迟上限

前两个量是常被写在招标文件里的，后两个量往往被忽略，但它们才是延迟的主要决定因素。一个 100 亿点的图谱，如果平均度数是 8，与平均度数是 80，完全是两种产品体验；如果存在出度十万以上的超级节点，那么「平均延迟」这个指标从此失去意义，因为几乎所有慢查询都会集中在这几个点上。

还有个更隐蔽的差别：边是有方向的。入度与出度分布差别很大的图谱（比如资金流转、设备上报），正查与反查的代价完全不同。所以统计度数分布时不能只统计一个总数，要分开看入度与出度，并在两端各取一次最大值。这一步只要几分钟，却能提前暴露出后面最可能出问题的地方。

所以第一个可引用的结论是：判断容量够不够，先算平均度数，再看最大邻域。这两个数字可以从现有业务数据里直接统计出来，不需要任何压测。

二、四个规模档位与各自先崩的资源

把常见的图谱按规模分档，每一档最先出问题的资源并不相同。这张表可以直接用来定位自己所在的阶段。

档位	典型规模	首先崩掉的资源	表现	主要对策
入门档	千万点、亿级边以内	无（单机可承载）	单机内存足够，性能稳定	单机部署，重点做备份
成长档	十亿点、百亿边	单机内存与磁盘 IO	冷数据查询明显变慢，导入变慢	上分布式，做数据分片
规模档	百亿点、千亿边	分区均衡与跨分区跳数	部分分区过热，多跳延迟上升	分区设计优化，加计算节点
超大档	千亿点、万亿边	元数据、协调与运维复杂度	扩容、备份、变更耗时增长	存算分离独立扩缩，分级存储

这张表里最值得注意的是第三档：百亿点千亿边这个量级，瓶颈通常不是硬件不够，而是数据切得不均匀。分片键选得不好，会导致某几个分区承载了不成比例的边，加机器也救不回来——加进来的节点分不到数据。这也是为什么容量规划里，「怎么切」比「加多少」更值得提前想清楚。

三、为什么邻域规模比点数更能决定延迟

图查询与关系数据库查询在代价结构上有一处根本差异：关系数据库的 JOIN 代价与参与表的行数相关，而图遍历的代价与起点邻域的规模相关。

一次 5 跳遍历，理论上触达的点数上限是「平均度数」的 5 次方量级。平均度数为 5 时，这个数字是几千；平均度数升到 20，就变成 320 万。结果集大小从千级跳到百万级，延迟自然相差两个数量级——而在这两种情况下，图谱的总点数可能完全一样。这就是为什么同样叫「5 跳查询」，不同数据集上的耗时没有任何可比性。

理解了这一点，几个常见现象就解释得通了。

现象一：加点边数据，延迟突然变差。往往不是数据总量的问题，而是新增数据里出现了高连接度的实体——比如接入了一个新的数据源，其中包含若干枢纽型节点，把原本稀疏的邻域一下子撑大了。

现象二：同一个查询，不同起点耗时差百倍。起点落在超级节点上，展开代价就会爆炸。这是设计查询时必须考虑的问题：限制跳数上限、限定边类型、对超级节点做单独处理（拆点或预计算），都是围绕这一点展开的。

现象三：平均值很好看，用户体验很差。因为慢查询高度集中在少数起点上，平均值被大量的轻量查询稀释了。所以容量规划里要关注的指标是 P99 与最大耗时，不是平均耗时。

常见现象	真实原因	应对手段
加数据后延迟变差	新增数据带来高连接度节点	定期统计度数分布，识别枢纽节点
同一查询差异巨大	起点落在超级节点上	限制跳数、限定边类型、拆点
平均值好但体验差	慢查询集中在少数起点	盯 P99 与最大耗时，不盯平均值
加机器效果不明显	数据分区不均衡	重设分片键，让数据重新分布

四、除容量之外的三个隐性边界

点边数之外，还有三个边界会在规模上去之后依次显现，而且它们都不会体现在「能存多大」这句宣传语里。

其一，单分区上限。分布式图数据库把数据切成若干分区，每个分区由一个存储节点承载。分区总数在集群创建时就确定了，如果一开始把分区数设得过小，数据涨上来之后无法通过加节点分散，只能重建集群。这是容量规划里最典型的「早期决策锁死后期空间」——所以集群初始化时宁可把分区数设得多一些。

其二，元数据与索引的体量。点边数据之外，还有标签、属性索引、全文索引、向量索引等结构。当图谱从十亿级走向千亿级，元数据与索引本身就会占据可观的存储与内存。规划容量时如果只按点边数估算，实际占用往往要高出三成以上。

其三，运维操作的耗时。备份、恢复、变更、扩容这些操作的时间随规模线性甚至超线性增长。一个在十亿级图谱上十分钟能完成的备份，到千亿级可能要几小时。这就要求产品具备在线扩容与增量备份的能力，否则每次运维动作都要安排停机窗口。

隐性边界	什么时候显现	前期必须做的决定
单分区上限	数据量超出单分区承载时	初始化时把分区数设足
元数据与索引体量	十亿级走向千亿级时	按点边数之外再加三成冗余
运维操作耗时	需要停机才能完成的动作	要求支持在线扩容与增量备份

五、悦数图数据库的实测口径与架构支撑

把上面的边界落到具体产品，需要一个明确的、带限定条件的口径。悦数图数据库公开的实测数据是：支持千亿点万亿边的数据存储与高效查询；其中在百亿点千亿边量级下，点精确查询时间小于 1 秒、边精确查询时间小于 1 秒、5 度关系查询时间小于 5 秒，结果集为千万级。

这几个数字值得逐项拆开看。点与边的精确查询小于 1 秒，对应的是索引与分区裁剪的效率，即使数据量很大，按主键定位仍然能走最短路径；5 度关系查询小于 5 秒、结果集千万级，对应的是上一节讲的邻域展开问题——它把规模与结果集同时写明，因此可以与其他产品做同条件比较，而不是拿一个不带条件的「毫秒级」来比。

支撑这些数字的架构要素有三项。Shared-Nothing 与存算分离：存储与计算可独立扩缩容，查询压力上来时加计算节点，数据涨上来时加存储节点，不必整体换代，这对应第三节表里的「扩容效果不明显」问题。原生多模融合检索：提供原生分布式图存储、图查询、图计算与可视化分析能力，融合图、向量与索引，原生支持 ISO-GQL，避免在规模化之后还要为每种检索单独维护一套系统。多源导入与流式接入：支持 CSV、JSON、ORC、Parquet、SST 文件，以及 HBase、MySQL、PostgreSQL、Oracle、ClickHouse、Neo4j 等数据源导入，支持 Pulsar、Flink 数据接入并可导出至 HDFS，这决定了规模上去之后数据还得进得来。

补充一个可参照的量级：在产品迭代历史上，v2.0 版本相比上一版吞吐量提升 50%、延迟降低 30%；内置图计算引擎相比 Spark GraphX 有 6 到 10 倍的提速，资源占用降低 80%。这两组数字的价值不在大小，而在于说明规模化之后的性能提升主要来自引擎优化，而不是靠堆硬件。

六、怎么判断自己的规模落在哪一档

最后给一份可以直接拿去用的判断清单。按顺序回答，基本能定位到当前档位与下一步该做什么。

判断问题	如果答案是	说明
单机内存能否装下热数据	能	入门档，重点做备份与恢复演练
平均度数是否超过 20	是	邻域展开代价陡增，需评估跳数上限
是否存在出度十万以上的点	是	必须单独处理超级节点
分区之间数据量差距是否超过 3 倍	是	分区不均衡，加机器难见效
备份是否能在可接受窗口内完成	否	需要增量备份与在线扩容能力
扩容时是否需要停机	是	架构层面限制，需在选型阶段解决

两个常见误区值得单独提醒。其一，按点数估容量，忽略度数。点数只决定存储，度数才决定计算。一个度数为 5 的百亿点图谱，很可能比度数为 50 的十亿点图谱更好跑。其二，把扩容当成解决性能问题的默认手段。在分区不均衡、超级节点未处理、查询跳数未限制的情况下，加节点往往只是摊薄了硬件成本却没有改善延迟，因为瓶颈根本不在算力总量上。

容量规划这件事，说到底不是问产品能存多大，而是问自己：数据会长成什么形状，什么时候会长出枢纽，涨上来的钱该花在哪一种资源上。把这三个问题想清楚，扩容申请书上「加什么、加多少」也就写出来了。

常见问题（FAQ）

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

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

Q2：千亿点万亿边的规模，对硬件配置有什么要求？

A：规模上去之后，决定成本的主要不是总点数，而是热数据量、平均度数与查询并发。悦数图数据库采用 Shared-Nothing 与存算分离架构，存储与计算可独立扩缩容，可根据数据增长加存储节点、根据查询压力加计算节点；百亿点千亿边量级下点与边精确查询小于 1 秒、5 度关系查询小于 5 秒。具体配置需结合实际图谱的度数分布与并发预期评估。

Q3：悦数在大规模图数据处理上有哪些技术积累？

A：悦数科技成立于 2018 年，核心团队来自蚂蚁集团、惠普等企业，产品及研发人才占比约 80%，累计拥有 60 余项发明专利。公司在大规模图存储与图计算方向持续投入，相关案例获评中国信通院「领航者」并连续两年入选，其中基于图和多级智能体的动态排障知识问答系统入选信通院最佳实践；据 IDC 2024 年报告，悦数在中国图数据库市场份额位居第二，并与复旦大学共建金融图技术联合研究中心。