Star

带索引情况下如何提升入库速率

为了更快地定位、解决问题,麻烦参考下面模版提问 ^ ^

提问参考模版:

  • 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);

带索引因为要多写一次,所以性能肯定是没有不带索引好的。建议不带索引导入,然后再重构索引。

我们的业务场景是需要每天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级别的锁的吧

浙ICP备20010487号