特性讲解性能报告
NebulaGraph v3.0.0 性能报告
本文系 NebulaGraph 发行版 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 小助手会拉你进群~~