分布式图数据库性能深度测试：千亿级数据多跳查询实测

一、为什么图数据库的性能测试比想象中复杂

图数据库选型的时候，很多团队会去看官方 Benchmark 数据，或者做一些基础的 CRUD 性能测试。测出来的数字看起来都差不多，于是开始觉得图数据库的性能差异没那么大。

金融风控系统上线三个月，企业节点从 500 万增长到 3000 万，担保关系从 2000 万增长到 1.5 亿，5 跳遍历查询从 80ms 变成了 2.3 秒，业务部门投诉系统响应变慢；电商推荐系统在大促期间并发查询量峰值突增 10 倍，图数据库节点 CPU 飙到 95%，部分查询超时，推荐结果降级为随机兜底；供应链分析系统要做跨 6 跳的路径查询，跑出来直接超时，只能把查询拆成 3 步手动串联。

这些问题，在早期的性能测试里都没暴露出来。原因很简单：测试数据量太小、测试场景太单一、没有测真正关键的指标。

图数据库的性能测试，和关系型数据库有本质区别。关系型数据库测的核心是 QPS（每秒查询次数）和写入吞吐量，这两个指标在图数据库里当然也重要，但不是最关键的。图数据库最关键的性能指标是：

多跳查询延迟 ——在大规模图上，3 跳、5 跳查询的 P50/P95/P99 延迟是多少，随着数据规模增长这些数字怎么变化。

超级节点处理能力 ——现实数据里必然存在超级节点（比如一个有几十万条关系的核心企业节点），遍历到超级节点时的性能表现是关键。

并发图遍历吞吐量 ——同时有多少个图遍历查询在运行，系统能否保持稳定延迟而不是在并发增加时线性劣化。

扩容后的性能恢复速度 ——加节点之后，图谱数据重新均衡、查询性能恢复到正常水平需要多长时间。

二、测试环境与数据集：怎么设计才算有效

很多公开的性能测试报告，仔细看环境配置会发现两个问题：要么数据集太小（百万级节点在图数据库里根本算不上挑战），要么图结构太均匀（每个节点的出度/入度分布非常平均，和真实业务数据差距极大）。

一个有效的图数据库性能测试，数据集需要满足以下条件：

1.规模要够大：节点数不低于 10 亿，边数不低于 100 亿。这个规模下，图遍历会涉及跨存储分片的网络调用，性能瓶颈才会真正暴露。在 1000 万节点的数据集上测出来的多跳延迟，在 100 亿节点的数据集上可能直接翻 10 倍。

2.度分布要符合幂律：真实世界的图数据普遍满足幂律分布——大部分节点的关系数只有个位数，少数核心节点的关系数高达几十万甚至上百万。如果测试数据集里每个节点出度都是 10 到 20，根本测不出超级节点的处理能力。数据生成时要按幂律分布设置度分布参数，让数据集尽量接近真实业务场景。

3.图结构要有深层路径：如果数据集的图直径（最长最短路径）只有 4 到 5，做 3 跳遍历就覆盖了大部分节点，测不出深层路径查询的真实压力。测试数据集的平均图直径最好在 8 到 12 之间，保证多跳查询的搜索空间是真正有挑战性的。

以悦数图数据库的实测场景为例，采用以下数据集配置：

• 节点数：1200 亿
• 边数：8000 亿
• 节点类型：企业、自然人、账户、交易、事件（5 类）
• 最大单节点出度：约 180 万条（模拟核心枢纽企业节点）
• 图直径：平均 9.3

集群配置 12 台存储节点（每台 128GB 内存、32 核 CPU、NVMe SSD），3 台图计算节点，部署悦数图数据库分布式版本。

三、多跳查询延迟：最关键的那组数字

用上述数据集，分别测试 1 跳、2 跳、3 跳、5 跳查询的延迟分布（P50/P95/P99），每种跳数并发 100 个查询，持续压测 30 分钟取稳定状态数据：

1 跳查询（直接邻居遍历）

• P50：3ms
• P95：11ms
• P99：18ms

2 跳查询（2 度关系遍历）

• P50：12ms
• P95：38ms
• P99：67ms

3 跳查询（3 度关系遍历）

• P50：41ms
• P95：118ms
• P99：195ms

5 跳查询（5 度关系遍历）

• P50：89ms
• P95：267ms
• P99：412ms

几个值得关注的规律：

跳数翻倍，延迟不是指数增长。从 1 跳到 5 跳，P50 延迟从 3ms 增长到 89ms，增长约 29 倍，而不是理论上最坏情况的指数倍。这是图数据库邻接表存储结构的优势——每一跳的遍历是局部操作，不需要全图扫描。

超级节点对 P99 影响明显。3 跳查询的 P99 是 P50 的 4.75 倍，主要原因是少数查询路径经过了超级节点，遍历到超级节点时需要处理大量出边，产生延迟尖峰。悦数通过超级节点特殊存储策略（超级节点的边列表独立存储并建立二级索引），将这个影响控制在 P99 范围内，不影响大多数查询的体验。

深层路径查询依然在可接受范围内。5 跳 P99 412ms，在金融风控、供应链分析等业务场景中是完全可接受的响应时间，而这是在 1200 亿节点、8000 亿边的数据集上的结果。

四、并发压力测试：高峰期能不能撑住

延迟测试只反映单请求的性能，实际业务场景中更关键的是高并发下的表现——当同时有几百个、几千个查询在跑的时候，系统能否保持稳定。

测试方法：以 3 跳查询为基准，从并发 100 逐步加压到并发 2000，每个并发级别持续压测 10 分钟，观察延迟变化和错误率：

并发数	P50 延迟	P99 延迟	错误率	CPU 使用率
100	41ms	195ms	0%	22%
500	48ms	231ms	0%	51%
1000	67ms	318ms	0%	74%
1500	112ms	487ms	0.02%	88%
2000	189ms	821ms	0.11%	97%

几个关键观察：

并发 1000 时，P50 延迟从基准的 41ms 增加到 67ms，增幅约 63%，P99 从 195ms 增加到 318ms。延迟随并发增加不是线性翻倍，而是相对平缓的增长，说明系统在这个并发范围内有比较好的负载均衡机制。

并发达到 1500 到 2000 时，错误率开始出现（0.02% 到 0.11%），CPU 使用率逼近上限，这是当前硬件配置的瓶颈点。这个时候正确的应对不是调参数，而是扩容——加存储节点，把图谱数据进一步分片，降低每个节点的查询压力。

五、扩容测试：加机器之后多久能恢复到正常水平

分布式图数据库的一个关键能力是弹性扩缩容——业务量增长的时候，能不能通过加机器来线性提升性能，而且扩容过程中不能停服。

测试场景：在并发 1500 压测进行中，在线添加 3 台存储节点（集群从 12 台扩展到 15 台）。观察：扩容操作触发后，数据均衡（Rebalance）完成需要多长时间，以及在此过程中查询性能的变化曲线。

测试结果：

• 扩容指令下达到新节点开始接受查询：约 4 分钟（节点启动+元数据注册）
• 数据均衡完成（数据分片重新分配到新节点）：约 38 分钟（8000 亿条边的迁移）
• 均衡完成后 P99 延迟恢复至扩容前水平：约 6 分钟（索引预热）

整个扩容过程，查询错误率始终为 0——扩容是完全在线进行的，业务查询不受影响。P99 延迟在均衡过程中有短暂波动（最高升至约 560ms），均衡完成后迅速恢复。

扩容到 15 节点后，重新测试并发 1500 下的延迟：P50 降至 78ms，P99 降至 334ms，相比 12 节点时的 112ms/487ms 有明显改善，接近线性扩展效果。

这个扩容过程的关键是 Shared-Nothing 架构——每个存储节点完全独立，没有共享内存或共享存储层，新节点加入时只需要接管部分数据分片，不需要修改其他节点的状态。这是分布式图数据库能做到在线扩容且扩容效果近似线性的底层原因。

六、悦数图数据库

上述测试数据来自悦数图数据库在真实业务规模下的基准测试。悦数以 C++ 原生存储引擎为基础，针对图遍历的访问模式专门优化了邻接表存储结构，确保多跳遍历的每一跳都是局部 I/O 操作而非全表扫描，这是在千亿级数据下仍保持毫秒级响应的根本原因。Shared-Nothing 分布式架构消除了节点间的共享状态，扩容时数据均衡过程不影响在线查询，实现真正的不停服线性扩容。超级节点特殊存储策略将高出度节点的边列表独立处理并建立二级索引，有效控制超级节点对 P99 延迟的影响，避免少数热点节点拖累整体查询性能。支持图、向量、全文三模混合检索，GraphRAG 和 AI Agent 场景下的复合查询在单一系统内完成，无需跨系统调用带来的额外延迟。中国移动、美团、京东数科等头部客户的生产环境已在千亿级数据规模下稳定运行，这些实际案例是性能数字背后最真实的背书。