Star

看官网的索引原理有些疑惑 请指教

https://nebula-graph.com.cn/posts/how-indexing-works-in-nebula-graph/ 这里讲到了索引的一些原理,但是我还有一些疑问:
lookup查询的时候 怎么和索引的kv存储联系起来?

比如 lookup on tag where tag.col1 ==1 # 使用的 index 是 index1,index1 on tag(col1),
索引存储的时候key是(假定是顶点的属性索引)


查询的时候col1 怎么和partitionid,indexid,vertexid发生关联呢?怎么扫描索引的呢?谢谢

在上边的例子中,是一个等价查询。这条数据在kv里边的存储结构为:
key : partId_IndexID_value(1)_vertexId

那么通过执行计划,发送到storage层的prefixScan的string为partId_IndexID_value(1),这条数据被命中后,会通过解析这条数据得到相应的vertexID。

2赞

通过col1 怎么找到key里面的partid和indexId的呢?我知道 key里面的value(1) 是从col1转换而来

lookup是查所有partId,indexId通过query,能找到一个最优index,就有对应IndexId了

@critical27
这种方法 会遍历所有partid吗?效率高吗?
indexid 通过query?能找到最优的index 不理解什么意思?能举个例子吗?

我这个帖子的内容 可能会是 很多人关注的内容,也希望 这个疑问解答后 能完善官网现有的索引描述 @Amber

1赞

现在同一个vid的索引和数据是存在一起的,对写友好,但是读就得扫所有part。
比如tag有三个字段(c1, c2, c3), 建了几个索引(c1), (c2), (c1, c2), (c1, c2, c3).

lookup on tag where tag.c1 == 1的时候(c1), (c1, c2), (c1, c2, c3)这三种索引都可用
lookup on tag where tag.c1 == 1 and tag.c2 == 1的时候(c1, c2), (c1, c2, c3)比(c1)更好
lookup on tag where tag.c2 == 1的时候只有(c2)可用

联想到mysql的索引 加速查询,场景是读多写少,这个地方 nebula解决的场景问题是?
索引是为了加速查询的,nebula这种遍历 会增量 数倍的查询比较次数吧?(数倍是指 partid的个数)不知道我理解对不对,一起探讨一下,没有挑战的意识

理解的没问题,是所有partId都会读,可能会存在读放大比较严重的问题,但是比较次数是不变的,无非是在所有节点读出这批数据和在一个节点读出这批数据的区别。设计的时候主要是考虑,如果做全局index,那么就需要解决数据和index存在不同节点的问题,可能就需要引入事务(现在没做)。现在这个方案就相对简单一点,另外一个好处是,如果需要在lookup之后还需要读索引之外的字段,可以直接在本地拿。

我理解 这个方案 是目前的最优解,不排除后续改造升级的可能

是的 后面会考虑类似mysql索引的形式

2赞

浙ICP备20010487号