Skip to Content
教程NeuG 基准测试:双模式图数据库

NeuG 性能评测:双模式图数据库

本教程演示如何复现 NeuG 的基准性能测试结果。NeuG 支持两种执行模式:

  • 嵌入式模式:直接在 Python 进程中运行查询,零序列化开销
  • 服务模式:连接到 NeuG 服务器进行并发事务工作负载

我们对两种模式与行业标准数据库进行基准测试,展示 NeuG 的性能优势。

注意:LDBC SNB Interactive 基准测试部分仅涵盖复杂读取查询(IC1–IC14)。不包括写入操作和事务更新。完整的 LDBC SNB Interactive 基准测试教程将在未来版本中提供。

数据集:LDBC SNB SF1

两个基准测试使用相同的 LDBC SNB SF1 数据集:

  • 节点:约 300 万(Person、Post、Comment、Tag 等)
  • :约 1700 万(KNOWS、LIKES、HASTAG 等)
  • 大小:压缩约 282MB,解压约 1.1GB

下载数据集

wget https://neug.oss-cn-hangzhou.aliyuncs.com/datasets/ldbc-snb-sf1-lsqb.tar.gz tar -xzf ldbc-snb-sf1-lsqb.tar.gz

LSQB 基准测试(嵌入式模式)

LSQB  包含 9 个偏向分析工作负载的复杂子图匹配查询。此基准测试比较嵌入式模式下的 NeuG 与 LadybugDB。

关于 KNOWS 边的说明:原始 LSQB 基准测试假设 KNOWS 关系是双向的(即如果 A 认识 B,则 B 也认识 A)。在我们的测试中,我们修改了所有涉及 KNOWS 边的查询以使用有向遍历(-[:KNOWS]->)。此调整允许 同一 LDBC SNB SF1 数据集用于 SNB Interactive 和 LSQB 两个基准测试,因为原始 LDBC SNB 数据中的 KNOWS 关系是单向的。此修改不影响评估图数据库查询优化和执行能力的公平性。

查询描述

查询描述
Q1长路径遍历(9 跳链)
Q2带评论-帖子模式的 2 跳
Q3同国家的三角形模式
Q4带 likes/replies 的多标签
Q5通过评论的标签共现
Q6带兴趣标签的 2 跳
Q7用于 likes/replies 的可选匹配
Q8带 NOT EXISTS 的标签模式
Q9带 NOT EXISTS 的 2 跳

运行基准测试

# 创建虚拟环境 python -m venv neug-env source neug-env/bin/activate # 安装依赖 pip install neug real_ladybug # 运行基准测试 cd neug/examples/lsqb_benchmark python run_benchmark.py --data-dir /path/to/ldbc-snb-sf1-lsqb

使用 --force 覆盖现有数据库。

预期结果

在 Apple Silicon Mac (M1/M2/M3) 上,NeuG 仅用单线程就在 9 个查询中的 8 个获胜,即使与 LadybugDB 的最佳多线程结果比较:

查询NeuG (1 线程)LadybugDB (最佳)获胜者
Q12.60s60.24s (4t)NeuG 23.2x
Q20.14s12.69s (8t)NeuG 90.6x
Q30.37s106.22s (2t)NeuG 287.1x
Q40.14s1.24s (8t)NeuG 8.9x
Q50.83s5.72s (8t)NeuG 6.9x
Q60.48s0.15s (4t)Ladybug 3.2x
Q70.58s4.91s (8t)NeuG 8.5x
Q80.71s7.09s (8t)NeuG 10.0x
Q90.60s1.02s (8t)NeuG 1.7x

NeuG 在复杂的多连接查询上表现出色,在三角形模式(Q3)上实现了高达 287x 的加速,在多跳过滤(Q2)上实现了 91x 的加速。LadybugDB 的多线程优势在简单的遍历查询如 Q6 上体现。


LDBC SNB Interactive 基准测试(服务模式)

LDBC SNB Interactive  包含 14 个复杂读取查询(IC1–IC14),涵盖多跳好友查找、最短路径和聚合。此基准测试比较服务模式下的 NeuG 与 Neo4j。

查询描述

查询描述
IC1具有特定名字的好友(最多 3 跳)
IC2好友的最近消息
IC3在两个国家有消息的好友
IC4时间范围内具有特定标签的消息
IC5具有最多好友成员的论坛
IC6有带标签帖子好友
IC7消息的最近点赞
IC8消息的最近回复
IC9好友的好友的最近消息
IC10同月出生的好友
IC11在特定国家工作的好友
IC12具有特定标签类兴趣的好友
IC13两人之间的最短路径
IC14两人之间的加权最短路径

运行基准测试

# 启动 Neo4j 服务器(可选,用于比较) docker run -d --name neo4j \ -p 7474:7474 -p 7687:7687 \ -e NEO4J_AUTH=neo4j/neo4j123 \ neo4j:latest # 创建虚拟环境 python -m venv neug-env source neug-env/bin/activate # 安装依赖 pip install neug neo4j # 运行基准测试 cd neug/examples/ldbc_interactive_benchmark python run_benchmark.py --data-dir /path/to/ldbc-snb-sf1-lsqb

预期结果

在 Apple Silicon Mac (M1/M2/M3) 上,4 个并发客户端运行 300 秒:

吞吐量比较

引擎QPSP50 延迟P95 延迟总查询数
NeuG6173.1 ms20.6 ms185,156
Neo4j12.216.0 ms1,728 ms3,659

NeuG 实现了 Neo4j 50.6x 的吞吐量。在延迟方面,NeuG 的 P95 仅为 20.6ms,而 Neo4j 的 P95 达到 1,728ms。

单查询延迟(P50 ms)

查询NeuGNeo4jNeuG 获胜
IC16.25.2-
IC23.28.42.6x
IC311.1984.489x
IC410.98.0-
IC522.31892.485x
IC62.7423.0159x
IC74.54.0-
IC82.41.0-
IC93.9829.8212x
IC105.384.216x
IC112.46.62.7x
IC123.918.84.8x
IC130.40.82x
IC144.5185.241x

NeuG 在 14 个查询中的 10 个获胜,在复杂的多跳和聚合查询上实现了显著加速。


为什么 NeuG 更快

NeuG 的性能优势来自:

嵌入式模式优势

  1. 图原生查询优化器GOpt  执行基于代价的优化,具有图特定的基数估计。

  2. 列式向量化执行:高效的内存管理和缓存友好的遍历。

  3. 零序列化开销:进程内执行,直接内存访问。

服务模式优势

  1. MVCC 并发控制:高效处理并发事务而不阻塞读取。

  2. 久经考验的引擎:NeuG 基于 GraphScope Flex  构建,该引擎在 LDBC SNB Interactive 上 创下世界纪录 ,达到 80,000+ QPS。


可复现性

所有性能结果均可独立复现:

如果您在复现这些结果时遇到任何问题,请在 GitHub Issues  报告。

Last updated on