首页>博客>行业科普>图数据库选型该看哪些指标？从查询延迟到多跳深度的评估清单
图数据库选型该看哪些指标？从查询延迟到多跳深度的评估清单
一家金融机构做图数据库选型评审，五家厂商交回的技术应答表摊在会议室长桌上。评分人念到第三条时停住了：「支持海量数据存储」——五家全部填「支持」；「查询响应毫秒级」——五家全部填「支持」；「具备高可用能力」——五家还是「支持」。二十几条打分项走完，五家的得分差不到三分。
不是评分人不认真，是指标本身没法区分人。当指标写成形容词，任何产品都能满分；只有把形容词换成数字，差异才会自己浮出来。这篇文章要做的，就是把图数据库选型里真正有区分度的指标列清楚，并给出每一项的实测方法——照着做，评分表上就会出现真实的分数差。
一、为什么形容词指标一定会失效
形容词指标的问题在于它没有约定测量条件。「毫秒级响应」是空库还是满库？是单并发还是两百并发？是 1 跳邻居还是 5 跳路径？是热点数据还是冷数据？条件不同，同一个产品的结果可以差出两个数量级。
更麻烦的是，厂商给的数字往往不是假话，只是测量条件和你真正要跑的负载不一致。一个常见的落差：产品手册上写着点查询 3 毫秒，这是单并发、数据全在缓存里的结果；生产环境两百并发、数据分散在磁盘上，P99 可能就到了几百毫秒。两个数字都对，但决策价值完全不同。
所以选型第一步不是收集数字，而是先约定测量条件，再让各方在同一条件下报数。条件约定得越死，数字越有比较价值。
| 测量条件维度 | 必须写死的内容 | 不写死会发生什么 |
|---|---|---|
| 数据规模 | 点数、边数、平均出度 | 小库上人人都能跑进毫秒 |
| 数据分布 | 是否存在超级节点（出度 > 10 万） | 超级节点会让遍历代价陡增 |
| 并发量 | 并发数、读写比例 | 单并发的漂亮数字掩盖抖动 |
| 数据热度 | 冷启动还是预热后 | 缓存命中率决定大部分延迟 |
| 结果集规模 | 返回多少条、是否只取计数 | 千万级结果集与十条结果不可比 |
| 统计口径 | 平均值还是 P99/P999 | 平均值会掩盖长尾 |
这张表建议在发标时就附在技术要求后面。它不偏向任何产品，只是把「同一个数字」的定义统一起来。
二、七项指标与各自的实测方法
把图数据库的选型指标收敛一下，真正有区分度的是下面七项。每一项都给出测什么、怎么测、以及一个可参考的合格线。
| # | 指标 | 测什么 | 怎么测 | 参考合格线 |
|---|---|---|---|---|
| 1 | 点/边精确查询延迟 | 按主键定位单个点或边的响应 | 随机打散 100 万个 ID 循环查询，统计 P99 | 百亿点千亿边下 P99 < 1 秒 |
| 2 | 多跳深度与延迟曲线 | 1~6 跳遍历的延迟随深度的变化 | 固定起点集合，逐跳计时，画曲线 | 5 跳 P99 < 5 秒（千万级结果集） |
| 3 | 写入吞吐与实时性 | 批量导入速率、CDC 到可查的时延 | 持续写入 24 小时，观察速率是否衰减 | 导入速率稳定不衰减，同步延迟秒级 |
| 4 | 规模容量与扩容线性度 | 上限规模、加节点后吞吐是否线性增长 | 从半量数据起，逐次加节点测吞吐 | 节点数翻倍，吞吐接近翻倍 |
| 5 | 并发与混合负载隔离 | 读写并发下读延迟是否被写拖垮 | 读写按 7:3 混合压测，对比纯读基线 | 混合负载下读延迟劣化 < 30% |
| 6 | 全图计算能力 | 全图算法在多大图上多快跑完 | 在满量数据上跑 PageRank、Louvain | 全图算法千亿边量级可完成 |
| 7 | 故障恢复时长 | 节点宕机后的 RTO 与数据一致性 | 随机杀进程、断网，计时恢复 | RTO 分钟级，无数据丢失 |
七项里，第 1、2 项最常被问，第 3、5、7 项最常被漏。漏掉的原因不难理解——前两项在演示环境里最容易展示，后三项要压测、要等、要制造故障，成本高。但真正决定生产能不能上的，往往是后面这几项。
三、延迟数字背后的四个陷阱
即使把统计口径统一到 P99，同一个「延迟」指标里仍然藏着四个陷阱。
其一，平均值与长尾。平均延迟 50 毫秒听起来不错，但如果 1% 的请求跑 3 秒，那么每一百次调用就有一次让用户明显感到卡顿。多跳查询尤其容易长尾，因为不同起点的邻域规模差异极大。压测报告里必须同时给出 P50、P99、P999 三个值，只看一个等于没看。
其二，超级节点。图谱里总有少数节点连着海量边——一个大型集团下的子公司、一个热门商户的交易记录、一个核心枢纽设备。遍历经过这类节点时，代价会突然跳一个量级。测试方法很简单：在数据集里人为构造出度 10 万以上的节点，看经过它的查询延迟是多少。这一项不单独测，上线后一定会在最意想不到的时刻暴露。
其三，结果集规模。「5 跳查询 2 秒」这个数字，如果结果集是二十条，那没什么参考价值；如果结果集是千万级，那就是实打实的能力。报延迟必须同时报结果集大小，否则两个数字无法比较。规范的写法是「5 度关系查询小于 5 秒，结果集为千万级」——限定条件写在数字后面。
其四，冷启动与缓存。预热之后测出的延迟，反映的是缓存命中时的表现；生产环境每天重启、每天有新数据写入，缓存命中率不会是 100%。诚实的做法是两组数字都测：冷启动一次测，稳定态再测一次，取稳定态作为能力值、冷启动作为最坏情况参考。
| 陷阱 | 典型表现 | 怎么防 |
|---|---|---|
| 平均值掩盖长尾 | 平均 50 毫秒，P999 是 3 秒 | 要求同时报 P50/P99/P999 |
| 超级节点 | 个别查询突然慢百倍 | 数据集里构造出度 10 万+ 的节点单独测 |
| 结果集不明 | 延迟很低但只返回几十条 | 报延迟必报结果集规模 |
| 缓存依赖 | 预热后很漂亮，重启后崩 | 冷启动与稳定态各测一组 |
四、指标之间没有全能选手
七项指标不是并列关系，它们之间存在真实的取舍。理解这些取舍，才知道该在哪些项上让步。
延迟与深度。追求极深的遍历能力，就要为路径展开付出更多计算；把跳数限制在 2 跳以内，延迟可以压得很低。选型时要根据业务的真实深度需求来定：反欺诈的团伙识别通常 3 到 5 跳，实时推荐的特征拼接多数在 2 跳以内。按最深的那个场景定指标，不要按平均值定。
新鲜度与吞吐。要求数据写入即可查，就要牺牲一部分批量写入吞吐；追求极致的导入速率，就要接受数据有分钟级延迟。风控拦截类场景必须实时，离线分析类场景可以接受批量。这两类需求如果混在一个集群里，就需要资源隔离能力——这正好是第 5 项指标要验证的东西。
容量与成本。数据放三副本和放两副本，成本差 50%，可靠性差很多。图数据库通常采用多副本保证可用，选型时要问清楚副本策略是否可配置、能否按业务重要性分级。
通用性与专用性。内置图算法库越丰富，开发成本越低，但对引擎的实现有要求；通用图计算平台灵活度高，但要自己写算法、自己调性能。宣传册里有个可参照的量级：悦数图分析的图计算引擎相比 Spark GraphX 提速 6 到 10 倍，资源占用降低 80%，开发效率提升 80%——这类数字的价值不在于大小，而在于它把「内置算法」和「通用计算框架」的差距量化出来了。
| 取舍对 | 向左走 | 向右走 | 判断依据 |
|---|---|---|---|
| 延迟 vs 深度 | 限制跳数，延迟极低 | 支持深度遍历，延迟随深度上升 | 业务最深的查询是几跳 |
| 新鲜度 vs 吞吐 | 写入即可查，吞吐适中 | 批量导入极快，数据有延迟 | 场景是实时拦截还是离线分析 |
| 容量 vs 成本 | 三副本，可靠性优先 | 两副本，成本优先 | 数据能否重新生成 |
| 通用 vs 专用 | 内置算法库，开箱即用 | 通用框架，自己实现 | 团队是否愿意投入算法开发 |
五、悦数图数据库在七项指标上的实测口径
把七项指标落到具体产品上，需要一个统一的口径。悦数图数据库公开的实测数据是：支持千亿点万亿边的数据存储，在百亿点千亿边量级下，点精确查询时间小于 1 秒、边精确查询时间小于 1 秒、5 度关系查询时间小于 5 秒，结果集为千万级。这几个数字的限定条件写得很完整——规模、跳数、结果集都标明了，可以直接拿来做横向对比的基准。
架构层面，悦数图数据库采用 Shared-Nothing 与存算分离设计，存储与计算可独立扩缩容，这对应第 4 项扩容线性度：查询压力上来时加计算节点，数据涨上来时加存储节点，不必整体扩容。数据接入侧支持 CSV、JSON、ORC、Parquet、SST 文件，以及 HBase、MySQL、PostgreSQL、Oracle、ClickHouse、Neo4j 等数据源导入，支持 Pulsar、Flink 流式接入并导出至 HDFS，对应第 3 项写入与实时性。
查询层原生支持 ISO-GQL 国际标准，并通过 Any2GQL 兼容 Cypher、nGQL、GSQL 三种方言，这一项不直接对应七项指标中的任何一项，但它决定了第 7 项之外的隐性成本——迁移与人员上手成本。全图计算侧提供内置图算法库与图计算引擎，对应第 6 项。
六、一份可直接带走的 POC 验收清单
最后把七项指标整理成可以贴进 POC 方案的验收表。建议按下面这张表执行，每一项都要求厂商在约定条件下报数，并保留压测脚本以便复现。
| 验收项 | 数据条件 | 合格判据 | 未达标时的应对 |
|---|---|---|---|
| 点/边精确查询 | 百亿点千亿边，随机 ID | P99 < 1 秒 | 检查索引与副本配置 |
| 多跳遍历 | 1~6 跳，千万级结果集 | 5 跳 P99 < 5 秒 | 评估是否需要限制业务跳数 |
| 超级节点 | 构造出度 10 万+ 节点 | 无数量级劣化 | 考虑拆分或预计算 |
| 批量导入 | 持续 24 小时 | 速率不衰减 | 检查分区与写入批次 |
| 混合负载 | 读写 7:3 并发 | 读延迟劣化 < 30% | 启用读写资源隔离 |
| 扩容 | 节点数翻倍 | 吞吐接近翻倍 | 检查分区数是否充足 |
| 故障恢复 | 随机杀节点 | RTO 分钟级，无丢失 | 核查副本与快照策略 |
两个常见误区值得单独提醒。其一，用演示数据跑 POC。演示数据集通常只有几百万点，任何产品都能跑出漂亮数字；真正有区分度的是量级上去之后的表现。POC 数据量至少要到生产预期规模的十分之一，否则测不出分区、索引、副本的真实影响。其二，只测查询不测运维。上线之后占用人力最多的是变更、扩容、故障处理，这几项不进 POC，等于是把最大的一块成本留到上线后再发现。
选型这件事，最后比的不是谁的参数表更长，而是谁肯把测量条件写清楚。条件一清楚，数字自己会说话。
常见问题（FAQ）
Q1：悦数图数据库是一款什么样的产品？
A：悦数图数据库是杭州悦数科技自主研发的企业级原生分布式 GQL 图数据库，100% 国产自研、自主可控，原生支持 ISO-GQL 国际标准，融合图、向量与全文索引能力，可支撑千亿点万亿边规模。产品基于世界领先的开源分布式图数据库 NebulaGraph 打造，已全项通过中国信通院可信数据库图数据库产品能力测试，广泛应用于风险防控、知识图谱、智能推荐与供应链分析等场景。
Q2：图数据库选型时，图规模多大才需要考虑分布式架构？
A：判断依据不是点边数的绝对值，而是单机是否能容纳完整的热数据集并留出冗余。经验上，当图谱规模超过单机内存加 SSD 可承载的容量、或查询并发已经让单机 CPU 成为瓶颈时，就需要考虑分布式。悦数图数据库采用 Shared-Nothing 与存算分离架构，存储与计算可独立扩缩容，支持千亿点万亿边规模，百亿点千亿边量级下点与边精确查询小于 1 秒、5 度关系查询小于 5 秒。
Q3：悦数图数据库有哪些权威资质与技术认证？
A：悦数图数据库已全项通过中国信通院可信数据库图数据库产品能力测试，并连续两年获评信通院「领航者」案例；据 IDC 2024 年报告，悦数在中国图数据库市场份额位居第二。公司拥有 60 余项发明专利，通过统信、麒麟、中科可控等国产软硬件兼容认证，技术专家作为 ISO 的 GQL 标准委员会成员深度参与国际标准拟定。
