一、MergeTree
1、创建与存储
- MergeTree 在写入一批数据时,数据总会以数据片段的形式写入磁盘,且数据片段不可修改。
- 为了避免片段过多,ClickHouse会通过后台线程,定期合并这些数据片段,属于相同分区的数据片段被合成一个新的片段。
- 这些数据片段不断合并的特点,也正是合并树名称的由来。
1.1 创建方式
语法:
CREATE TABLE [IF NOT EXISTS] [db.]table_name [ON CLUSTER cluster]
(
name1 [type1] [DEFAULT|MATERIALIZED|ALIAS expr1] [TTL expr1],
name2 [type2] [DEFAULT|MATERIALIZED|ALIAS expr2] [TTL expr2],
...
INDEX index_name1 expr1 TYPE type1(...) GRANULARITY value1,
INDEX index_name2 expr2 TYPE type2(...) GRANULARITY value2
) ENGINE = MergeTree()
ORDER BY expr
[PARTITION BY expr]
[PRIMARY KEY expr]
[SAMPLE BY expr]
[TTL expr [DELETE|TO DISK 'xxx'|TO VOLUME 'xxx'], ...]
[SETTINGS name=value, ...]
配置选项:
- ORDER BY [必填]:排序键,用于指定在一个数据片段内,数据以何种标准排序。
- 如果没使用 PARTITION BY 指定主键,默认会使用排序键作为主键。
- 排序键设置单列,ORDER BY xxx。排序键设置多列,ORDER BY (xxx, yyy)。
- PARTITION BY [选填]:分区键,用于指定表数据以何种标准进行分区。
- 如果不声明分区键,则ClickHouse会生成一个名为 all 的分区。
- PRIMARY KEY [选填]:主键,声明后会依据主键字段生成一级索引,用于加速表查询。
- 默认情况下,主键与排序键相同。
- 在一般情况下,在单个数据片段内,数据与一级索引以相同的规则生序排列。
- 与其他数据库不同,MergeTree 主键允许存在重复数据(ReplacingMergeTree可以去重)。
- SAMPLE BY [选填]:抽样表达式,用于声明数据以何种标准进行采样。
- 如果使用抽样表达式,主键中必须包含这个表达式。
- 例如:
ENGINE = MergeTree() ORDER BY (a, b, intHash32(UserID) SAMPLE BY intHash32(UserID)
- TTL [选填]:指定列的存储周期或定义数据片段在硬盘和卷上的移动逻辑的规则列表。
- 表达式中必须存在至少一个 Date 或 DateTime 类型的列,比如:
TTL date + INTERVAl 1 DAY
- DELETE 是当指定列到达指定时间后删除过期的数据。默认的规则是 DELETE。
- TO DISK ‘xxx’|TO VOLUME ‘xxx’ 是将数据片段移动到指定的 磁盘 或 卷 。
- 可以指定多个规则,但最多只能有一个
DELETE
规则。
- SETTINGS [选填]:控制 MergeTree 行为的额外参数。
- index_granularity:索引粒度。默认值为8192,表示每间隔8192行数据才生成一条索引。
- index_granularity_bytes:索引粒度,默认值10MB,表示写入的数据存储大小到了10MB就会生成一条索引。
- use_minimalistic_part_header_in_zookeeper:ZooKeeper 中数据片段存储方式。一般设置为1,这样ZooKeeper 会存储更少的数据。
1.2 存储格式
MergeTree 表引擎中的数据是拥有物理存储的,数据会按照分区目录的形式保存到磁盘上。
一张数据表的完整物理结构分为3个层级,分别为数据表目录、分区目录以及各分区下具体的数据文件。
- partition:分区目录。属于相同分区的数据,最终会被合并到同一个分区目录,而不同分区的数据,永远不会被合并在一起。
- checksums.txt:校验文件,二进制格式存储。它保存了余下各类文件(primary.idx、count.txt等)的size大小及size的哈希值,用于快速校验文件的完整性和正确性。
- columns.txt:列字段信息文件,使用明文格式存储。
- count.txt:计数文件,使用明文格式存储。用于记录当前数据分区目录下数据的总行数。
- primary.idx:一级索引文件,使用二进制格式存储。用于存放稀疏索引。一级索引是通过 ORDER BY 或 PRIMARY KEY 指定。
- [Column].bin:数据文件,使用压缩格式存储,默认为LZ4压缩格式,用于存储某一列的数据。每一列字段拥有独立的.bin数据文件,文件名以列字段名称命名。
- [Column].mrk:列字段标记文件,使用二进制格式存储。标记文件保存了.bin文件中数据的偏移量信息。
- MergeTree通过标记文件建立了primary.idx稀疏索引与.bin数据文件之间的映射关系。
- 首先通过稀疏索引(primary.idx)找到对应数据的偏移量信息(.mrk),再通过偏移量直接从.bin文件中读取数据。
- 每个列都会拥有各自的.mrk标记文件。
- [Column].mrk2:如果使用了自适应大小的索引间隔,则标记文件会以.mrk2命名。工作原理和.mrk标记文件相同。
- partition.dat与minmax_[Column].idx:分区键生成的索引文件,都是二进制格式存储。
- partition.dat 用于保存当前分区下分区表达式最终生成的值。
- minmax 索引用于记录当前分区下分区字段对应原始数据的最小和最大值。
- skp_idx[Column].idx 与 spk_idx[Column].mrk:如果在建表语句中声明了二级索引,会生成相应的二级索引与标记文件,都是二进制存储。
2、数据分区
2.1 数据分区规则
- MergeTree 数据分区的规则由分区ID决定,而具体到每个数据分区所对应的ID,则是由分区键的取值决定的。
- 针对取值数据类型的不同,分区ID的生成逻辑目前拥有四种规则:
- 不指定分区键:
- 分区ID默认取名为all,所有的数据都会被写入这个all分区。
- 使用整型:
- 分区键取值是整型,且无法转换为日期类型YYYYMMDD格式,则直接以整型的字符形式作为分区ID。
- 使用日期类型:
- 分区键取值是日期类型,或者能转换为日期类型YYYYMMDD格式的整型,则按照YYYYMMDD进行格式化后的字符形式作为分区ID。
- 使用其他类型:
- 如String、Float等,则通过128位Hash算法取Hash值作为分区ID。
2.2 分区目录命名
完整分区目录的命名公式:PartitionID_MinBlockNum_MaxBlockNum_Level
- PartitionID:分区ID
- MinBlockNum和MaxBlockNum:最小数据块编号与最大数据块编号。
- Level:合并的层级,可以理解为某个分区被合并过的次数。
2.3 分区目录合并
MergeTree 与其他数据库不同的是,每一批数据的写入,MergeTree 都会生成一批新的分区目录。也就是说,对于同一个分区而言,也会存在多个分区目录的情况。
在之后的某个时刻(写入后的10~15分钟,也可以手动执行 optimize table xxxx final
语句),ClickHouse会通过后台任务再将属于相同分区的多个目录合并成一个新的目录。
已经存在的旧分区目录并不会立即被删除,而是在之后的某个时刻通过后台任务删除(默认8分钟)。
新目录名称的合并方式遵循的规则:
- MinBlockNum:取同一分区内所有目录中最小的 MinBlockNum 值。
- MaxBlockNum:取同一分区内所有目录中最大的 MaxBlockNum 值。
- Level:取同一分区内最大的 Level 值并加1。
名称变化过程:
分区目录创建、合并、删除的过程:
3、一级索引
MergeTree 的主键使用 PRIMARY KEY 定义,待主键定义之后,MergeTree 会依据 index_granularity 间隔(默认8192行),为数据表生成一级索引并保存至 primary.idx 文件内,索引数据按照 PRIMARY KEY 排序。
3.1 稀疏索引
primary.idx 文件内的一级索引采用稀疏索引实现。
- 稠密索引中每一行索引标记都会对应到一行具体到数据记录。
- 稀疏索引中每一行索引标记对应的是一段数据,而不是一行。
稀疏索引的优势是仅用少量的索引标记就能够记录大量数据的区间位置信息,且数据量越大优势越明显。由于稀疏索引占有空间小,所以primaray.idx内的索引数据常驻内存,取用速度自然极快。
索引文件查看命令:od -An -i -w4 primary.idx
3.2 索引粒度
索引粒度就如同标尺一般,会丈量整个数据的长度,并依照刻度对数据进行标注,最终将数据标记成多个间隔的小段。
3.3 索引规则
由于是稀疏索引,所以 MergeTree 需要间隔 index_granularity 行数据才会生成一条索引记录,其索引值会依据声明的主键字段获取。
- 单主键
-
- 最终索引数据是5716353266…
- 多主键
3.4 索引查询过程
- MarkRange
- MarkRange 在 ClickHouse 中是用于定义标记区间的对象。
- MergeTree 按照 index_granularity 的间隔粒度,将一段完整的数据划分成多个小的间隔数据段,一个具体的数据段即是一个 MarkRange。
- MarkRange 与索引编号对应,使用 start 和 end 两个属性表示其区间范围。通过与start 及 end 对应的索引编号的取值,即能够得到它所对应的数值区间。而数值区间表示了此 MarkRange 包含的数据范围。
- 查询步骤:
- 1、生成查询条件区间:将查询条件转换为条件区间。
- 2、递归交集判断:以递归的形式,依次对 MarkRange 的数值区间与条件区间做交集判断。
- 如果不存在交集,则直接通过减枝算法优化此整段MarkRange。
- 如果存在交集,且 MarkRange 步长大于8(end-start),则将此区间进一步拆分成 8 个子区间,并重复此规则,继续做递归交集判断。
- 如果存在交集,且 MarkRange 不可再分解(步长小于8),则记录 MarkRange 并返回。
- 3、合并MarkRange区间:将最终匹配的 MarkRange 聚在一起,合并它们的范围。
4、数据存储
4.1 列式存储
- 在 MergeTree 中,数据按列存储。每个列字段都拥有独立的一个.bin文件。
- 数据文件以分区目录的形式被组织存放,所以在.bin文件中只会保存当前分区片段内的这一部分数据。
- 优势:
- 存储方式:
- 首先。数据是经过压缩的,目前支持LZ4、ZSTD、Multiple和Delta几种算法,默认使用LZ4算法;
- 其次,数据会事先依照 ORDER BY 的声明排序;
- 最后,数据是以压缩数据块的形式被组织并写入.bin文件中。
4.2 数据压缩
一个压缩数据块由头信息和压缩数据两部分组成。
- 头信息固定使用9位字节表示,具体由1个UInt8(1字节) 整型和2个UInt32(4字节)整型组成。分别代表使用的压缩算法类型、压缩后的数据大小和压缩前的数据大小。
- bin压缩文件是由多个压缩数据块组成的。
- 每个压缩数据块的体积,按照其压缩前的数据字节大小,都被严格控制在64KB~1MB。
-
数据写入过程:
- MergeTree在数据具体的写入过程中,会依照索引粒度(默认情况下,每次取8192行),按批次获取数据并进行处理。
- 单个批次数据 size < 64KB:继续获取下一批数据,直到累积到size >= 64KB,生成一个压缩数据块。
- 单个批次数据 64KB <= size <= 1MB:直接生成一个压缩数据块。
- 单个批次数据 size > 1MB:首先按照 1MB 大小截断并生成一个压缩数据块。剩余数据继续依照上述规则执行。
优势:
- 1、虽然数据被压缩后能够有效减少数据大小,降低存储空间并加速数据传输效率,但数据的压缩和解压动作,其本身也会带来额外的性能损耗。所以需要控制被压缩数据的大小,以求在性能损耗和压缩率之间寻求一种平衡。
- 2、其二,在具体读取某一列数据时(.bin文件),首先需要将压缩数据加载到内存并解压,这样才能进行后续的数据处理。通过压缩数据块,可以在不读取整个.bin文件的情况下将读取粒度降低到压缩数据块级别,从而进一步缩小数据读取的范围。
5、数据标记
5.1 生成规则
数据标记作为衔接一级索引和数据的桥梁,其像极了做过标记小抄的书签,而且每个章节都拥有各自的书签。
数据标记和索引区间是对齐的。
为了能够与数据衔接,[Column].mrk数据标记文件也与[Column].bin文件一一对应,用于记录数据在.bin文件中的偏移量信息。
一行标记数据使用一个元组表示,元组内包含两个整型数值的偏移量信息。
- 第一个整数:表示在.bin压缩文件中,压缩数据块的起始偏移量。
- 第二个整数:表示该数据压缩块解压后,其未压缩数据的起始偏移量。
查看标记文件的命令:
od -An -l xxx.mrk
5.2 工作方式
MergeTree 在读取数据时,必须通过标记数据的位置信息才能够找到所需要的数据。整个查找过程大致可以分为读取压缩数据块和读取数据两个步骤。
- 读取压缩数据块:
- 在查询某一列数据时,MergeTree无须一次性加载整个.bin文件,而是根据标记文件中所保存的压缩文件中的偏移量(第一个整数)去加载特定的压缩数据块。
- 读取数据:
- 在读取解压后的数据时, MergeTree 并不需要一次性扫描整段解压数据,而是根据标记文件中保存的解压数据块中的偏移量(第二个整数)去加载特定的一小段。
6、数据标记和数据压缩
- 由于压缩数据块的划分,与一个间隔(index_granularity)内的数据大小相关,每个压缩数据块的体积被严格控制在64KB~1MB。
- 一个间隔 (index_granularity) 的数据,只会产生一行数据标记。
- 根据一个间隔内数据的实际字节大小,数据标记和压缩数据块之间会产生三种不同的对应关系。
6.1 多对一
当一个间隔 (index_granularity) 内的数据未压缩大小 size < 64KB 时,则多个数据标记对应一个压缩数据块。
6.2 一对一
当一个间隔 (index_granularity) 内的数据未压缩大小 64KB <= size <= 1MB 时,则一个数据标记对应一个压缩数据块。
6.2 一对多
当一个间隔 (index_granularity) 内的数据未压缩大小 size >1MB 时,则一个数据标记对应多个压缩数据块。
7、数据读写流程
7.1 写入数据
数据写入的第一步是生成分区目录,伴随着每一批数据的写入,都会生成一个新的分区目录。在后续的某一时刻,属于相同分区的目录会依照规则合并到一起;接着,按照 index_granularity 索引粒度,会分别生成 primary.idx 一级索引、每一个列字段的 .mrk 数据标记和 .bin 压缩数据文件。
7.2 写入数据
数据查询的本质,可以看作一个不断减小数据范围的过程。在最理想的情况下,MergeTree 首先可以依次借助分区索引、一级索引和二级索引,将数据扫描缩至最小。然后再借助数据标记,将需要解压与计算的数据范围缩至最小。
二、MergeTree 家族
1、MergeTree
1.1 数据TTL
TTL 即 Time To Live,顾名思义,它表示数据的存活时间。在 MergeTree 中,可以为某个列字段或整张表设置 TTL。
- 当时间到达时,如果是列字段级别的 TTL,则会删除这一列数据。
- 如果是表级别的 TTL,则会删除整张表的数据。
- 如果同时设置了列级别和表级别的 TTL,则会以先到期的那个为主。
- ClickHouse 目前没有提供取消 TTL 的方法。
设置TTL:
- INTERVAL 完整的操作包括 SECOND、MINUTE、HOUR、DAY、WEEK、MONTH、QUARTER 和 YEAR。
- 列级别设置 TTL
CREATE TABLE ttl_table_v1 (
id String,
create_time DateTime,
code String TTL create_time + INTERVAL 10 SECOND
)
ENGINE = MergeTree
ORDER by id
CREATE TABLE ttl_table_v2 (
id String,
create_time DateTime,
code String TTL create_time + INTERVAL 10 SECOND
)
ENGINE = MergeTree
PARTITION BY toYYYYMM(create_time)
ORDER by create_time
TTL create_time + INTERVAL 1 DAY
- TTL 的运行机制
- 如果一张 MergeTree 表被设置了 TTL 表达式,那么在写入数据时,会以数据分区为单位,在每个分区目录内生成一个名为 ttl.txt 的文件。
- ttl.txt 文件中通过一串JSON配置保存了TTL的相关信息
{"columns":[{"name":"code","min":1557478860,"max":1557651660}],"table":{"min":1557565200,"max":1557738000}}
1.2 多路径存储策略
19.15 版本之前,MergeTree 只支持单路径存储,所有的数据都会被写入 config.xml 配置中path 指定的路径下,即使服务器挂载了多块磁盘,也无法有效利用这些存储空间。
19.15 版本开始,MergeTree 实现了自定义存储策略的功能,支持以数据分区为最小移动单元,将分区目录写入多块磁盘目录。
存储策略:
- 默认策略:
- MergeTree 原本的存储策略,无须任何配置,所有分区会自动保存到 config.xml 配置中 path 指定的路径下。
- JBOD策略:
- 这种策略适合服务器挂载了多块磁盘,但没有做RAID的场景。
- JBOD 是一种轮询策略,每执行一次 INSERT 或者 MERGE,所产生的新分区会轮询写入各个磁盘。
- HOT/COLD策略:
- 这种策略适合服务器挂载了不同类型磁盘的场景。
- 将存储磁盘分为 HOT 与 COLD 两类区域。
- HOT 区域使用 SSD 这类高性能存储媒介,注重存取性能。
- COLD 区域则使用 HDD 这类高容量存储媒介,注重存取经济性。
- 数据在写入 MergeTree 之初,首先会在 HOT 区域创建分区目录用于保存数据,当分区数据大小累积到阈值时,数据会自行移动到 COLD 区域。
配置方式:
- 存储配置需要预先定义在 config.xml 配置文件中,由 storage_configuration 标签表示。
- 在 storage_configuration 之下又分为 disks 和 policies 两组标签,分别表示磁盘与存储策略。
<storage_configuration>
<disks>
<disk_name_a>
<path>/chbase/datapath>
<keep_free_space_bytes>1073741824keep_free_space_bytes>
disk_name_a>
<disk_name_b>
<path>…path>
<keep_free_space_bytes>...keep_free_space_bytes>
disk_name_b>
disks>
<policies>
<default_jbod>
<volumes>
<jbod>
<disk>disk_name_adisk>
<disk>disk_name_bdisk>
jbod>
volumes>
default_jbod>
policies>
storage_configuration>
2、ReplacingMergeTree
MergeTree 拥有主键,但是它的主键却没有唯一键的约束。这意味着即便多行数据的主键相同,它们还是能够被正常写入。
ReplacingMergeTree 就是在这种背景下为了数据去重而设计的,它能够在合并分区时删除重复的数据。
ReplacingMergeTree 是以分区为单位删除重复数据的。
- 只有在相同的数据分区内重复的数据才可以被删除,而不同数据分区之间的重复数据依然不能删除。
- 如果要求主键完全不重复,那么这种表就不能分区。
ReplacingMergeTree 的可选参数:
ENGINE = ReplacingMergeTree([ver])
ver 表示版本列,类型为 UInt*, Date 或 DateTime。可选参数。
在数据合并时,ReplacingMergeTree 从相同排序键的行中选择一行留下:
- 如果 ver 列未指定,保留最后写入的一条。
- 如果 ver 列已指定,保留 ver 值最大的版本。
3、SummingMergeTree
用户只需查询数据的汇总结果,不关心明细数据,并且数据的汇总条件是预先明确的,而 SummingMergeTree 就是能够在合并分区时,按照预先定义的条件聚合汇总数据,将同一分组下的多行数据汇总合并成一行。
使用方式:
- 用 ORDER BY 排序键作为聚合数据的条件key。
- 只有在合并分区时才会触发汇总的逻辑。
- 以数据分区为单位来聚会数据。当分区合并时,同一数据分区内聚合key相同的数据会被合并汇总,而不同分区之间的数据则不会被汇总。
- 如果在定义引擎时指定了 columns 汇总列,则 SUM 汇总这些列字段;如果未指定,则聚合所有非主键的数值类型字段。
- 在数据汇总时,同一分区内,相同聚合key的多行数据会合并成一行。其中,汇总字段会进行sum计算;对于那些非汇总字段,则会使用第一行数据的取值。