性能测试对比:Nebula 2.0.1 vs Nebula 1.2.0

目录

  • 一、测试结论
    • 1.1 测试结论
  • 二、测试环境
    • 2.1 机器
    • 2.2 部署方式
    • 2.3 Space 信息
    • 2.4 配置文件
  • 三、测试数据
  • 四、测试用例
    • 4.1 CASE1
    • 4.2 CASE2
    • 4.3 CASE3
    • 4.4 CASE4
  • 五、测试结果及说明
    • 5.1 测试指标
    • 5.2 测试结果
      • 5.2.1 CASE1
      • 5.2.2 CASE2
      • 5.2.3 CASE3
      • 5.2.4 CASE4
    • 5.3 测试结果说明

一、测试结论

1.1 测试结论

测试结论如下:

  • 一跳场景下,Nebula v2.0.1 吞吐下降约 10%-20%(原因分析详见 5.3)
  • 多跳场景下,Nebula v2.0.1 表现优于 Nebula v1.2.0
    • 简单目的点查询场景下,两个版本基本持平
    • 其他查询场景下,Nebula v2.0.1 吞吐量提升在 35%-100% 之间,延迟下降在 10%-50% 之间

下面为具体的测试过程。

二、测试环境

2.1 机器

4 台物理机:48 Core,256G Mem,1.5T SSD,万兆网

2.2 部署方式

服务 数量 说明
graphd 1 单机部署
metad 3 使用 3 台机器混布
storaged 3 使用 3 台机器混布

表2-1 服务部署方式说明

2.3 Space 信息

Space 名称 分片数量 备份数量 VID 类型
ldbc_snb_sf100_vid_int 24 1 INT64

表 2-2 Nebula v2.0.1 Space 信息说明

Space 名称 分片数量 备份数量 VID 类型
ldbc_snb_sf100 24 1 INT64

表 2-3 Nebula v1.2.0 Space 信息说明

2.4 配置文件

Storage:

  • –rocksdb_block_cache=81920
  • –max_handlers_per_req=1
  • –heartbeat_interval_secs=10

其他配置参见 Nebula 生产环境配置。配置文件在 conf 目录下的三个配置文件:

  • nebula-graphd.conf.production
  • nebula-storaged.conf.production
  • nebula-metad.conf.production

三、测试数据

本次测试及性能对比均采用 LDBC 100G 数据集。

四、测试用例

本次测试共选择了四个测试用例。

4.1 CASE1

该用例用于测试 N 跳拓展取目的点 ID。语句用法如下:

GO {N} STEP FROM {vid} OVER knows  

4.2 CASE2

该用例用于测试 N 跳拓展取边属性。语句用法如下:

GO {N} STEP FROM {vid} OVER knows yield knows.`time`  

4.3 CASE3

该用例用于测试 N 跳拓展取目的点属性。语句用法如下:

GO {N} STEP FROM {vid} OVER knows yield $$.person.first_name  

4.4 CASE4

该用例用于测试 N 跳拓展后取边属性以及目的点属性,并进行 TOPN 计算。语句用法如下:

GO {N} STEP FROM {vid} OVER knows YIELD DISTINCT knows.`time` as t, $$.person.first_name, $$.person.last_name, $$.person.birthday as birth | order by $-.t,$-.birth | limit 10  

五、测试结果及说明

5.1 测试指标

本次测试主要考察系统吞吐量(Throughput),查询延迟(Latency)。其中 Latency 部分将分别考察服务端及客户端的结果,并细分为 P99,P95,P90 三个指标。

5.2 测试结果

5.2.1 CASE1

语句 GO {N} STEP FROM {vid} OVER knows 测试结果

图5-1 CASE1 一跳查询吞吐量

图5-2 CASE1 一跳查询服务端延迟

图5-3 CASE1 一跳查询客户端延迟

图5-4 CASE1 两跳跳查询吞吐量

图5-5 CASE1 两跳查询服务端延迟

图5-6 CASE1 两跳查询客户端延迟

图5-7 CASE1 三跳查询吞吐量

图5-8 CASE1 三跳查询服务端延迟

图5-9 CASE1 三跳查询客户端延迟

5.2.2 CASE2

语句 GO {N} STEP FROM {vid} OVER knows yield knows.time 测试结果:

图5-10 CASE2 一跳查询吞吐量

图5-11 CASE2 一跳查询服务端延迟

图5-12 CASE2 一跳查询服务端延迟

图5-13 CASE2 两跳查询吞吐量

图5-14 CASE2 两跳查询服务端延迟

图5-15 CASE2 两跳查询客户端延迟

图5-16 CASE2 三跳查询吞吐量

图5-17 CASE2 三跳服务端延迟

图5-18 CASE2 三跳客户端延迟

5.2.3 CASE3

语句 GO {N} STEP FROM {vid} OVER knows yield $$.person.first_name 测试结果

图5-19 CASE3 一跳吞吐量

图5-20 CASE3 一跳服务端延迟

图5-21 CASE3 一跳客户端端延迟

图5-22 CASE3 两跳吞吐量

图5-23 CASE3 两跳服务端延迟

图5-24 CASE3 两跳客户端延迟

图5-25 CASE3 三跳吞吐量

图5-26 CASE3 三跳服务端延迟

图5-27 CASE3 三跳客户端延迟

5.2.4 CASE4

语句 GO {N} STEP FROM {vid} OVER knows YIELD DISTINCT knows.time as t, $$.person.first_name, $$.person.last_name, $$.person.birthday as birth | order by $-.t,$-.birth | limit 10 测试结果

图5-28 CASE4 一跳吞吐量

图5-29 CASE4 一跳服务端耗时

图5-30 CASE4 一跳客户端耗时

图5-31 CASE4 两跳跳吞吐量

图5-32 CASE4 两跳服务端延迟

图5-33 CASE4 两跳客户端耗时

图5-34 CASE4 三跳吞吐量

图5-35 CASE4 三跳服务端耗时

图5-36 CASE4 三跳客户端耗时

5.3 测试结果说明

与 Nebula v1.2.0 相比,Nebula v2.0.1 在多跳场景下吞吐量有较大提升,同时延迟也得到了降低。

在单跳场景下,Nebula v2.0.1 吞吐量有所下降,同时延迟也有相应上升。究其原因,主要是因为 Nebula v2.0.1 将查询语句拆分成多个子任务的查询计划,导致异步任务剧增。由于一跳场景都是小任务,所以在高吞吐情况下,会出现任务排队,导致延迟上升,同时吞吐量相比 v1.2.0 有所下降。

性能测试对比报告.pdf (3.3 MB)

3赞

那未来 这个点 会考虑优化吗?如何优化呢?

会优化的,具体方案可以关注我们后续版本。

1赞

服务端和客户端耗时是通过什么获取到的?

几个线程并发压测的?

请问一下采用的多少线程的压测?
是否可以获取一下测试脚本
想进行一下复测,比较一下与Neo4j的性能

1赞

服务端和客户端都会统计耗时的,每次请求都能获取到这两个时间。具体怎么用你可以看下相关客户端。

10~500,你可以仔细看看我们报告中的配图。

想问下这几个CASE每个case平均返回的数据量有多大,具体来讲:

  1. 每秒接收多少K的数据
  2. 测试使用到的点平均处理的记录数
  1. 有一些原始数据,但是没做统计。具体不同case,不同步数,数据量都是不一样的。
  2. 不明白平均处理的记录数是什么意思。
  1. 一个case,放不同的点进去,步数不同,数据量不同,有的三跳邻居为几十,有的三跳邻居可达千万,邻居数不在一个数量级,即便是都返回count,tps什么的也会不同吧。
  2. 同1的回复,可以理解为最后一跳要处理的节点数目的平均值。

Jmeter 测试的代码可以提供一份么

是的,所以测试一般都是关注P99这样的指标,很少去关注均值。

请问这个数据集各节点会占用多大内存空间,数据集处理的时候是否有特殊要求,比如去掉第一行?

基本上是均匀分布的,数据不需要特殊处理。

你好,请教一下,我在压测的时候使用jmeter,看压测结果里面只有一个Latency数据,应该时客户端查询时迟,请问服务端时延需要怎么查看呢?能通过jmeter的配置来获取么?

浙ICP备20010487号