ClickHouse内幕(3)基于索引的查询优化

京东云开发者
• 阅读 292

ClickHouse索引采用唯一聚簇索引的方式,即Part内数据按照order by keys有序,在整个查询计划中,如果算子能够有效利用输入数据的有序性,对算子的执行性能将有巨大的提升。本文讨论ClickHouse基于索引的查询算子优化方式。

在整个查询计划中Sort、Distinct、聚合这3个算子相比其他算子比如:过滤、projection等有如下几个特点:1.算子需要再内存中保存状态,内存代价高;2.算子计算代价高;3.算子会阻断执行pipeline,待所有数据计算完整后才会向下游输出数据。所以上算子往往是整个查询的瓶颈算子。

本文详细讨论,3个算子基于索引的查询优化前后,在计算、内存和pipeline阻断上的影响。

实验前准备:

后续的讨论主要基于实验进行。

CREATE TABLE test_in_order
(
    `a` UInt64,
    `b` UInt64,
    `c` UInt64,
    `d` UInt64
)
ENGINE = MergeTree
ORDER BY (a, b);

表中总共有3个part,每个part数据量4条。

PS: 用户可以在插入数据前提前关闭后台merge,以避免part合并成一个,如果part合并成一个将影响查询并行度,可能对实验有影响,以下查询可以关闭后台merge:system stop merges test_in_order

一、Sort算子

如果order by查询的order by字段与表的order by keys的前缀列匹配,那么可以根据数据的有序特性对Sort算子进行优化。

1.Sort算子实现方式

首先看下不能利用主键有序性的场景,即对于order by查询的order by字段与表的order by keys的前缀列不匹配。比如下面的查询:

query_1: EXPLAIN PIPELINE SELECT b FROM read_in_order ORDER BY b ASC

它的执行计划如下:

┌─explain───────────────────────────────┐
│ (Expression)                          │
│ ExpressionTransform                   │
│   (Sorting)                           │
│   MergingSortedTransform 3 → 1        │
│     MergeSortingTransform × 3         │
│       LimitsCheckingTransform × 3     │
│         PartialSortingTransform × 3   │
│           (Expression)                │
│           ExpressionTransform × 3     │
│             (ReadFromMergeTree)       │
│             MergeTreeThread × 3 0 → 1 │
└───────────────────────────────────────┘

排序算法由3个Transform组成,其中

1)PartialSortingTransform对单个Chunk进行排序;

2)MergeSortingTransform对单个stream进行排序;

3)MergingSortedTransform合并多个有序的stream进行全局sort-merge排序



ClickHouse内幕(3)基于索引的查询优化



如果查询的order by字段与表的order by keys的前缀列匹配,那么可以根据数据的有序特性对查询进行优化,优化开关:optimize_read_in_order。

2.匹配索引列的查询

以下查询的order by字段与表的order by keys的前缀列匹配

query_3: EXPLAIN PIPELINE SELECT b FROM test_in_order ORDER BY a ASC, b ASCSETTINGS optimize_read_in_order = 0 -- 关闭read_in_order优化

查看order by语句的pipeline执行计划

┌─explain───────────────────────────┐
│ (Expression)                      │
│ ExpressionTransform               │
│   (Sorting)                       │
│   MergingSortedTransform 3 → 1    │
│     MergeSortingTransform × 3     │
│       (Expression)                │
│       ExpressionTransform × 3     │
│         (ReadFromMergeTree)       │
│         MergeTreeThread × 3 0 → 1 │
└───────────────────────────────────┘

此时order by算子的算法

1)首先MergeSortingTransform对输入的stream进行排序

2)然后MergingSortedTransform将多个排好序的stream进行合并,并输出一个整体有序的stream,也是最终的排序结果。

这里有个疑问在关闭read_in_order优化的查询计划中,系统直接默认了MergeSortingTransform的输入在Chunk内是有序的,这里其实是一个默认优化,因为order by查询的order by字段与表的order by keys的前缀列匹配,所以数据在Chunk内部一定是有序的。

3. 开启优化optimize_read_in_order

┌─explain──────────────────────────┐
│ (Expression)                     │
│ ExpressionTransform              │
│   (Sorting)                      │
│   MergingSortedTransform 3 → 1   │
│     (Expression)                 │
│     ExpressionTransform × 3      │
│       (ReadFromMergeTree)        │
│       MergeTreeInOrder × 3 0 → 1 │
└──────────────────────────────────┘

4. 优化分析

打开optimize_read_in_order后:

1.对于计算方面:算法中只有一个MergingSortedTransform,省略了单个stream内排序的步骤

2.由于内存方面:由于MergeSortingTransform是消耗内存最大的步骤,所以优化后可以节约大量的内存

3.对于poipeline阻塞:MergeSortingTransform会阻塞整个pipeline,所以优化后也消除了对pipeline的阻塞

二、Distinct算子

如果distinct查询的distinct字段与表的order by keys的前缀列匹配,那么可以根据数据的有序特性对Distinct算子进行优化,优化开关:optimize_distinct_in_order。通过以下实验进行说明:

1. Distinct算子实现方式

查看distinct语句的pipeline执行计划

query_2: EXPLAIN PIPELINE SELECT DISTINCT * FROM woo.test_in_order SETTINGS optimize_distinct_in_order = 0 -- 关闭distinct in order优化
┌─explain─────────────────────────────┐
│ (Expression)                        │
│ ExpressionTransform                 │
│   (Distinct)                        │
│   DistinctTransform                 │
│     Resize 3 → 1                    │
│       (Distinct)                    │
│       DistinctTransform × 3         │
│         (Expression)                │
│         ExpressionTransform × 3     │
│           (ReadFromMergeTree)       │
│           MergeTreeThread × 3 0 → 1 │
└─────────────────────────────────────┘

Distinct算子采用两阶段的方式,首先第一个DistinctTransform在内部进行初步distinct,其并行度为3,可以简单的认为有3个线程在同时执行。然后第二个DistinctTransform进行final distinct。

每个DistinctTransform的计算方式为:首先构建一个HashSet数据结构,然后根据HashSet,构建一个Filter Mask(如果当前key存在于HashSet中,则过滤掉),最后过滤掉不需要的数据。

2.开启优化optimize_distinct_in_order

┌─explain────────────────────────────────┐
│ (Expression)                           │
│ ExpressionTransform                    │
│   (Distinct)                           │
│   DistinctTransform                    │
│     Resize 3 → 1                       │
│       (Distinct)                       │
│       DistinctSortedChunkTransform × 3 │
│         (Expression)                   │
│         ExpressionTransform × 3        │
│           (ReadFromMergeTree)          │
│           MergeTreeThread × 3 0 → 1    │
└────────────────────────────────────────┘

可以看到初步distinct和final distinct采用了不同的transform,DistinctSortedChunkTransform和DistinctTransform。

DistinctSortedChunkTransform:对单个stream内的数据进行distinct操作,因为distinct列跟表的order by keys的前缀列匹配,scan算子读取数据的时候一个stream只从一个part内读取数据,那么每个distinct transform输入的数据就是有序的。所以distinct算法有:

DistinctSortedChunkTransform算法一:

Transform中保留最后一个输入的数据作为状态,对于每个输入的新数据如果跟保留的状态相同,那么忽略,如果不同则将上一个状态输出给上一个算子,然后保留当前的数据最为状态。这种算法对于在整个stream内部全局去重时间和空间复杂度都有极大的降低。



ClickHouse内幕(3)基于索引的查询优化



DistinctSortedStreamTransform算法二:(ClickHouse采用的)

Transform对与每个Chunk(ClickHouse中Transform数据处理的基本单位,默认大约6.5w行),首先将相同的数据划分成多个Range,并设置一个mask数组,然后将相同的数据删除掉,最后返回删除重复数据的Chunk。



ClickHouse内幕(3)基于索引的查询优化



3. 优化分析

打开optimize_distinct_in_order后:主要对于第一阶段的distinct步骤进行了优化,从基于HashSet过滤的算法到基于连续相同值的算法。

1.对于计算方面:优化后的算法,省去了Hash计算,但多了判断相等的步骤,在不同数据基数集大小下,各有优劣。

2.由于内存方面:优化后的算法,不需要存储HashSet

3.对于poipeline阻塞:优化前后都不会阻塞pipeline

三、聚合算子

如果group by查询的order by字段与表的order by keys的前缀列匹配,那么可以根据数据的有序特性对聚合算子进行优化,优化开关:optimize_aggregation_in_order。

1.聚合算子实现方式

查看group by语句的pipeline执行计划:

query_4: EXPLAIN PIPELINE SELECT a FROM test_in_order GROUP BY a SETTINGS optimize_aggregation_in_order = 0 -- 关闭read_in_order优化
┌─explain─────────────────────────────┐
│ (Expression)                        │
│ ExpressionTransform × 8             │
│   (Aggregating)                     │
│   Resize 3 → 8                      │
│     AggregatingTransform × 3        │
│       StrictResize 3 → 3            │
│         (Expression)                │
│         ExpressionTransform × 3     │
│           (ReadFromMergeTree)       │
│           MergeTreeThread × 3 0 → 1 │
└─────────────────────────────────────┘

对于聚合算子的整体算法没有在执行计划中完整显示出来,其宏观上采用两阶段的聚合算法,其完整算法如下:1.AggregatingTransform进行初步聚合,这一步可以并行计算;2.ConvertingAggregatedToChunksTransform进行第二阶段聚合。(PS:为简化起见,忽略two level HashMap,和spill to disk的介绍)。

2.开启优化optimize_aggregation_in_order

执行计划如下:

┌─explain───────────────────────────────────────┐
│ (Expression)                                  │
│ ExpressionTransform × 8                       │
│   (Aggregating)                               │
│   MergingAggregatedBucketTransform × 8        │
│     Resize 1 → 8                              │
│       FinishAggregatingInOrderTransform 3 → 1 │
│         AggregatingInOrderTransform × 3       │
│           (Expression)                        │
│           ExpressionTransform × 3             │
│             (ReadFromMergeTree)               │
│             MergeTreeInOrder × 3 0 → 1        │
└───────────────────────────────────────────────┘

可以看到打开optimize_aggregation_in_order后aggregating算法由三个步骤组成:

1)首先AggregatingInOrderTransform会将stream内连续的相同的key进行预聚合,预聚合后在当前stream内相同keys的数据只会有一条;

2)FinishAggregatingInOrderTransform将接收到的多个stream内的数据进行重新分组使得输出的chunk间数据是有序的,假设前一个chunk中group by keys最大的一条数据是5,当前即将输出的chunk中没有大于5的数据;

3)MergingAggregatedBucketTransform的作用是进行最终的merge aggregating。



ClickHouse内幕(3)基于索引的查询优化



FinishAggregatingInOrderTransform的分组算法如下:

假设有3个stream当前算子会维护3个Chunk,每一次选取在当前的3个Chunk内找到最后一条数据的最小值,比如初始状态最小值是5,然后将3个Chunk内所有小于5的数据一次性取走,如此反复如果一个Chunk被取光,需要从改stream内拉取新的Chunk。



ClickHouse内幕(3)基于索引的查询优化



这种算法保证了每次FinishAggregatingInOrderTransform向下游输出的Chunk的最大值小于下一次Chunk的最小值,便于后续步骤的优化。

3.优化分析

打开optimize_aggregation_in_order后:主要对于第一阶段的聚合步骤进行了优化,从基于HashMap的算法到基于连续相同值的算法。

1.对于计算方面:优化后的算法,减少了Hash计算,但多了判断相等的步骤,在不同数据基数集大小下,各有优劣。

2.由于内存方面:优化前后无差别

3.对于poipeline阻塞:优化前后无差别

四、优化小结

在整个查询计划中Sort、Distinct、聚合这3个算子算子往往是整个查询的瓶颈算子,所以值得对其进行深度优化。ClickHouse通过利用算子输入数据的有序性,优化算子的算法或者选择不同的算法,在计算、内存和pipeline阻塞三个方面均有不同程度的优化。

点赞
收藏
评论区
推荐文章
Mysql索引覆盖
通常情况下,我们创建索引的时候只关注where条件,不过这只是索引优化的一个方向。优秀的索引设计应该纵观整个查询,而不仅仅是where条件部分,还应该关注查询所包含的列。索引确实是一种高效的查找数据方式,但是mysql也可以从索引中直接获取数据,这样就不在需要读数据行了。
Johnny21 Johnny21
3年前
MySQL8.0和MySQL5.7的区别
隐藏索引在8.0中,索引可以隐藏。隐藏索引对性能调试非常重要,索引可以被隐藏和显示,当一个索引隐藏时,不会被查询优化器所使用。隐藏一个索引,然后观察数据库性能是否下降,如果下降,说明该索引有效,否则无效,可以删除。隐藏索引语法:ALTERTABLEtALTERINDEXiINVISIBLE恢复索引语法:AL
Wesley13 Wesley13
3年前
MySQL千万级别优化·中
MySQL千万级别的查询优化手段·中单列索引(假设在v\_record表中存在id列的索引)1、WHERE条件使用​EXPLAINSELECT\FROMv\_recordWHEREid2​结论:利用索引进行回表查询2、SELECT字段使用
Wesley13 Wesley13
3年前
560字带你彻底搞懂:MySQL的索引优化分析
正文一、SQL分析性能下降、SQL慢、执行时间长、等待时间长查询语句写得差索引失效关联查询太多join(设计缺陷)单值索引:在user表中给name属性创建索引,createindexidx\_nameonu
Wesley13 Wesley13
3年前
mysql之索引
一.索引:索引是表的目录,在查找内容之前可以先在目录中查找索引位置,以此快速定位查询数据。对于索引,会保存在额外的文件中1.1.创建一个索引:mysqlcreateindexix_classontb3(class_id);QueryOK,0rowsaffected(0.02sec)
Wesley13 Wesley13
3年前
mysql中的分区表
分区表的意义:当数据量非常大时(表的容量到达GB或者是TB),如果仍然采用索引的方式来优化查询,由于索引本生的消耗以及大量的索引碎片的产生,查询的过程会导致大量的随机I/O的产生,在这种场景下除非可以很好的利用覆盖索引,否则由于在查询的过程中需要根据索引回数据表查询,会导致性能受到很大的影响,这时可以考虑通过分区表的策略来提高查询的性能。
Wesley13 Wesley13
3年前
Mysql索引最佳实践笔记0524
mysql5.7innodb默认存储引擎一、关于索引二、最佳实践三、避坑实践一、关于索引1.索引的作用提高查询效率数据分组、排序避免回表查询优化聚集查询用于多表join关联查询利用唯一性约束、保证数据唯一性innodb行锁实现索引的“
Easter79 Easter79
3年前
TiDB 源码阅读系列文章(七)基于规则的优化
作者:毛康力在TiDB里面,SQL优化的过程可以分为逻辑优化和物理优化两个部分。逻辑优化主要是基于规则的优化,简称RBO(rulebasedoptimization)。物理优化会为逻辑查询计划中的算子选择某个具体的实现,需要用到一些统计信息,决定哪一种方式代价最低,所以是基于代价的优化CBO(costbasedoptimizatio
Easter79 Easter79
3年前
TiDB 源码阅读系列文章(十三)索引范围计算简介
简述在数据库中处理查询请求时,如果可以尽早的将无关数据过滤掉,那么后续的算子就可以少做无用功,提升整个SQL的执行效率。过滤数据最常用的手段是使用索引,TiDB的优化器也会尽量采用索引过滤的方式处理请求,利用索引有序的特点来提升查询效率。比如当查询条件为 a1 时,如果a这一列上有索引,我们就可以利用索引很快的把满足 a
从 SQL 查询优化技巧去看 h2 数据库查询原理 | 京东物流技术团队
本文目标是:了解查询的核心原理,对比SQL查询优化技巧在h2database中的落地实现。前提:为了贴近实际应用,本文CodeInsight基于BTree存储引擎。数据查询核心原理数据库实现查询的原理:遍历表/索引,判断是否满足where筛选条件,添加到结