Clickhouse表引擎

最新推荐文章于 2024-06-20 18:25:34 发布
最新推荐文章于 2024-06-20 18:25:34 发布
阅读量99 收藏
点赞数
分类专栏： ClickHouse 文章标签： clickhouse
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/weixin_64910075/article/details/132804993
版权

4.0 表引擎的分类

1、日志

2、内存

3、合并树

4、其他

4.1 表引擎的使用

表引擎是 ClickHouse 的一大特色。可以说， 表引擎决定了如何存储表的数据。包括：

➢ 数据的存储方式和位置，写到哪里以及从哪里读取数据。

➢ 支持哪些查询以及如何支持。

➢ 并发数据访问。

➢ 索引的使用（如果存在）。

➢ 是否可以执行多线程请求。

➢ 数据复制参数。

表引擎的使用方式就是必须显式在创建表时定义该表使用的引擎，以及引擎使用的相关

参数。

特别注意：引擎的名称大小写敏感

4.2 TinyLog

以列文件的形式保存在磁盘上，不支持索引，没有并发控制。一般保存少量数据的小表，

生产环境上作用有限。可以用于平时练习测试用。

如：

create table t_tinylog ( id String, name String) engine=TinyLog;

4.3 Memory

内存引擎，数据以未压缩的原始形式直接保存在内存当中，服务器重启数据就会消失。 读写操作不会相互阻塞，不支持索引。简单查询下有非常非常高的性能表现（超过 10G/s）。

一般用到它的地方不多，除了用来测试，就是在需要非常高的性能，同时数据量又不太

大（上限大概 1 亿行）的场景

4.4 MergeTree

ClickHouse 中最强大的表引擎当属 MergeTree（合并树）引擎及该系列（*MergeTree）中的其他引擎，支持索引和分区，地位可以相当于 innodb 之于 Mysql。而且基于 MergeTree， 还衍生除了很多小弟，也是非常有特色的引擎.

1）建表语句

create table t_order_mt(
 id UInt32,
 sku_id String,
 total_amount Decimal(16,2),
 create_time Datetime
) engine =MergeTree
 partition by toYYYYMMDD(create_time)
 primary key (id)
 order by (id,sku_id);

2）插入数据

insert into t_order_mt values
(101,'sku_001',1000.00,'2020-06-01 12:00:00') ,
(102,'sku_002',2000.00,'2020-06-01 11:00:00'),
(102,'sku_004',2500.00,'2020-06-01 12:00:00'),
(102,'sku_002',2000.00,'2020-06-01 13:00:00'),
(102,'sku_002',12000.00,'2020-06-01 13:00:00'),
(102,'sku_002',600.00,'2020-06-02 12:00:00');

MergeTree 其实还有很多参数(绝大多数用默认值即可)，但是三个参数是更加重要的， 也涉及了关于 MergeTree 的很多概念。

4.4.1 partition by 分区(可选)

1）作用

学过 hive 的应该都不陌生，分区的目的主要是降低扫描的范围，优化查询速度

2）如果不填

只会使用一个分区。

3）分区目录

MergeTree 是以列文件+索引文件+表定义文件组成的，但是如果设定了分区那么这些文件就会保存到不同的分区目录中。

4）并行

分区后，面对涉及跨分区的查询统计，ClickHouse 会以分区为单位并行处理。

5）数据写入与分区合并

任何一个批次的数据写入都会产生一个临时分区，不会纳入任何一个已有的分区。写入 后的某个时刻（大概 10-15 分钟后），ClickHouse 会自动执行合并操作（等不及也可以手动 通过 optimize 执行），把临时分区的数据，合并到已有分区中。

optimize table xxxx final;
6）例如

再次执行上面的插入操作

insert into t_order_mt values
(101,'sku_001',1000.00,'2020-06-01 12:00:00') ,
(102,'sku_002',2000.00,'2020-06-01 11:00:00'),
(102,'sku_004',2500.00,'2020-06-01 12:00:00'),
(102,'sku_002',2000.00,'2020-06-01 13:00:00'),
(102,'sku_002',12000.00,'2020-06-01 13:00:00'),
(102,'sku_002',600.00,'2020-06-02 12:00:00');

查看数据并没有纳入任何分区

手动 optimize 之后

hadoop102 :) optimize table t_order_mt final;

再次查询

4.4.2 primary key 主键(可选)

ClickHouse 中的主键，和其他数据库不太一样，它只提供了数据的一级索引，但是却不是唯一约束。这就意味着是可以存在相同 primary key 的数据的。

主键的设定主要依据是查询语句中的 where 条件。

根据条件通过对主键进行某种形式的二分查找，能够定位到对应的 index granularity,避免了全表扫描。

index granularity： 直接翻译的话就是索引粒度，指在稀疏索引中两个相邻索引对应数据的间隔。ClickHouse 中的 MergeTree 默认是 8192。官方不建议修改这个值，除非该列存在大量重复值，比如在一个分区中几万行才有一个不同数据。

稀疏索引:

稀疏索引的好处就是可以用很少的索引数据，定位更多的数据，代价就是只能定位到索引粒度的第一行，然后再进行进行一点扫描。

4.4.3 order by（必选）

order by 设定了分区内的数据按照哪些字段顺序进行有序保存。

order by 是 MergeTree 中唯一一个必填项，甚至比 primary key 还重要，因为当用户不设置主键的情况，很多处理会依照 order by 的字段进行处理（比如后面会讲的去重和汇总）。

要求：主键必须是 order by 字段的前缀字段。

比如 order by 字段是 (id,sku_id) 那么主键必须是 id 或者(id,sku_id)

4.4.4 二级索引

目前在 ClickHouse 的官网上二级索引的功能在 v20.1.2.4 之前是被标注为实验性的，在这个版本之后默认是开启的。

1）老版本使用二级索引前需要增加设置

是否允许使用实验性的二级索引（v20.1.2.4 开始，这个参数已被删除，默认开启）

set allow_experimental_data_skipping_indices=1;
2）创建测试表
create table t_order_mt2(
 id UInt32,
 sku_id String,
 total_amount Decimal(16,2),
 create_time Datetime,
INDEX a total_amount TYPE minmax GRANULARITY 5
) engine =MergeTree
 partition by toYYYYMMDD(create_time)
 primary key (id)
 order by (id, sku_id);

其中 GRANULARITY N 是设定二级索引对于一级索引粒度的粒度

3）插入数据
insert into t_order_mt2 values
(101,'sku_001',1000.00,'2020-06-01 12:00:00') ,
(102,'sku_002',2000.00,'2020-06-01 11:00:00'),
(102,'sku_004',2500.00,'2020-06-01 12:00:00'),
(102,'sku_002',2000.00,'2020-06-01 13:00:00'),
(102,'sku_002',12000.00,'2020-06-01 13:00:00'),
(102,'sku_002',600.00,'2020-06-02 12:00:00');
4）对比效果

那么在使用下面语句进行测试，可以看出二级索引能够为非主键字段的查询发挥作用。

[atguigu@hadoop102 lib]$ clickhouse-client --send_logs_level=trace <<< 'select 
* from t_order_mt2 where total_amount > toDecimal32(900., 2)';

4.4.5 数据 TTL

TTL 即 Time To Live，MergeTree 提供了可以管理数据表或者列的生命周期的功能。

1）列级别 TTL
（1）创建测试表
create table t_order_mt3(
 id UInt32,
 sku_id String,
 total_amount Decimal(16,2) TTL create_time+interval 10 SECOND,
 create_time Datetime 
) engine =MergeTree
partition by toYYYYMMDD(create_time)
 primary key (id)
 order by (id, sku_id);
（2）插入数据（注意：根据实际时间改变）
insert into t_order_mt3 values
(106,'sku_001',1000.00,'2020-06-12 22:52:30'),
(107,'sku_002',2000.00,'2020-06-12 22:52:30'),
(110,'sku_003',600.00,'2020-06-13 12:00:00');
（3）手动合并，查看效果到期后，指定的字段数据归 0

2）表级 TTL

下面的这条语句是数据会在 create_time 之后 10 秒丢失

alter table t_order_mt3 MODIFY TTL create_time + INTERVAL 10 SECOND;

涉及判断的字段必须是 Date 或者 Datetime 类型，推荐使用分区的日期字段。

能够使用的时间周期：

- SECOND

- MINUTE

- HOUR

- DAY

- WEEK

- MONTH

- QUARTER

- YEAR

4.5 ReplacingMergeTree

ReplacingMergeTree 是 MergeTree 的一个变种，它存储特性完全继MergeTree，只是多了一个去重的功能。尽管 MergeTree 可以设置主键，但是 primary key 其实没有唯一约束 的功能。如果你想处理掉重复的数据，可以借助这个 ReplacingMergeTree。

1）去重时机

数据的去重只会在合并的过程中出现。合并会在未知的时间在后台进行，所以你无法预先作出计划。有一些数据可能仍未被处理。

2）去重范围

如果表经过了分区，去重只会在分区内部进行去重，不能执行跨分区的去重。 所以 ReplacingMergeTree 能力有限， ReplacingMergeTree 适用于在后台清除重复的数

据以节省空间，但是它不保证没有重复的数据出现。

3）案例演示

（1）创建表

create table t_order_rmt(
 id UInt32,
 sku_id String,
 total_amount Decimal(16,2) ,
 create_time Datetime 
) engine =ReplacingMergeTree(create_time)
 partition by toYYYYMMDD(create_time)
 primary key (id)
 order by (id, sku_id);

ReplacingMergeTree() 填入的参数为版本字段，重复数据保留版本字段值最大的。 如果不填版本字段，默认按照插入顺序保留最后一条。

（2）向表中插入数据

insert into t_order_rmt values
(101,'sku_001',1000.00,'2020-06-01 12:00:00') ,
(102,'sku_002',2000.00,'2020-06-01 11:00:00'),
(102,'sku_004',2500.00,'2020-06-01 12:00:00'),
(102,'sku_002',2000.00,'2020-06-01 13:00:00'),
(102,'sku_002',12000.00,'2020-06-01 13:00:00'),
(102,'sku_002',600.00,'2020-06-02 12:00:00');

（3）执行第一次查询

hadoop102 :) select * from t_order_rmt;

（4）手动合并

OPTIMIZE TABLE t_order_rmt FINAL;

（5）再执行一次查询

hadoop102 :) select * from t_order_rmt;

4）通过测试得到结论

➢ 实际上是使用 order by 字段作为唯一键

➢ 去重不能跨分区

➢ 只有同一批插入（新版本）或合并分区时才会进行去重

➢ 认定重复的数据保留，版本字段值最大的

➢ 如果版本字段相同则按插入顺序保留最后一笔

4.6 SummingMergeTree

对于不查询明细，只关心以维度进行汇总聚合结果的场景。如果只使用普通的MergeTree的话，无论是存储空间的开销，还是查询时临时聚合的开销都比较大。

ClickHouse 为了这种场景，提供了一种能够“预聚合”的引擎SummingMergeTree

1）案例演示

（1）创建表

create table t_order_smt(
 id UInt32,
 sku_id String,
 total_amount Decimal(16,2) ,
 create_time Datetime 
) engine =SummingMergeTree(total_amount)
 partition by toYYYYMMDD(create_time)
 primary key (id)
 order by (id,sku_id );

（2）插入数据

insert into t_order_smt values
(101,'sku_001',1000.00,'2020-06-01 12:00:00'),
(102,'sku_002',2000.00,'2020-06-01 11:00:00'),
(102,'sku_004',2500.00,'2020-06-01 12:00:00'),
(102,'sku_002',2000.00,'2020-06-01 13:00:00'),
(102,'sku_002',12000.00,'2020-06-01 13:00:00'),
(102,'sku_002',600.00,'2020-06-02 12:00:00');

（3）执行第一次查询

hadoop102 :) select * from t_order_smt;

（4）手动合并

OPTIMIZE TABLE t_order_smt FINAL;

（5）再执行一次查询

hadoop102 :) select * from t_order_smt;

2）通过结果可以得到以下结论

➢ 以 SummingMergeTree（）中指定的列作为汇总数据列

➢ 可以填写多列必须数字列，如果不填，以所有非维度列且为数字列的字段为汇总数据列

➢ 以 order by 的列为准，作为维度列

➢ 其他的列按插入顺序保留第一行

➢ 不在一个分区的数据不会被聚合

➢ 只有在同一批次插入(新版本)或分片合并时才会进行聚合

3）开发建议

设计聚合表的话，唯一键值、流水号可以去掉，所有字段全部是维度、度量或者时间戳。

4）问题

能不能直接执行以下 SQL 得到汇总值

select total_amount from XXX where province_name=’’ and create_date=’xxx’

不行，可能会包含一些还没来得及聚合的临时明细

如果要是获取汇总值，还是需要使用 sum 进行聚合，这样效率会有一定的提高，但本身 ClickHouse 是列式存储的，效率提升有限，不会特别明显。

select sum(total_amount) from province_name=’’ and create_date=‘xxx’

超级困蛋
关注
专栏目录
【clickhouse】clickhouse 表引擎 之 AggregatingMergeTree
九师兄
02-08 1178
AggregatingMergeTree 是 ClickHouse 中的一个表引擎，它基于 MergeTree 引擎，并添加了对预聚合的支持。这个引擎特别适合需要频繁进行聚合查询的场景，因为它可以在数据写入时就预先计算并存储聚合结果，从而在查询时大大减少计算量和提高查询性能。做过数据仓库建设经验的读者一定知道“数据立方体”的概念，这是一个在数据仓库领域十分常见的模型。它通过以空间换时间的方法提升查询性能，将需要聚合的数据预先计算出来，并将结果保存起来。在后续进行聚合查询的时候，直接使用结果数据。
ClickHouse表引擎
robinhunan的博客
10-20 962
ClickHouse表引擎
ClickHouse应用
小呀么小白兔
03-02 432
第二章 ClickHouse的安装 2.1 准备工作 2.1.1 确定防火墙处于关闭状态 2.1.2 CentOS取消打开文件数限制  在hadoop102的 /etc/security/limits.conf文件的末尾加入以下内容 [apache@hadoop102 ~]$ sudo vim /etc/security/limits.conf * soft nofile 65536 * hard nofile 65536 * soft nproc 131072 * ha...
Clickhouse之表引擎
weixin_43597208的博客
04-07 243
写入后的某个时刻（大概 10-15 分钟后）， ClickHouse 会自动执行合并操作（等不及也可以手动通过 optimize 执行），把临时分区的数据，合并到已有分区中。order by 是 MergeTree 中唯一一个必填项，甚至比 primary key 还重要，因为当用户不设置主键的情况，很多处理会依照 order by 的字段进行处理（比如后面会讲的去重和汇总）。ClickHouse 中的主键，和其他数据库不太一样， 它只提供了数据的一级索引，但是却不是唯一约束。一般保存少量数据的小表，
Clickhouse学习笔记（3）—— Clickhouse表引擎
WHY的博客
11-10 2008
本文介绍了clickhouse这一数据库常用的表引擎，包括TinyLog、Memory、MergeTree、ReplacingMergeTree和SummingMergeTree等，并附有详细的操作案例
Clickhouse表引擎介绍
03-08 2603
作者：俊达。
clickhouse表引擎
zll_1234的博客
12-21 2563
表引擎是clickhouse的一大特色，表引擎决定了如何存储表的数据
3、ClickHouse表引擎-MergeTree引擎
05-29
MergeTree引擎是ClickHouse中最为核心和常用的表引擎，尤其适合高负载的数据处理任务。 MergeTree系列引擎的设计理念在于高效的数据插入和处理。在写入数据时，MergeTree将数据分片存储，并在后台自动进行合并，这...
详解 ClickHouse 的表引擎
最新发布
weixin_44480009的博客
06-20 1772
表引擎决定了如何存储表的数据。包括：数据的存储方式和位置，写到哪里以及从哪里读取数据支持哪些查询以及如何支持并发数据访问索引的使用（如果存在）是否可以执行多线程请求数据复制参数表引擎的使用方式：必须显式在创建表时定义该表使用的引擎，以及引擎使用的相关参数。特别注意：表引擎的名称大小写敏感。
clickhouse5:表引擎-Megree
天启的博客
08-13 289
clickhouse在建表时必须显示指定该表使用的引擎，以及引擎使用的相关参数。引擎的名称大小写敏感。表引擎决定了如何存储表的数据，包括： 数据的存储方式和位置，写到哪里以及从哪里读取数据 支持哪些查询以及如何支持 并发数据访问 索引的使用(如果存在) 是否可以执行多线程请求 数据复制参数 1.MergeTree 适用于高负载任务的最通用和功能最强大的表引擎。这类引擎的特点是可以快速插入数据并进行后续的后台数据处理，MergeTree引擎支持数据复制(使用Repli...
ClickHouse表引擎详解看这篇就够了-基本讲解、处理逻辑、测试实例
weixin_43805705的博客
01-03 2256
表引擎在 ClickHouse 中的作用十分关键，直接决定了数据如何存储和读取、是否支持并发读写、是否支持 index、支持的 query 种类、是否支持主备复制等。 ClickHouse表引擎一共分为四个系列，分别是Log、MergeTree、Integration、Special。其中包含了两种特殊的表引擎Replicated、Distributed，功能上与其他表引擎正交，根据场景组合使用。
ClickHouse学习笔记之表引擎
四国棋客
09-03 808
表引擎是ClickHouse一大特色，决定了表数据的存储方式。表引擎使用时必须显式在创建表时定义该表使用的引擎，以及引擎参数，注意引擎名大小写敏感
【基础篇】ClickHouse 表引擎详解
日拱一卒无有尽，功不唐捐终入海
09-17 1843
Clickhouse 表引擎（Table Engine）是一种数据库管理系统中的关键部分，负责存储数据、读取数据和处理数据查询。不同的表引擎具有不同的性能特性和适用范围。在某些数据库系统中，例如MySQL，你可以为每个表选择不同的表引擎，包括InnoDB，MyISAM，Memory等。这些表引擎在功能、性能、并发能力、恢复能力等方面都有所不同。在ClickHouse中，表引擎的选择将影响数据的存储格式、索引的使用、并发控制机制、是否支持数据复制等许多重要的方面。表引擎（即表的类型）决定了什么。
ClickHouse基础知识（四）：ClickHouse 引擎详解
zuodingquan666的博客
12-28 2049
（2）向表中插入数据。
Clickhouse引擎材料
draven1122的博客
10-25 829
https://www.jianshu.com/p/dbca0f5ededb
ClickHouse学习笔记（二）：ClickHouse常见表引擎简介
u011047968的专栏
03-27 1916
摘要：简单介绍了一下 ClickHouse 的常见表引擎
ClickHouse的Engine
wade1010的专栏
01-10 537
特点：跟TinyLog相似，但也有区别：存储的列文件中存在某些“标记”数据，这些数据都是写到数据块上并携带些offset，这些offset可以记录从何处读取文件和跳转到何处去，在并发数据访问中适合多线程读取表数据，写操作是带锁的，log engine不支持索引操作，如果表写入失败，将会导致表不可用。特点：清除重复数据往往发生在数据合并时，所以在清除数据时，可以节省大量的空间，但是不能保证数据没有重复。大量的数据插入到表中，后台将会逐个part写入，并且按照后台的规则对写入的数据进行合并。
ClickHouse开发规范
雪辉博客
11-18 1945
文章目录一、建表规范1.1 数据表引擎选择Log系列Integration系列Special系列MergeTree系列1.2 数据表字段选择数值类型字符串类型日期类型二、SQL规范 一、建表规范 数据表必须设置主键 数据表必须有以下字段 created_date updated_date created_by updated_by 1.1 数据表引擎选择 Log系列 Log系列表引擎功能相对简单，主要用于快速写入小表（1百万行左右的表），然后全部读出的场景。 几种Log表引擎的共性是： 数据被顺序ap
ClickHouse表常用引擎
热门推荐
努力赚钱就可以住更好的养老院
09-20 1万+
TinyLog 是最简单的表轻量引擎（最多约100万行）, 一写多读的应用场景。同时读写会损害数据 TinyLog 表经常作为中间表，用于数据的微批量处理. 语法中无需携带任何参数 它将数据保存到磁盘. 每个字段都以单独压缩文件形式保存. 当写入数据时, 数据追加到文件的末尾 创建表的样例： CREATE TABLE [ IF NOT EXISTS ] [ ...
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值