本文系 Nebula Graph 发行版 v3.0.0 的性能测试报告。
本文目录
- 测试环境
- 测试数据
- 关于 LDBC-SNB
- Nebula Commit
- 测试说明
- 测试用例和结果
- 查询带边属性
- 查询带目的点属性
- 查询带边属性+目的点属性
- LOOKUP
- FETCH 点
- FETCH 边
- MATCH 索引
- MATCH 一跳
- MATCH 两跳
- 插入点
- 插入边
- v3.0.0 vs v2.6.1（Baseline）性能对比
- 查询带边属性
- 查询带目的点属性
- 查询带边属性+目的点属性
- LOOKUP
- FETCH 点
- FETCH 边
- MATCH 索引
- MATCH 一跳
- MATCH 两跳
- 插入点
- 插入边
- 总结
测试环境
服务器和压测机皆为物理机
- 注意：服务器设置 CPU 为 Performance 模式。
测试数据
测试数据采用 LDBC-SNB SF100 数据集，SF100 数据集大小为 100G，共有 282,386,021 个点以及 1,775,513,185 条边。测试用的图空间分区数为 24，副本数为 3。
关于 LDBC-SNB：关联数据基准委员会（LDBC，Linked Data Benchmark Council），是图（Graph）和 RDF 数据管理的基准指南制定者。社交网路基准（SNB，Social Network Benchmark）是关联数据基准委员会（LDBC）开发的软件基准（Benchmark）之一。关于 LDBC-SNB 数据集，具体请参考以下文档：
- LDBC_SNB_SF100：https://ldbcouncil.org/ldbc_snb_docs/ldbc-snb-specification.pdf
- 24 Partitions：https://github.com/ldbc/ldbc_snb_docs
- 3 Replica Factors：https://github.com/ldbc/ldbc_snb_datagen_spark
Nebula Commit
- nebula-graphd version 96db138
- nebula-storaged version 96db138
测试说明
- 压测工具使用基于 Go 语言的 k6，具体请参阅 k6官方网站；客户端使用的是 nebula-go
- 图表中横坐标轴的 “50_vu“、“100_vu“等中的 “vu” 表示的是 k6 使用的概念 “virtual user”，即性能测试中的并发数；50_vu 表示 50 个并发用户，100_vu 表示 100 个并发用户，以此类推…
- 性能基线使用正式发布的 2.6.1 版本
-
ResponseTime=Latency（服务端处理时长）+网络回传结果时长+客户端反序列化结果时长
测试用例和结果
注：下图涉及的词语解释
- QPS 即吞吐率
- Latency 即服务端耗时
- ResponseTime 即客户端耗时
查询带边属性
GO {} STEP FROM {} OVER KNOWS yield KNOWS.creationDate
一跳·吞吐率
一跳·服务端耗时（ms）
一跳·客户端耗时（ms）
两跳·吞吐率
两跳·服务端耗时（ms）
两跳·客户端耗时（ms）
三跳·吞吐率
三跳·服务端耗时（ms）
三跳·客户端耗时（ms）
查询带目的点属性
GO {} STEP FROM {} OVER KNOWS yield $$.Person.firstName
一跳·吞吐率
一跳·服务端耗时（ms）
一跳·客户端耗时（ms）
两跳·吞吐率
两跳·服务端耗时（ms）
两跳·客户端耗时（ms）
三跳·吞吐率
三跳·服务端耗时（ms）
三跳·客户端耗时（ms）
查询带边属性+目的点属性
GO {} STEP FROM {} OVER KNOWS yield DISTINCT KNOWS.creationDate as t, $$.Person.firstName, $$.Person.lastName, $$.Person.birthday as birth | order by $-.t, $-.birth | limit 10
一跳·吞吐率
一跳·服务端耗时（ms）
一跳·客户端耗时（ms）
两跳·吞吐率
两跳·服务端耗时（ms）
两跳·客户端耗时（ms）
三跳·吞吐率
三跳·服务端耗时（ms）
三跳·客户端耗时（ms）
LOOKUP 查询性能
LOOKUP ON Person WHERE Person.firstName == '{}' YIELD Person.firstName, Person.lastName, Person.gender, Person.birthday, Person.creationDate, Person.locationIP, Person.browserUsed
吞吐率
服务端耗时（ms）
客户端耗时（ms）
FETCH 点查询性能
FETCH PROP ON Person {} YIELD Person.firstName, Person.lastName, Person.gender, Person.birthday, Person.creationDate, Person.locationIP, Person.browserUsed
吞吐率
服务端耗时（ms）
客户端耗时（ms）
FETCH 边查询性能
FETCH PROP ON KNOWS {} -> {} YIELD KNOWS.creationDate
吞吐率
服务端耗时（ms）
客户端耗时（ms）
MATCH 索引性能
MATCH (v:Person) WHERE v.Person.firstName == '{}' RETURN v
吞吐率
服务端耗时（ms）
客户端耗时（ms）
MATCH 一跳性能
MATCH (v1:Person)-[e:KNOWS]->(v2:Person) WHERE id(v1) == {} RETURN v2
吞吐率
服务端耗时（ms）
客户端耗时（ms）
MATCH 两跳
MATCH (v1:Person)-[e:KNOWS*2]->(v2:Person) WHERE id(v1) == {} RETURN v2
吞吐率
服务端耗时（ms）
客户端耗时（ms）
插入点性能
INSERT VERTEX Comment (creationDate, locationIP, browserUsed, content, length) VALUES {}:('{}', '{}', '{}', '{}', {})
吞吐率
服务端耗时（ms）
客户端耗时（ms）
插入边性能
INSERT EDGE LIKES (creationDate) VALUES {}→{}:('{}')
吞吐率
服务端耗时（ms）
客户端耗时（ms）
v3.0.0 vs v2.6.1（Baseline）性能对比
以下数据选取 P99 值。
查询带边属性
GO {} STEP FROM {} OVER KNOWS yield KNOWS.creationDate
一跳·吞吐率
一跳·服务端耗时（ms）
一跳·客户端耗时（ms）
两跳·吞吐率
两跳·服务端耗时（ms）
两跳·客户端耗时（ms）
三跳·吞吐率
三跳·服务端耗时（ms）
三跳·客户端耗时（ms）
查询带目的点属性
GO {} STEP FROM {} OVER KNOWS yield $$.Person.firstName
一跳·吞吐率
一跳·服务端耗时（ms）
一跳·客户端耗时（ms）
两跳·吞吐率
两跳·服务端耗时（ms）
两跳·客户端耗时（ms）
三跳·吞吐率
三跳·服务端耗时（ms）
三跳·客户端耗时（ms）
查询带边属性+目的点属性
GO {} STEP FROM {} OVER KNOWS yield DISTINCT KNOWS.creationDate as t, $$.Person.firstName, $$.Person.lastName, $$.Person.birthday as birth | order by $-.t, $-.birth | limit 10
一跳·吞吐率
一跳·服务端耗时（ms）
一跳·客户端耗时（ms）
两跳·吞吐率
两跳·服务端耗时（ms）
两跳·客户端耗时（ms）
三跳·吞吐率
三跳·服务端耗时（ms）
三跳·客户端耗时（ms）
LOOKUP 查询性能
LOOKUP ON Person WHERE Person.firstName == '{}' YIELD Person.firstName, Person.lastName, Person.gender, Person.birthday, Person.creationDate, Person.locationIP, Person.browserUsed
吞吐率
服务端耗时（ms）
客户端耗时（ms）
FETCH 点查询性能
FETCH PROP ON Person {} YIELD Person.firstName, Person.lastName, Person.gender, Person.birthday, Person.creationDate, Person.locationIP, Person.browserUsed
吞吐率
服务端耗时（ms）
客户端耗时（ms）
FETCH 边查询性能
FETCH PROP ON KNOWS {} -> {} YIELD KNOWS.creationDate
吞吐率
服务端耗时（ms）
客户端耗时（ms）
MATCH 索引性能
MATCH (v:Person) WHERE v.Person.firstName == '{}' RETURN v
吞吐率
服务端耗时（ms）
客户端耗时（ms）
MATCH 一跳性能
MATCH (v1:Person)-[e:KNOWS]->(v2:Person) WHERE id(v1) == {} RETURN v2
吞吐率
服务端耗时（ms）
客户端耗时（ms）
MATCH 两跳
MATCH (v1:Person)-[e:KNOWS*2]->(v2:Person) WHERE id(v1) == {} RETURN v2
吞吐率
服务端耗时（ms）
客户端耗时（ms）
插入点性能
INSERT VERTEX Comment (creationDate, locationIP, browserUsed, content, length) VALUES {}:('{}', '{}', '{}', '{}', {})
吞吐率
服务端耗时（ms）
客户端耗时（ms）
插入边性能
INSERT EDGE LIKES (creationDate) VALUES {}→{}:('{}')
吞吐率
服务端耗时（ms）
客户端耗时（ms）
总结
v3.0.0 版本的性能总体上较 2.6 版本吞吐率有所提高，客户端耗时有所降低，服务端耗时在高并发下有些许提高。原因是 nebula-go 客户端性能有所提高，导致 k6 每轮压测的时长缩短，服务端在高并发下承受更多的压力，所以服务端耗时些微提高。
交流图数据库技术？加入 Nebula 交流群请先填写下你的 Nebula 名片，Nebula 小助手会拉你进群~~
这是一个从 https://nebula-graph.com.cn/posts/nebula-graph-v3.0.0-benchmark-report/ 下的原始话题分离的讨论话题
