ClickHouse 的表引擎是 ClickHouse 服务的核心,它们主要是解决以下问题:
注意:
引擎是区分大小写的
该系列引擎是执行高负载任务的最通用和最强大的表引擎,它们的特点是可以快速插入数据以及进行后续的数据处理。该系列引擎还同时支持数据复制(使用Replicated的引擎版本),分区 (partition) 以及一些其它引擎不支持的额外功能。
HDFS 表引擎不支持 Kerberos 认证,如果开启,请关闭HDFS的Kerberos认证,创建 HDFS 测试表示例:
CREATE TABLE hdfs_table1_local ON CLUSTER sharding_cluster
(
`id` UInt32,
`name` String
)
ENGINE = HDFS('hdfs://clickhouse1:9099/clickhouse/hdfs_table1/*', 'CSV')
创建 MySQL 表引擎测试表:
CREATE TABLE clickhouse_mysql_test_local ON CLUSTER sharding_cluster
(
`id` UInt32,
`name` String
)
ENGINE = MySQL('host:port', 'database', 'table', 'user', 'password')
相对于 MySQL 表引擎而言,JDBC 表引擎不仅可以对接 MySQL 数据库还能够与 PostgreSQL、SQLite 和 H2 数据库对接。但是,JDBC 表引擎无法单独完成所有的工作,他需要依赖名为 clickhouse-jdbc-bridge 的查询代理服务。
Kafka 表引擎能够直接与 Kafka 系统对接,进而订阅 Kafka 中的主题并实时接收消息数据(暂不支持 Exactly once(恰好一次))。
创建 Kafka 表引擎测试表:
create table clickhouse_kafka_test_local(
id UInt32,
name String
) engine = Kafka()
settings
kafka_broker_list = 'clickhouse1:9092,clickhouse2:9092,clickhouse3:9092',
kafka_topic_list = 'clickhouse_kafka_test',
kafka_group_name = 'clickhouse_kafka_test_group',
kafka_format = 'JSONEachRow',
kafka_skip_broken_messages = 100;
File 表引擎能够直接读取本地文件的数据,通常被作为一种扩充手段来使用。
File 表引擎测试表:
CREATE TABLE test_file_table
(
`id` UInt32,
`name` String
)
ENGINE = File('CSV')
File 表引擎的数据只能保存在 config.xml 配置中由 path 指定的路径下。
例如:
<ch-path>/data/defalut/test_file_table/data.CSVch-path>
Memory 表引擎直接将数据保存在内存中,数据即不会被压缩也不会被格式转换,因为基于内存,所以服务重启后会丢失。
Memory 表引擎测试表:
CREATE TABLE test_memory_table
(
`id` UInt32,
`name` String
)
ENGINE = Memory()
Set 表引擎是拥有物理存储的,数据首先会被写至内存,然后被同步到磁盘文件中。
Set 表引擎测试表:
CREATE TABLE test_set_table
(
`id` UInt32
)
ENGINE = Set()
注意:
Set 表引擎不能被直接查询,正确的查询方法是将 Set 表引擎作为 IN 查询的右侧条件,例如:
SELECT arrayJoin([1,2,3]) AS a WHERE a IN test_set_table
Join 表引擎可以说是为 JOIN 查询而生的
,它等同于将 JOIN 查询进行了一层简单封装。
Join 表引擎测试表:
CREATE TABLE test_join_table
(
`id` UInt32,
`name` String
)
ENGINE = Join(ANY,LEFT,id)
说明:
需要说明的是:Join表引擎更加通常的用途,是用于Join连接查询的右侧表。且Join表的数据是首先被写至内存,然后才被同步到磁盘文件上。这意味着两件事:
1.Join表的查询速度很快,因为它的存在本来就是为了优化连接查询的速度;
2.Join表不适合存放千万级以上的大表,否则会占用过多的服务器内存,它更适合存放需要经常查询的小表,且通常为join语句的右侧表。
Buffer 表引擎完全使用内存装载数据,不支持文件的持久化存储,所以当服务重启之后,表内的数据会被清空。Buffer 表引擎不是为了面向查询场景而设计的,它的作用是充当缓冲区的角色。
TinyLog 是日志家族系列中性能最低的表引擎,它的存储结构由数据文件和元数据两部分组成。
TinyLog 表引擎测试表:
CREATE TABLE test_tinylog_table
(
`id` UInt32,
`name` String
)
ENGINE = TinyLog()
StripeLog 对比 TinyLog 拥有更高的查询性能。
StripeLog 表引擎测试表:
CREATE TABLE test_stripelog_table
(
`id` UInt32,
`name` String
)
ENGINE = StripeLog()
Log 表引擎结合了 TinyLog 表引擎和 StripeLog 表引擎的长处,是日志家族系列中性能最高的表引擎。由于拥有数据标记且各列数据独立存储,所以 Log 既能够支持并行查询,又能够按列按需读取。
Log 表引擎测试表:
CREATE TABLE test_log_table
(
`id` UInt32,
`name` String
)
ENGINE = Log()
这一类表引擎不存储任何数据,而是像粘合剂一样可以整合其他数据表。
Merge 表引擎就如同一层使用了门面模式的代理,它本身不存储任何数据,也不支持数据写入。他的作用就如其名,即负责合并多个查询的结果集。
比如现在有几个表:test_table_2019、test_table_2020、test_table_2021、test_table_2022、test_table_2023
Merge 表引擎测试表:
CREATE TABLE test_table_all as test_table_2019
ENGINE = Merge(currentDatabase(),'^test_table_')
上面的语句是将所有以^test_table_开头的数据表合并。
Dictionary 表引擎是数据字段的一层代理封装,它可以取代字典函数,让用户通过数据表查询字典。字典内的数据被加载后,会全部保存到内存中,所以使用 Dictionary 表对字典表性能不会有任何影响。
Dictionary 表引擎测试表:
CREATE TABLE tb_test_flat_dict
(
`id` UInt32,
`code` String,
`name` String
)
ENGINE = Dictionary(test_flat_dict)
test_flat_dict 对应一个已被加载的字典名称
Distributed 表引擎自身不存储任何数据,它能作为分布式表的一层透明代理,在集群内部自动开展数据的写入分发以及查询路由工作。
Live View 是一种特殊的视图,虽然它并不属于表引擎,但是因为它与数据表息息相关,Live View 的作用类似事件监听器,它能够将一条 SQL 查询结果作为监控目标,当目标数据增加时,Live View 可以及时发出响应。
原始表
CREATE TABLE origin_table1
(
`id` UInt32,
`name` String
)
ENGINE = Log()
创建一张 Live View 表示:
CREATE LIVE VIEW lv_origin AS SELECT COUNT(*) FROM orign_table1
如此一来,Live View 就进入监听模式了。接着通过下面的命令可以看出实时监控结果:
WATCH lv_origin
Null 表引擎的功能和作用,与 Unix 系统的空设备 /dev/null 很相似。如果用户向 Null 表写入数据,系统会正确返回,但是 Null 表会自动忽略数据,永远不会将它保存。如果不希望保留源表的数据,那么将原表设置成 Null 引擎将会是极好的选择。
URL 表引擎的作用等价于 HTTP 客户端,他可以通过 HTTP/HTTPS 协议,直接访问远端的 REST 服务。当执行 SELECT 查询的时候,底层会将其转换成 GET 请求的远程调用。而执行 INSERT 查询的时候,会将其转换为 POST 请求的远程调用。URL 表引擎的声明方式如下:
ENGINE = URL(url, format)
其中,url 表示远端的服务地址,而 format 则是 Clickhouse 支持的数据格式,如 TSV、CSV 和 JSON 等。