Clickhouse表引擎

最新推荐文章于 2023-09-17 10:30:00 发布
最新推荐文章于 2023-09-17 10:30:00 发布
阅读量74 收藏
点赞数
分类专栏： 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’

超级困蛋
关注
  • 0
    点赞
  • 踩
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
专栏目录
ClickHouse表引擎
robinhunan的博客
10-20 900
ClickHouse表引擎
ClickHouse应用
小呀么小白兔
03-02 389
第二章 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 220
写入后的某个时刻（大概 10-15 分钟后）， ClickHouse 会自动执行合并操作（等不及也可以手动通过 optimize 执行），把临时分区的数据，合并到已有分区中。order by 是 MergeTree 中唯一一个必填项，甚至比 primary key 还重要，因为当用户不设置主键的情况，很多处理会依照 order by 的字段进行处理（比如后面会讲的去重和汇总）。ClickHouse 中的主键，和其他数据库不太一样， 它只提供了数据的一级索引，但是却不是唯一约束。一般保存少量数据的小表，
clickhouse5:表引擎-Megree
天启的博客
08-13 254
clickhouse在建表时必须显示指定该表使用的引擎，以及引擎使用的相关参数。引擎的名称大小写敏感。表引擎决定了如何存储表的数据，包括： 数据的存储方式和位置，写到哪里以及从哪里读取数据 支持哪些查询以及如何支持 并发数据访问 索引的使用(如果存在) 是否可以执行多线程请求 数据复制参数 1.MergeTree 适用于高负载任务的最通用和功能最强大的表引擎。这类引擎的特点是可以快速插入数据并进行后续的后台数据处理，MergeTree引擎支持数据复制(使用Repli...
ClickHouse表引擎详解看这篇就够了-基本讲解、处理逻辑、测试实例
weixin_43805705的博客
01-03 2067
表引擎在 ClickHouse 中的作用十分关键，直接决定了数据如何存储和读取、是否支持并发读写、是否支持 index、支持的 query 种类、是否支持主备复制等。 ClickHouse表引擎一共分为四个系列，分别是Log、MergeTree、Integration、Special。其中包含了两种特殊的表引擎Replicated、Distributed，功能上与其他表引擎正交，根据场景组合使用。
3、ClickHouse表引擎-MergeTree引擎
05-29
3、ClickHouse表引擎-MergeTree引擎 网址：https://blog.csdn.net/chenwewi520feng/article/details/130502351 介绍clickhouse 的表引擎，即mergetree引擎的使用
4、clickhouse的Log系列表引擎、外部集成表引擎和其他特殊的表引擎介绍及使用
05-29
4、clickhouse的Log系列表引擎、外部集成表引擎和其他特殊的表引擎介绍及使用 网址：https://blog.csdn.net/chenwewi520feng/article/details/130505297 介绍Log系列表引擎、外部集成表引擎和其他特殊的表引擎介绍及...
ClickHouse-架构原理和表引擎详解
最新发布
03-04
ClickHouse-架构原理和表引擎详解
clickhouse--kafka引擎接入同步表.docx
12-26
Clickhouse—kafka引擎接入到同步表同样可同步，等同于直接插入同步表,说明只要同步表有变化久同步，和具体变化源没关系，merger系列引擎对外没有区别，可互相转化
clickhouse各种表引擎的异同markdown笔记.zip
03-15
clickhouse各种表引擎的异同markdown笔记
ClickHouse学习笔记之表引擎
四国棋客
09-03 493
表引擎是ClickHouse一大特色，决定了表数据的存储方式。表引擎使用时必须显式在创建表时定义该表使用的引擎，以及引擎参数，注意引擎名大小写敏感
【基础篇】ClickHouse 表引擎详解
日拱一卒无有尽，功不唐捐终入海
09-17 1451
Clickhouse 表引擎（Table Engine）是一种数据库管理系统中的关键部分，负责存储数据、读取数据和处理数据查询。不同的表引擎具有不同的性能特性和适用范围。在某些数据库系统中，例如MySQL，你可以为每个表选择不同的表引擎，包括InnoDB，MyISAM，Memory等。这些表引擎在功能、性能、并发能力、恢复能力等方面都有所不同。在ClickHouse中，表引擎的选择将影响数据的存储格式、索引的使用、并发控制机制、是否支持数据复制等许多重要的方面。表引擎（即表的类型）决定了什么。
Clickhouse引擎材料
draven1122的博客
10-25 812
https://www.jianshu.com/p/dbca0f5ededb
ClickHouse学习笔记（二）：ClickHouse常见表引擎简介
u011047968的专栏
03-27 1805
摘要：简单介绍了一下 ClickHouse 的常见表引擎
ClickHouse的Engine
wade1010的专栏
01-10 482
特点：跟TinyLog相似，但也有区别：存储的列文件中存在某些“标记”数据，这些数据都是写到数据块上并携带些offset，这些offset可以记录从何处读取文件和跳转到何处去，在并发数据访问中适合多线程读取表数据，写操作是带锁的，log engine不支持索引操作，如果表写入失败，将会导致表不可用。特点：清除重复数据往往发生在数据合并时，所以在清除数据时，可以节省大量的空间，但是不能保证数据没有重复。大量的数据插入到表中，后台将会逐个part写入，并且按照后台的规则对写入的数据进行合并。
ClickHouse开发规范
雪辉博客
11-18 1902
文章目录一、建表规范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】ClickHouse表引擎 MergeTree 建表方式与分区规则
九师兄
02-07 4902
1.概述 转载：ClickHouse表引擎 1.MergeTree 建表方式与分区规则 2.MergeTree 介绍 表引擎是 ClickHouse 设计实现中的一大特色。可以说，是表引擎决定了一张数据表最终的“性格”，比如数据表拥有何种特性、数据以何种形式被存储以及如何被加载。 ClickHouse拥有非常庞大的表引擎体系，其共拥有合并树、外部存储、内存、文件、接口和其他6大类20多种表引擎。而在这众多的表引擎中，又属合并树（MergeTree）表引擎及其家族系列最为强大，在生产环境的绝大部分场景中，都.
ClickHouse表常用引擎
热门推荐
努力赚钱就可以住更好的养老院
09-20 1万+
TinyLog 是最简单的表轻量引擎（最多约100万行）, 一写多读的应用场景。同时读写会损害数据 TinyLog 表经常作为中间表，用于数据的微批量处理. 语法中无需携带任何参数 它将数据保存到磁盘. 每个字段都以单独压缩文件形式保存. 当写入数据时, 数据追加到文件的末尾 创建表的样例： CREATE TABLE [ IF NOT EXISTS ] [ ...
ClickHouse 表引擎
阿茂丶
11-10 1484
一、引擎分类 MergeTree系列 LogTree系列 集成引擎 特定功能引擎 适用于高负载任务的最通用和功能最强大的表引擎。可以快速插入数据并进行后续的后台数据处理 1. MergeTree 2. ReplacingMergeTree 3. SummingMergeTree 4. AggregatingMergeTree 5. CollapsingMergeTree 6.VersionedCollap.
clickhouse表引擎
05-12
它支持多种表引擎，包括以下几种： 1. MergeTree：基于时间戳的表引擎，适用于大部分的数据分析场景。 2. ReplacingMergeTree：基于时间戳的表引擎，支持数据的更新和删除。 3. CollapsingMergeTree：基于时间戳...

“相关推荐”对你有帮助么？

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

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

抵扣说明：

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

余额充值