nebula性能测试相关问题

问答 问题
,
1

当前部署环境如下

  • nebula 版本：v1
  • 部署方式（分布式 / 单机 / Docker / DBaaS）：3节点分布式 docker swarm
  • 32 core, 64 g 内存，1t 硬盘空间（hdd）
  • 问题的具体描述

我自己导入了一部分ldbc数据74G左右，Edge: 1101,535,334，Vertex: 282,612,309
100个partition，1副本，导入nebula后我查看了storage的大小是76g左右，减去wal文件2.2g左右，74g左右。

关于在测试中如何避免随机误差，我有以下几个问题：

  1. 在这个测试中，标中测的延时貌似是一次查询的延时。请问在实际测试中，是否应该随机抽样n个vertex统计查询延时的平均值(ave)和方差(std dev)。如果是这样，请问有没有推荐的n值。

  2. 在测试中，要如何避免查询结果被cache？同样在这篇report中，1 billion edges的时候2-hop和common friend的时间比1-hop快特别多。请问是否是因为1-hop和2-hop用的是同样的vertex，部分结果在cache中，所以2-hop反而比1-hop快。

    Screen Shot 2021-02-07 at 4.24.43 PM
    Screen Shot 2021-02-07 at 4.24.43 PM1514×1376 224 KB

  3. 在测试3-hop时，会出现超时的问题。请问是否应该修改下图的timeout值，如果是的话，有没有推荐的值。

    image
    image2282×1080 246 KB

6
  1. 这个没有特别固定的值，要想获得客观的性能数据，可以使用benchmark工具 GitHub - vesoft-inc/nebula-bench: Collection of benchmark services and tools for Nebula Graph
  2. 目前没有特别好的方法在同样的数据下避免多次查询产生的cache, 如果实在需要不同步数拓展之间的性能可以用benchmark工具多次压数据
  3. 在数据量大或query复杂的情况是可以根据场景修改timeout的，你可以先改成120秒试一下
7

不会直接cache一个query的结果。但是访问到的kv会被存储层 cache。没有warmup的话，可能第一次各种加载就会特别慢吧。

你可以更改block cache大小。（通常lsm tree的index也会放在cache里面）。当然怎么用好cache本来就是存储系统很重要的一个功能。

另外，你现在的场景，数据量相比内存来说差不多，这样测试就变成了内存类的数据库会更有优势。