聊聊ClickHouse MergeTree引擎的固定/自适应索引粒度

京东云开发者
• 阅读 175

前言

我们在刚开始学习ClickHouse的MergeTree引擎时,就会发现建表语句的末尾总会有SETTINGS index_granularity = 8192这句话(其实不写也可以),表示索引粒度为8192。在每个data part中,索引粒度参数的含义有二:

  • 每隔index_granularity行对主键组的数据进行采样,形成稀疏索引,并存储在primary.idx文件中;

  • 每隔index_granularity行对每一列的压缩数据([column].bin)进行采样,形成数据标记,并存储在[column].mrk文件中。

index_granularity、primary.idx、[column].bin/mrk之间的关系可以用ClickHouse之父Alexey Milovidov展示过的一幅简图来表示。

聊聊ClickHouse MergeTree引擎的固定/自适应索引粒度

但是早在ClickHouse 19.11.8版本,社区就引入了自适应(adaptive)索引粒度的特性,并且在之后的版本中都是默认开启的。也就是说,主键索引和数据标记生成的间隔可以不再固定,更加灵活。下面通过简单实例来讲解固定索引粒度和自适应索引粒度之间的不同之处。

固定索引粒度

利用Yandex.Metrica提供的hits_v1测试数据集,创建如下的表。

CREATE TABLE datasets.hits_v1_fixed
(
    `WatchID` UInt64,
    `JavaEnable` UInt8,
    `Title` String,
    -- A lot more columns...
)
ENGINE = MergeTree()
PARTITION BY toYYYYMM(EventDate)
ORDER BY (CounterID, EventDate, intHash32(UserID))
SAMPLE BY intHash32(UserID)
SETTINGS index_granularity = 8192, 
         index_granularity_bytes = 0;  -- Disable adaptive index granularity

注意使用SETTINGS index_granularity_bytes = 0取消自适应索引粒度。将测试数据导入之后,执行OPTIMIZE TABLE语句触发merge,以方便观察索引和标记数据。

来到merge完成后的数据part目录中——笔者这里是201403_1_32_3,并利用od(octal dump)命令观察primary.idx中的内容。注意索引列一共有3列,Counter和intHash32(UserID)都是32位整形,EventDate是16位整形(Date类型存储的是距离1970-01-01的天数)。

[root@ck-test001 201403_1_32_3]# od -An -i -j 0 -N 4 primary.idx 
          57  # Counter[0]
[root@ck-test001 201403_1_32_3]# od -An -d -j 4 -N 2 primary.idx 
 16146        # EventDate[0]
[root@ck-test001 201403_1_32_3]# od -An -i -j 6 -N 4 primary.idx 
    78076527  # intHash32(UserID)[0]
[root@ck-test001 201403_1_32_3]# od -An -i -j 10 -N 4 primary.idx 
        1635  # Counter[1]
[root@ck-test001 201403_1_32_3]# od -An -d -j 14 -N 2 primary.idx 
 16149        # EventDate[1]
[root@ck-test001 201403_1_32_3]# od -An -i -j 16 -N 4 primary.idx 
  1562260480  # intHash32(UserID)[1]
[root@ck-test001 201403_1_32_3]# od -An -i -j 20 -N 4 primary.idx 
        3266  # Counter[2]
[root@ck-test001 201403_1_32_3]# od -An -d -j 24 -N 2 primary.idx 
 16148        # EventDate[2]
[root@ck-test001 201403_1_32_3]# od -An -i -j 26 -N 4 primary.idx 
   490736209  # intHash32(UserID)[2]

能够看出ORDER BY的第一关键字Counter确实是递增的,但是不足以体现出index_granularity的影响。因此再观察一下标记文件的内容,以8位整形的Age列为例,比较简单。

[root@ck-test001 201403_1_32_3]# od -An -l -j 0 -N 320 Age.mrk
                    0                    0
                    0                 8192
                    0                16384
                    0                24576
                    0                32768
                    0                40960
                    0                49152
                    0                57344
                19423                    0
                19423                 8192
                19423                16384
                19423                24576
                19423                32768
                19423                40960
                19423                49152
                19423                57344
                45658                    0
                45658                 8192
                45658                16384
                45658                24576

上面打印出了两列数据,表示被选为标记的行的两个属性:第一个属性为该行所处的压缩数据块在对应bin文件中的起始偏移量,第二个属性为该行在数据块解压后,在块内部所处的偏移量,单位均为字节。由于一条Age数据在解压的情况下正好占用1字节,所以能够证明数据标记是按照固定index_granularity的规则生成的。

自适应索引粒度

创建同样结构的表,写入相同的测试数据,但是将index_granularity_bytes设为1MB(为了方便看出差异而已,默认值是10MB),以启用自适应索引粒度。

CREATE TABLE datasets.hits_v1_adaptive
(
    `WatchID` UInt64,
    `JavaEnable` UInt8,
    `Title` String,
    -- A lot more columns...
)
ENGINE = MergeTree()
PARTITION BY toYYYYMM(EventDate)
ORDER BY (CounterID, EventDate, intHash32(UserID))
SAMPLE BY intHash32(UserID)
SETTINGS index_granularity = 8192, 
         index_granularity_bytes = 1048576;  -- Enable adaptive index granularity

index_granularity_bytes表示每隔表中数据的大小来生成索引和标记,且与index_granularity共同作用,只要满足两个条件之一即生成。

触发merge之后,观察primary.idx的数据。

[root@ck-test001 201403_1_32_3]# od -An -i -j 0 -N 4 primary.idx 
          57  # Counter[0]
[root@ck-test001 201403_1_32_3]# od -An -d -j 4 -N 2 primary.idx 
 16146        # EventDate[0]
[root@ck-test001 201403_1_32_3]# od -An -i -j 6 -N 4 primary.idx 
    78076527  # intHash32(UserID)[0]
[root@ck-test001 201403_1_32_3]# od -An -i -j 10 -N 4 primary.idx
          61  # Counter[1]
[root@ck-test001 201403_1_32_3]# od -An -d -j 14 -N 2 primary.idx
 16151        # EventDate[1]
[root@ck-test001 201403_1_32_3]# od -An -i -j 16 -N 4 primary.idx
  1579769176  # intHash32(UserID)[1]
[root@ck-test001 201403_1_32_3]# od -An -i -j 20 -N 4 primary.idx
          63  # Counter[2]
[root@ck-test001 201403_1_32_3]# od -An -d -j 24 -N 2 primary.idx
 16148        # EventDate[2]
[root@ck-test001 201403_1_32_3]# od -An -i -j 26 -N 4 primary.idx
  2037061113  # intHash32(UserID)[2]

通过Counter列的数据可见,主键索引明显地变密集了,说明index_granularity_bytes的设定生效了。接下来仍然以Age列为例观察标记文件,注意文件扩展名变成了mrk2,说明启用了自适应索引粒度。

[root@ck-test001 201403_1_32_3]# od -An -l -j 0 -N 2048 --width=24 Age.mrk2
                    0                    0                 1120
                    0                 1120                 1120
                    0                 2240                 1120
                    0                 3360                 1120
                    0                 4480                 1120
                    0                 5600                 1120
                    0                 6720                 1120
                    0                 7840                  352
                    0                 8192                 1111
                    0                 9303                 1111
                    0                10414                 1111
                    0                11525                 1111
                    0                12636                 1111
                    0                13747                 1111
                    0                14858                 1111
                    0                15969                  415
                    0                16384                 1096
# 略去一些
                17694                    0                 1102
                17694                 1102                 1102
                17694                 2204                 1102
                17694                 3306                 1102
                17694                 4408                 1102
                17694                 5510                 1102
                17694                 6612                  956
                17694                 7568                 1104
# ......

mrk2文件被格式化成了3列,前两列的含义与mrk文件相同,而第三列的含义则是两个标记之间相隔的行数。可以观察到,每隔1100行左右就会生成一个标记(同时也说明该表内1MB的数据大约包含1100行)。同时,在偏移量计数达到8192、16384等8192的倍数时(即经过了index_granularity的倍数行),同样也会生成标记,证明两个参数是协同生效的。

最后一个问题:ClickHouse为什么要设计自适应索引粒度呢?

当一行的数据量比较大时(比如达到了1kB甚至数kB),单纯按照固定索引粒度会造成每个“颗粒”(granule)的数据量膨胀,拖累读写性能。有了自适应索引粒度之后,每个granule的数据量可以被控制在合理的范围内,官方给定的默认值10MB在大多数情况下都不需要更改。

作者:京东物流 康琪

来源:京东云开发者社区 自猿其说 Tech 转载请注明来源

点赞
收藏
评论区
推荐文章
Stella981 Stella981
3年前
Kylin、Druid、ClickHouse 核心技术对比
文章作者:吴建超内容来源:jackywoo.cn导读:Kylin、Druid、ClickHouse是目前主流的OLAP引擎,本文尝试从数据模型和索引结构两个角度,分析这几个引擎的核心技术,并做简单对比。在阅读本文之前希望能对Kylin、Druid、ClickHouse有所理解。01Kylin数据模型
Wesley13 Wesley13
3年前
MySQL表介绍
MySQLInnoDB表介绍一、索引组织表在InnoDB引擎中,表都是根据主键顺序存放的。这种存储方式称为索引组织表,在InnoDB引擎中,每张表都有逐渐。如果没有显示定义主键,则引擎会按照以下方式选择或创建主键。(1)、判断表是否有非空唯一索引,如果有,则该字段为主键。如果有多个非空唯一索引,则选择第一个定义的非空索引字段作为
Wesley13 Wesley13
3年前
MySQL索引的索引长度问题
MySQL的每个单表中所创建的索引长度是有限制的,且对不同存储引擎下的表有不同的限制。在MyISAM表中,创建组合索引时,创建的索引长度不能超过1000,注意这里索引的长度的计算是根据表字段设定的长度来标量的,例如:createtabletest(idint,name1varchar(300),name2varchar(300),nam
Wesley13 Wesley13
3年前
mysql面试题
MySQL面试索引相关1.什么是索引?索引是一种数据结构,可以帮助我们快速的进行数据的查找.1.索引是个什么样的数据结构呢?索引的数据结构和具体存储引擎的实现有关,在MySQL中使用较多的索引有Hash索引,B树索引等,而我们经常使用的InnoDB存储引擎的默认索引实现为:B树索引.
Wesley13 Wesley13
3年前
MYSQL 索引类型
  在MYSQL中,索引是在引擎层中而不是服务器层实现的。所以并没有统一的索引标准:不同存储引擎的索引的工作方式并不一样,也不是所有的存储引擎都支持所有类型的索引。即使多个存储引擎支持同一种类型的索引,其底层的实现也可能不同(1)BTree索引    如果没有特别指明类型的话,那么就代指为BTree引擎,它使用BTree数据结构来
Wesley13 Wesley13
3年前
mysql之索引
一.索引:索引是表的目录,在查找内容之前可以先在目录中查找索引位置,以此快速定位查询数据。对于索引,会保存在额外的文件中1.1.创建一个索引:mysqlcreateindexix_classontb3(class_id);QueryOK,0rowsaffected(0.02sec)
Stella981 Stella981
3年前
ClickHouse MergeTree引擎的简单介绍
1.介绍Clickhouse中最强大的表引擎当属MergeTree(合并树)引擎及该系列(MergeTree)中的其他引擎。MergeTree允许依据主键和日期创建索引,并进行实时的数据更新操作。MergeTree是ClickHouse里最为先进的表引擎。请注意不要将MergeTree跟Merge引擎混淆!!!Mer
Wesley13 Wesley13
3年前
mysql索引总结
上文(https://my.oschina.net/jayqqaa12/blog/3162088"上文")中我们主要介绍了sql语句在server层的执行过程我们再来分析一下具体的语句在引擎层的执行步骤,CRUD的操作都跟索引相关,我们先了解一下索引索引索引的出现其实就是为了提高数据查询的效率,就像书的目录数据结
Stella981 Stella981
3年前
ElasticSearch学习笔记(二)
了解以下几个概念1\.索引index简单的可以理解为关系型数据库的中库或者表。一个elasticsearch集群中可以有多个索引。2\.文档docment可以理解为表中的行数据,表示一个对象。每个文档有一个唯一标识\_id,相当于关系数据库的主键。一个索引中可以有多个结构相同的文档。3\.域
京东云开发者 京东云开发者
4个月前
ClickHouse内幕(3)基于索引的查询优化
ClickHouse索引采用唯一聚簇索引的方式,即Part内数据按照orderbykeys有序,在整个查询计划中,如果算子能够有效利用输入数据的有序性,对算子的执行性能将有巨大的提升。本文讨论ClickHouse基于索引的查询算子优化方式。在整个查询计划中