华为云GES持久化图数据库复合索引介绍

举报
村头树下 发表于 2023/09/25 09:23:29 2023/09/25
【摘要】 本文章主要介绍索引的作用,以及如何实现这种功能,希望可以帮助理解索引的作用以及如何使用索引 1. 什么是复合索引复合索引是用户手动建立的用于加速查询的一类额外数据。详细参数可以参考规格文档https://support.huaweicloud.com/api-ges/ges_03_0454.html 2. 复合索引能做什么复合索引有两类。一是label索引,用于加速label的扫描。二是属性...

本文章主要介绍索引的作用,以及如何实现这种功能,希望可以帮助理解索引的作用以及如何使用索引

1. 什么是复合索引

复合索引是用户手动建立的用于加速查询的一类额外数据。详细参数可以参考规格文档

https://support.huaweicloud.com/api-ges/ges_03_0454.html

2. 复合索引能做什么

复合索引有两类。一是label索引,用于加速label的扫描。二是属性索引,用于加速属性过滤。
这里列举了一些常用接口(语句)与索引的关系

api接口 索引加速方式
summary 扫描label索引,统计各label点边数目
match (n:user) return count(*) 扫描点label索引,统计label为user的点数目
match ()-[r:label]-() return count® 扫描边label索引,统计指定label点数目
match (n:user) return n limit 1 通过点label索引快速寻找label为user的点
match (n:user) where n.age > 10 return n limit 1 仅有label索引时扫描label索引,寻找user的点,然后进行属性过滤。当存在age属性索引时直接使用属性索引定位到目标点
match (n:user) where n.age in [1, 10] return n limit 1 同上

3. 无索引时如何查询

首先了解无索引的情况下,查询的逻辑,才可以理解索引在此基础上做了什么使得查询能够加速。查询逻辑主要与两个方面有关:数据结构,以及数据访问方式,以及查询场景。
a) 原始点结构
持久化版本所有数据都是以KV(键值对)的方式存储在分布式KV数据库中,在没有建立索引的时候,数据库中仅有原始点边KV。以点数据结构为例:

Key: image.png

Value:image.png

key的开始部分为kVType,这是所有数据都会存在的固定前缀,用以区分不同类型的数据。然后是Vid是全局唯一点id。Labelid是标识label的内置编码。Value则是属性的数据。

b) 数据访问方式
所有的图数据的查询最终都是依托于KV数据库的访问。常用的访问KV数据的方式有两种:

  1. 精确查询接口,指定完整的key查询value
  2. 前缀查询接口,仅指定key的前缀部分,查询所有key的前缀匹配的KV数据对。前缀查相对来说会更加频繁的使用。一个场景可能会需要多次前缀查,而前缀查的次数越多,结果越多,相应的此场景响应速度就越慢。前缀查结果大小直接与前缀的长度有关,前缀越长或者越精确,那么前缀查的结果越少。需要的计算量也越少。相应速度就会越快。

c) 查询场景:
常见查询场景的对应的kv层接口调用:

场景 KV接口及调用次数 查询速度 对应Cypher语句
指定id过滤 前缀查 * 1 快,由于KVType和Vid已知,可以拼出前缀,同时一个id一般不会有太多label,前缀查的结果不会特别多。 match(n) where id(n)=‘0’ return n
指定label过滤 前缀查n + 过滤m 慢, 由于不知道Vid,所以只能先拼出只有KVType的前缀,然后前缀查出所有点,再逐个过滤Label,点数据较多时,会有多次前缀查,分批获取再过滤。 match(n:Label) return n
指定label+属性过滤 前缀查n + 过滤m 慢, 查询前缀为KvType,遍历全图点,先进行Label过滤,再进行属性过滤 match (n:Label) where n.prop=‘xx’ return n
指定属性过滤 前缀查n + 过滤m 非常慢, 查询前缀为KvType,遍历全图点,全部进行属性过滤 match (n) where n.prop=‘xx’ return n

可见,除了指定id的查询,其他所有查询均非常慢。这些查询都需要进行全图点扫描加过滤的方式来获取结果。这与查询出来的结果数目无关。对于较大的图来说,这样的查询代价是十分巨大的。

4. 复合索引如何加速

查询慢的场景无外乎两种场景,label查询或者属性查询。在没有索引的情况下,这两种查询都是建立在全局点扫描的基础上,进行过滤。当有效数据占比越低(例如全局点1w,目标点仅有1个),这种扫描方式就越显得不划算。
对于这两种场景,我们可以建立对应的索引。索引本身也是KV数据。所以其key的布局就决定了其功能。

  1. 对于label过滤场景,索引的key的格式为:
    image.png

对于每一个点,都会有一条对应的Label索引KV。
当需要过滤特定Label时,可以拼出KVType+Label的前缀,利用kv数据底座的前缀查接口,就能直接将所有符合条件的点过滤出来。
2. 对于属性过滤的场景,索引的key格式为:
image.png

属性索引只针对个别过滤较为频繁的属性而建立。所以也只会对包含此属性的点才会生成属性索引kv。相比于Label索引这里只是多了一个property字段。此字段填的是Vid对应点的属性的值。需要注意的是,property字段并不包含全部的点属性,仅仅是待过滤属性的值。
当进行属性查询时,由于知道目标值(例如where n.prop=1,目标值就是1)。直接拼出KVTypr+Label+Property,调用前缀查询接口。即可查出所有符合条件的点。

当利用索引查出匹配的索引KV之后,就可以很方便的拿到对应的VId。然后根据此Vid,就能快速查询到这个点的属性,或者邻居等信息。

5. 索引建立的若干建议

索引并不是没有代价的,虽然它能加速查询,但是会降低写操作的性能,以及耗费更多的磁盘空间。所以建立索引之前需要考虑是不是必要的。这可以从数据区分度,数据大小,以及访问频率三个方面来评估。

  1. 数据区分度:对于属性索引建议在过滤性好的属性上建立。值分布较为分散,比较适合建立。例如身份证号,手机号。但是对于性别这种属性,就不建议为此建立。对于label索引,如果图里面只有一个label,那么建label索引其实也是没有什么必要的,但是大部分情况,label索引都是必要的。
  2. 数据大小:这主要是针对属性索引来说的,在已经有Label索引的前提下,如果某个label下的点边数目很少,即使扫描所有label代价也不高,这时候没有必要再为其建立属性索引。
  3. 访问频率:这一点很好理解,只对频繁在where子句中出现的属性建立索引。
【版权声明】本文为华为云社区用户原创内容,转载时必须标注文章的来源(华为云社区)、文章链接、文章作者等基本信息, 否则作者和本社区有权追究责任。如果您发现本社区中有涉嫌抄袭的内容,欢迎发送邮件进行举报,并提供相关证据,一经查实,本社区将立刻删除涉嫌侵权内容,举报邮箱: cloudbbs@huaweicloud.com
  • 点赞
  • 收藏
  • 关注作者

评论(0

0/1000
抱歉,系统识别当前为高风险访问,暂不支持该操作

全部回复

上滑加载中

设置昵称

在此一键设置昵称,即可参与社区互动!

*长度不超过10个汉字或20个英文字符,设置后3个月内不可修改。

*长度不超过10个汉字或20个英文字符,设置后3个月内不可修改。