您现在的位置是：首页 > 文章详情

四问复合索引，让你的数据查询速度飞起

日期：2023-09-27点击：243收藏

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

1. 什么是复合索引

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

复合索引有两类。一是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	同上

首先了解无索引的情况下，查询的逻辑，才可以理解索引在此基础上做了什么使得查询能够加速。查询逻辑主要与两个方面有关：数据结构，以及数据访问方式，以及查询场景。

持久化版本所有数据都是以KV（键值对）的方式存储在分布式KV数据库中，在没有建立索引的时候，数据库中仅有原始点边KV。以点数据结构为例：

Key:

Value:

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

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

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

常见查询场景的对应的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的查询，其他所有查询均非常慢。这些查询都需要进行全图点扫描加过滤的方式来获取结果。这与查询出来的结果数目无关。对于较大的图来说，这样的查询代价是十分巨大的。

查询慢的场景无外乎两种场景，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，就能快速查询到这个点的属性，或者邻居等信息。

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

数据区分度：对于属性索引建议在过滤性好的属性上建立。值分布较为分散，比较适合建立。例如身份证号，手机号。但是对于性别这种属性，就不建议为此建立。对于label索引，如果图里面只有一个label，那么建label索引其实也是没有什么必要的，但是大部分情况，label索引都是必要的。
数据大小：这主要是针对属性索引来说的，在已经有Label索引的前提下，如果某个label下的点边数目很少，即使扫描所有label代价也不高，这时候没有必要再为其建立属性索引。
访问频率：这一点很好理解，只对频繁在where子句中出现的属性建立索引。

关注公众号

低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。

持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。

转载内容版权归作者及来源网站所有，本站原创内容转载请注明来源。