为了更快地定位、解决问题,麻烦参考下面模版提问 ^ ^
提问参考模版:
nebula 版本:2.0 beta
部署方式(分布式 / 单机 / Docker / DBaaS):Docker 单机
硬件信息
磁盘( 必须为 SSD ,不支持 HDD)SSD
CPU、内存信息:40C 126G
出问题的 Space 的创建方式:执行 describe space xxx
;
问题的具体描述
你好,我在测试nebula在我们业务场景下的入库性能,不带索引时的入库性能可以达到我们的目标,但是建立索引入库时的性能很差,偶尔还有入库超时的情况。
不带索引可以达到6万条数据(业务数据)/秒,加索引后降到不到2千条/秒。
我是用的docker部署,graphd、storaged、metad都在一台机器上。
下面是schema定义:
CREATE TAG IF NOT EXISTS linux_process(pid int, pguid string, pname string DEFAULT “”, cmd string DEFAULT “”, created_time int DEFAULT -1,
cmd_id string DEFAULT “”, agent_ip string DEFAULT “”, agent_id string DEFAULT “”);
CREATE EDGE IF NOT EXISTS linux_process_create(datatime int DEFAULT -1, event_src string DEFAULT "", merge_count int DEFAULT -1);
CREATE TAG INDEX IF NOT EXISTS index_linux_process ON linux_process(pid);
Amber
2020 年12 月 11 日 02:24
2
带索引因为要多写一次,所以性能肯定是没有不带索引好的。建议不带索引导入,然后再重构索引。
我们的业务场景是需要每天24小时不间断的持续数据入库,对数据库的查询频率也比较高,而且不是固定在某一时段。
这种在查询之前再建索引,查完删索引的做法感觉不太合适,而且rebuild在大数据量下的耗时也比较长,请问有没有比较成熟的方案可以优化带索引的插入和查询呢?
你好,有以下几个问题:
1,索引和tag或edge的分布情况是什么?每个tag或edge大概附属了几个索引?
2,24小时持续入库的过程中有高峰期吗?时间曲线大概什么样?
3,目前的大概数据量是多少?
索引写入慢的原因有三个:
1, 写入数据增大了,多一个索引就需要多写一份数据。
2,写入索引的过程中,为了保证索引与数据的一致性,需要一边查询一边写入,例如upsert操作,需要删除旧索引插入新索引。这一系列操作都是在原子操作中完成。
3,当大量数据写入后,可能一些数据是无序的,这时会影响上边第2点的查询操作,经过测试,带索引的情况下,bulk insert 时会有性能衰减的情况,这个时候如果做一次compact,性能就可以恢复。
以下是之前在单机ssd存储下做的一个测试,供参考:
--total_vertices_size=2000000
============================================================================
src/storage/test/StorageIndexWriteBenchmark.cpprelative time/iter iters/s
============================================================================
withoutIndex 5.85s 170.92m
unmatchIndex 6.23s 160.60m
attachIndex 20.57s 48.61m
duplicateVerticesIndex 1.01min 16.56m
multipleIndex 1.03min 16.20m
============================================================================
--total_vertices_size=1000000
============================================================================
src/storage/test/StorageIndexWriteBenchmark.cpprelative time/iter iters/s
============================================================================
withoutIndex 2.75s 364.19m
unmatchIndex 3.52s 284.10m
attachIndex 8.39s 119.24m
duplicateVerticesIndex 23.06s 43.37m
multipleIndex 26.67s 37.50m
============================================================================
--total_vertices_size=100000
============================================================================
src/storage/test/StorageIndexWriteBenchmark.cpprelative time/iter iters/s
============================================================================
withoutIndex 249.19ms 4.01
unmatchIndex 262.50ms 3.81
attachIndex 755.14ms 1.32
duplicateVerticesIndex 1.77s 564.09m
multipleIndex 1.23s 813.10m
============================================================================
--total_vertices_size=10000
============================================================================
src/storage/test/StorageIndexWriteBenchmark.cpprelative time/iter iters/s
============================================================================
withoutIndex 24.60ms 40.65
unmatchIndex 28.94ms 34.55
attachIndex 70.85ms 14.11
duplicateVerticesIndex 162.35ms 6.16
multipleIndex 142.78ms 7.00
============================================================================
--total_vertices_size=1000
============================================================================
src/storage/test/StorageIndexWriteBenchmark.cpprelative time/iter iters/s
============================================================================
withoutIndex 2.97ms 336.30
unmatchIndex 4.19ms 238.76
attachIndex 10.24ms 97.65
duplicateVerticesIndex 19.40ms 51.55
multipleIndex 19.13ms 52.29
============================================================================
**/
1 个赞
1、目前使用的测试数据集,该测试数据集使用的真实场景下的数据,只有一个tag和一个edge,只有tag上建了索引,只对其中一个字段建了索引,详细可见我的问题描述;
2、24小时内真实场景产生的数据量是否存在高峰还不确定,目前测试是假设不存在高峰;
3、目前是入库1000万条数据,每条数据拆分出2个点和一条边;
有几个疑问:
1、带索引入库是原子的,那么过程中会锁库吗?
2、带索引入库后,执行compact后,后续的入库性能会恢复到不带索引的程度吗?
1、带索引入库是原子的,那么过程中会锁库吗?
不会锁库
2、带索引入库后,执行compact后,后续的入库性能会恢复到不带索引的程度吗?
肯定恢复不到不带索引的性能,索引本身也是要写数据的。只能恢复的性能衰减前的状态。
1.目前atomic raft commit应该是有partition级别的锁的吧