表引擎(即表的类型)决定了:
1)数据的存储方式和位置,写到哪里以及从哪里读取数据
2)支持哪些查询以及如何支持。
3)并发数据访问。
4)索引的使用(如果存在)。
5)是否可以执行多线程请求。
6)数据复制参数。
ClickHouse的表引擎有很多,下面介绍其中几种,对其他引擎有兴趣的可以去查阅官方文档:官方文档
是为了分区间能够并行计算
数据其实是先写到临时分区, 后续才被合并到现有分区
分区目录: 由文件+索引文件+表定义文件
组成
它只提供了数据的一级索引
,但不是唯一约束
是稀疏索引(类似于跳表)
二级索引
数据的存活时间, 数据过期失效后不会立即清除
, 而是在合并时才进行清除, 被清除前这个数据依旧是可见的
它的清除不是为了业务去及时清除过期数据, 而只是为了节省内存才清除失效数据
设定了分区内
数据按照哪些字段 进行有序地保存
主键必须是order by字段的前缀字段, 比如 order by的字段是(id,sku_id)时, 那么主键必须是id 或者(id,sku_id)
可作ReplacingMergeTree里的去重字段
, 和SummingMergeTree里的维度字段
TinyLog
最简单的表引擎,用于将数据存储在磁盘上。每列都存储在单独的压缩文件中,写入时,数据将附加到文件末尾。
该引擎没有并发控制
●如果同时从表中读取和写入数据,则读取操作将抛出异常;
●如果同时写入多个查询中的表,则数据将被破坏。
这种表引擎的典型用法是 write-once:首先只写入一次数据,然后根据需要多次读取。此引擎适用于相对较小的表(建议最多1,000,000行)。如果有许多小表,则使用此表引擎是适合的,因为它比需要打开的文件更少。当拥有大量小表时,可能会导致性能低下。 不支持索引。
案例:创建一个TinyLog引擎的表并插入一条数据
此时我们到保存数据的目录/var/lib/clickhouse/data/default/t中可以看到如下目录结构:
a.bin 和 b.bin 是压缩过的对应的列的数据, sizes.json 中记录了每个 *.bin 文件的大小:
:)create table t (a UInt16, b String) ENGINE = TinyLog; :)insert into t (a, b) values (1, 'abc'); |
内存引擎,数据以未压缩的原始形式直接保存在内存当中,服务器重启数据就会消失。读写操作不会相互阻塞,不支持索引。简单查询下有非常非常高的性能表现(超过10G/s)。
一般用到它的地方不多,除了用来测试,就是在需要非常高的性能,同时数据量又不太大(上限大概 1 亿行)的场景。
Merge
Merge 引擎 (不要跟 MergeTree 引擎混淆) 本身不存储数据,但可用于同时从任意多个其他的表中读取数据。 读是自动并行的,不支持写入。读取时,那些被真正读取到数据的表的索引(如果有的话)会被使用。
Merge 引擎的参数:一个数据库名和一个用于匹配表名的正则表达式。
案例:先建t1,t2,t3三个表,然后用 Merge 引擎的 t 表再把它们链接起来。
:)create table t1 (id UInt16, name String) ENGINE=TinyLog; |
MergeTree
Clickhouse 中最强大的表引擎当属 MergeTree (合并树)引擎及该系列(*MergeTree)中的其他引擎。拥有主键,但是它的主键却没有唯一键的约束
MergeTree 引擎系列的基本理念如下。当你有巨量数据要插入到表中,你要高效地一批批写入数据片段,并希望这些数据片段在后台按照一定规则合并。相比在插入时不断修改(重写)数据进存储,这种策略会高效很多。
格式:
ENGINE = MergeTree()
[PARTITION BY expr] PARTITION BY 分区键 只能按照日期分区 eg:按月份分区 toYYYYMM(datecolumn)
[ORDER BY expr] ORDER BY 排序键,可以是一组列的元组或者任意表达式 例如(ORDER BY(id,name))排序
[PRIMARY KEY expr] 主键 ,(如果不写PRIMARY KEY默认以ORDER BY作为主键,如果指定主键不能和order by 一样)
[SAMPLE BY expr] 用于抽样表达式 , 如果写了此参数,要用抽样表达式,则主键中必须包含这个表达式
[SETTINGS name=value,...] SETTINGS :MergeTree的额外参数:
min_merge_bytes_to_use_direct_io 使用直接 I/O 来操作磁盘的合并操作时要求的最小数据量。合并数据片段时,ClickHouse 会计算要被合并的所有数据的总存储空间。如果大小超过了 min_merge_bytes_to_use_direct_io时,ClickHouse 会计算要被合并的所有数据的总存储空间。如果大小超过了 min_merge_bytes_to_use_direct_io设置的字节数,则 ClickHouse 将使用直接 I/O 接口 否则使用缓存i/o
use_minimalistic_part_header_in_zookeeper — 数据片段头在 ZooKeeper 中的存储方式。如果设置了
use_minimalistic_part_header_in_zookeeper=1 ,ZooKeeper 会存储更少的数据。
index_granularity — 索引粒度。即索引中相邻『标记』间的数据行数。默认值,8192
index_granularity — 索引粒度。即索引中相邻『标记』间的数据行数。默认值,8192 。该列表中所有可用的参数可以从这里查看 MergeTreeSettings.h 。 |
格式
CREATE TABLE [IF NOT EXISTS] [db.]table_name [ON CLUSTER cluster]
(
name1 [type1] [DEFAULT|MATERIALIZED|ALIAS expr1],
name2 [type2] [DEFAULT|MATERIALIZED|ALIAS expr2],
...
INDEX index_name1 expr1 TYPE type1(...) GRANULARITY value1,
INDEX index_name2 expr2 TYPE type2(...) GRANULARITY value2
) ENGINE = MergeTree()
[PARTITION BY expr]
[ORDER BY expr]
[PRIMARY KEY expr]
[SAMPLE BY expr]
[SETTINGS name=value, ...]
案例
create table mt_table (date Date, id UInt8, name String) ENGINE=MergeTree(date, (id, name), 8192);
insert into mt_table values ('2019-05-01', 1, 'zhangsan');
insert into mt_table values ('2019-06-01', 2, 'lisi');
insert into mt_table values ('2019-05-03', 3, 'wangwu');
在/var/lib/clickhouse/data/default/mt_tree下可以看到:
[root@hadoop102 mt_table]# ls
20190501_20190501_2_2_0 20190503_20190503_6_6_0 20190601_20190601_4_4_0 detached
ReplacingMergeTree
这个引擎是在 MergeTree 的基础上,添加了“处理重复数据”的功能,该引擎和MergeTree的不同之处在于它会删除具有相同主键的重复项。数据的去重只会在合并的过程中出现。合并会在未知的时间在后台进行,所以你无法预先作出计划。有一些数据可能仍未被处理。因此,ReplacingMergeTree 适用于在后台清除重复的数据以节省空间,但是它不保证没有重复的数据出现。
格式:
ENGINE [=] ReplacingMergeTree(date-column [, sampling_expression], (primary, key), index_granularity, [ver])
案例
create table rmt_table (date Date, id UInt8, name String,point UInt8) ENGINE= ReplacingMergeTree(date, (id, name), 8192,point);
插入一些数据:
insert into rmt_table values ('2019-07-10', 1, 'a', 20);
insert into rmt_table values ('2019-07-10', 1, 'a', 30);
insert into rmt_table values ('2019-07-11', 1, 'a', 20);
insert into rmt_table values ('2019-07-11', 1, 'a', 30);
insert into rmt_table values ('2019-07-11', 1, 'a', 10);
等待一段时间或optimize table rmt_table手动触发merge,后查询
:) select * from rmt_table;
┌───────date─┬─id─┬─name─┬─point─┐
│ 2019-07-11 │ 1 │ a │ 30 │
└────────────┴────┴──────┴───────┘
Distributed
分布式引擎,本身不存储数据, 但可以在多个服务器上进行分布式查询。 读是自动并行的。读取时,远程服务器表的索引(如果有的话)会被使用。
Distributed(cluster_name, database, table [, sharding_key])
参数解析:
cluster_name - 服务器配置文件中的集群名,在/etc/metrika.xml中配置的 database – 数据库名 table – 表名 sharding_key – 数据分片键
案例演示:
1)在hadoop102,hadoop103,hadoop104上分别创建一个表t
:)create table t(id UInt16, name String) ENGINE=TinyLog;
2)在三台机器的t表中插入一些数据
:)insert into t(id, name) values (1, 'zhangsan'); :)insert into t(id, name) values (2, 'lisi');
3)在hadoop102上创建分布式表
:)create table dis_table(id UInt16, name String) ENGINE=Distributed(perftest_3shards_1replicas, default, t, id);
4)往dis_table中插入数据
:) insert into dis_table select * from t
5)查看数据量
:) select count() from dis_table FROM dis_table ┌─count()─┐ │ 8 │ └─────────┘ :) select count() from t SELECT count() FROM t ┌─count()─┐ │ 3 │ └─────────┘
可以看到每个节点大约有1/3的数据