使用

表引擎的使用方式就是必须显示在创建表时定义该表使用的引擎，以及引擎使用的相关参数。
如：
create table t_tinylog ( id String, name String) **engine=TinyLog**;

注意:驼峰命名法，引擎的名称大小写敏感

常用引擎

TinyLog

以列文件的形式保存在磁盘上，不支持索引，没有并发控制。一般保存少量数据的小表，生产环境上作用有限。可以用于平时练习测试用。

Memory

内存引擎，数据以未压缩的原始形式直接保存在内存当中，服务器重启数据就会消失。读写操作不会相互阻塞，不支持索引。简单查询下有非常非常高的性能表现（超过10G/s）。
一般用到它的地方不多，除了用来测试，就是在需要非常高的性能，同时数据量又不太大（上限大概 1 亿行）的场景。

create table t_memory(id Int16, name String) engine=Memory;
insert into t_memory values(1, ‘lisi’);

重启服务器查询数据已经没有了.

MergeTree

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

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，a)

primary key要么是order by (id,sku_id,a)要么是id，要么是id,sku_id,要么是id,sku_id,a

MergeTree其实还有很多参数(绝大多数用默认值即可)，但是上面3个标红参数是更加重要的，也涉及了关于MergeTree的很多概念。
插入多条数据

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’)


Partition by 分区

作用：
学过hive的应该都不陌生，分区的目的主要是减少扫描的范围，优化查询速度。如果不填： 只会使用一个分区。
分区目录：
MergeTree 是以列文件+索引文件+表定义文件组成的，但是如果设定了分区那么这些文件就会保存到不同的分区目录中。
并行：
分区后，面对涉及跨分区的查询统计，clickhouse会以分区为单位并行处理。
数据写入与分区合并：
任何一个批次的数据写入都会产生一个临时分区，不会纳入任何一个已有的分区。写入后的某个时刻（大概10-15分钟后），clickhouse会自动执行合并操作（等不及也可以手动通过optimize执行），把临时分区的数据，合并到已有分区中。
optimize table xxxx [final]

primary key主键

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

主键的设定主要依据是查询语句中的where 条件。
人话：将主键作为稀疏索引来过滤出对应数据，避免全盘扫描
根据条件通过对主键进行某种形式的二分查找，能够定位到对应的index granularity,避免了全包扫描。

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

稀疏索引
稀疏索引的好处就是可以用很少的索引数据，定位更多的数据，代价就是只能定位到索引粒度的第一行，
然后再进行进行一点扫描,但是要求索引必须有序，这就是order by的结构的原因。
由于稀疏索引比较少, 所以理论上可以完全加载到内存中, 从提高查询速度
image.png

order by

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

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

要求：主键必须是order by字段的前缀字段。
比如order by 字段是 (id,sku_id) 那么主键必须是id 或者(id,sku_id)

数据TTL

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

列级别的TTL

针对某列数据过期

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)
insert into t_order_mt3
values(106,’sku_001’,1000.00,’2021-08-03 15:37:50’) ,
(107,’sku_002’,2000.00,’2020-06-12 22:52:30’),
(110,’sku_003’,600.00,’2021-01-17 12:00:00’)

表级别的TTL

针对整张表数据过期

alter table t_order_mt3 MODIFY TTL create_time + INTERVAL 20 SECOND;

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

- SECOND
- MINUTE
- HOUR
- DAY
- WEEK
- MONTH
- QUARTER
- YEAR

ReplacingMergeTree

分区内去重合并树
ReplacingMergeTree是MergeTree的一个变种，它存储特性完全继承MergeTree，只是多了一个去重的功能。

什么样的数据是重复
order by字段相同认为重复

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

去重范围：
如果表经过了分区，去重只会在分区内部进行去重，不能执行跨分区的去重。
所以ReplacingMergeTree能力有限， ReplacingMergeTree 适用于在后台清除重复的数据以节省空间，但是它不保证没有重复的数据出现。

建表

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);

关于版本的选择: Type UInt*, Date or DateTime. 可以比较大小的类型都行

插入数据

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’)

这里最终会保留12000，保留的是order之后的字段
image.png

执行合并
optimize table t_order_rmt final;

image.png

该引擎使用场景
ReplacingMergeTree 适用于在后台清除重复的数据以节省空间，但是它不保证没有重复的数据出现。

SummingMergeTree

分区内预聚合

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

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

建表

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 )

插入数据

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’)

image.png
optimize: 会自动进行预聚合
image.png

结论

  1. 以SummingMergeTree(字段)中指定的列作为汇总数据列。
    可以填写多列必须数字列，如果不填，以所有非维度列, 非主键且为数字列的字段为汇总数据列
    2. 以order by 的列为准，作为维度列(group by …)
    3. 其他的列保留第一行。
    4. 不在一个分区的数据不会被预聚合。
    5. 聚合发生的时机不确定
    6. 查询的时候仍然需要sql聚合语句