四问复合索引，让你的数据查询速度飞起
本文分享自华为云社区 《华为云GES持久化图数据库复合索引介绍》，作者：村头树下。
本文章主要介绍索引的作用，以及如何实现这种功能，希望可以帮助理解索引的作用以及如何使用索引
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: 
Value:
key的开始部分为kVType，这是所有数据都会存在的固定前缀，用以区分不同类型的数据。然后是Vid是全局唯一点id。Labelid是标识label的内置编码。Value则是属性的数据。
b) 数据访问方式
所有的图数据的查询最终都是依托于KV数据库的访问。常用的访问KV数据的方式有两种：
- 精确查询接口，指定完整的key查询value
- 前缀查询接口，仅指定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的格式为：
对于每一个点，都会有一条对应的Label索引KV。
当需要过滤特定Label时，可以拼出KVType+Label的前缀，利用kv数据底座的前缀查接口，就能直接将所有符合条件的点过滤出来。
2. 对于属性过滤的场景，索引的key格式为：
属性索引只针对个别过滤较为频繁的属性而建立。所以也只会对包含此属性的点才会生成属性索引kv。相比于Label索引这里只是多了一个property字段。此字段填的是Vid对应点的属性的值。需要注意的是，property字段并不包含全部的点属性，仅仅是待过滤属性的值。
当进行属性查询时，由于知道目标值（例如where n.prop=1,目标值就是1）。直接拼出KVTypr+Label+Property，调用前缀查询接口。即可查出所有符合条件的点。
当利用索引查出匹配的索引KV之后，就可以很方便的拿到对应的VId。然后根据此Vid，就能快速查询到这个点的属性，或者邻居等信息。
5. 索引建立的若干建议
索引并不是没有代价的，虽然它能加速查询，但是会降低写操作的性能，以及耗费更多的磁盘空间。所以建立索引之前需要考虑是不是必要的。这可以从数据区分度，数据大小，以及访问频率三个方面来评估。
- 数据区分度：对于属性索引建议在过滤性好的属性上建立。值分布较为分散，比较适合建立。例如身份证号，手机号。但是对于性别这种属性，就不建议为此建立。对于label索引，如果图里面只有一个label，那么建label索引其实也是没有什么必要的，但是大部分情况，label索引都是必要的。
- 数据大小：这主要是针对属性索引来说的，在已经有Label索引的前提下，如果某个label下的点边数目很少，即使扫描所有label代价也不高，这时候没有必要再为其建立属性索引。
- 访问频率：这一点很好理解，只对频繁在where子句中出现的属性建立索引。
