请教一个索引设计上面的问题

问一个设计层面的问题:索引重建的过程中,如果属性发生变更,是什么流程呀,索引重建命令也会写到WAL吗,先执行索引重建再追加属性变更吗,这么做的话我感觉更新效率是问题。

开始重建索引之后会创建一个buffer。重建索引的过程中会将存量数据回填,增量数据写入buffer。存量数据回填完成后,再消费buffer。

在buffer消费完成的一瞬间会有短暂的阻塞(可忽略不计)。

3 个赞

重建索引很快是吗,在整个重建的过程中,我理解更新都应该是阻塞的

不会被阻塞。但是在重建索引完成之前不要使用索引去查询,否则查询出来的数据会不完整。

1 个赞

对了,还有一个小问题想问您:存储引擎的Hash规则为什么会用起点而没用终点呢?

每条边实际上在起点终点两个Part中都会有存储。

比如:

有一条边:A->B。点A存储在Part1上,点B存储在Part2上。

此时Part1上会记录以A为起点的出边,并且按A进行Hash。同时Part2上会记录以B为终点的入边,并且按B进行Hash。

更多细节可以参考 Storage 服务 - Nebula Graph Database 手册

1 个赞

我的问法有问题,
假设这么一个场景吧,查找A所有大学同学(大学这个属性假设没有被当作边属性的一部分),这里面其实用到了终点的属性
按照我之前的了解:NebulaGraph首先会通过A的vid定位到其中一个分片,然后找出符合同学关系的所有出边,将终点汇总返回查询引擎层,然后再将终点做分组hash。并行请求存储引擎,存储引擎再根据终点做过滤。这样其实是多了一次请求存储引擎,而且返回查询引擎的数据量也很大,如果能在第一次调用存储引擎的过程中做完过滤是最好的了。

NebulaGraph 目前是怎么优化这种请求的,或者说将来有什么计划去处理终点过滤排序和截取的方案吗

我理解你说的数据模型是这样的:

A(大学:X) <–(关系:同学)–> B(大学:X)

然后找到在X大学的所有B并且和A是同学关系。

这种请求是没办法优化的,必须进行两次RPC请求。因为A和B不一定在同一个Part中。

1 个赞

多谢大佬

1 个赞