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

rose839 · 2020 年12 月 11 日 02:18

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

提问参考模版：

nebula 版本：2.0 beta
部署方式（分布式 / 单机 / Docker / DBaaS）：Docker 单机
硬件信息
- 磁盘（必须为 SSD ，不支持 HDD）SSD
- CPU、内存信息：40C 126G
出问题的 Space 的创建方式：执行 describe space xxx;

image1047×146 5.88 KB
问题的具体描述
你好，我在测试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

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

rose839 · 2020 年12 月 11 日 02:28

我们的业务场景是需要每天24小时不间断的持续数据入库，对数据库的查询频率也比较高，而且不是固定在某一时段。
这种在查询之前再建索引，查完删索引的做法感觉不太合适，而且rebuild在大数据量下的耗时也比较长，请问有没有比较成熟的方案可以优化带索引的插入和查询呢？

bright-starry-sky · 2020 年12 月 11 日 03:38

你好，有以下几个问题：
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
============================================================================
**/

rose839 · 2020 年12 月 11 日 04:01

1、目前使用的测试数据集，该测试数据集使用的真实场景下的数据，只有一个tag和一个edge，只有tag上建了索引，只对其中一个字段建了索引，详细可见我的问题描述；
2、24小时内真实场景产生的数据量是否存在高峰还不确定，目前测试是假设不存在高峰；
3、目前是入库1000万条数据，每条数据拆分出2个点和一条边；

有几个疑问：
1、带索引入库是原子的，那么过程中会锁库吗？
2、带索引入库后，执行compact后，后续的入库性能会恢复到不带索引的程度吗？

bright-starry-sky · 2020 年12 月 11 日 08:03

1、带索引入库是原子的，那么过程中会锁库吗？
不会锁库
2、带索引入库后，执行compact后，后续的入库性能会恢复到不带索引的程度吗？
肯定恢复不到不带索引的性能，索引本身也是要写数据的。只能恢复的性能衰减前的状态。

Shylock-Hg · 2020 年12 月 11 日 08:16

1.目前atomic raft commit应该是有partition级别的锁的吧