clickhouse-其他常见类型表引擎

其他常见类型的表引擎

clickhouse表引擎还有：

• 外部存储系列的表引擎，能够直接读取其他系统的数据，clickhouse只负责元数据管理，类似外挂表的形式
• 内存系列的表引擎，能够充当数据发挥的临时存储载体或消息通道
• 日志文件系列，简单易用
• 接口系列表引擎，能够串联已有的数据表，起到粘合作用

外部存储类型

外部存储表引擎直接从其他的存储系统读取数据，例如直接读取hdfs文件或者mysql数据库的表。这些表引擎只负责元数据管理和数据查询，而不负责数据写入。

HDFS

hdfs表引擎可以直接与它对接，读取hdfs內文件。

Mysql

mysql表引擎可以通过与mysql数据库中数据表建立映射，并通过sql向其发起远程查询，包括select和insert

JDBC

JDBC表引擎不仅可以对接MySQL数据库，还能够PostgreSQL、SQLIte和H2数据库对接。

KAFKA

• 首先是kafka数据表A，充当的角色是一条数据管道，负责拉取kafka中的数据
• 接着是另外一张任意引擎的数据表B，它充当的角色是面向终端用户的查询表，在生产环境中通常是MergeTree系列。
• 最后一张是物化视图，负责将A中数据实时同步到B

File

读取本地文件的数据，通常被作为一张扩充手段来使用。

内存类型

面向内存查询的，但是也会写入磁盘（除了Memory表引擎之外）。

Memory

memory表引擎直接将数据保存在内存中，数据既不会被压缩也不会被格式转换，数据在内存中保存的形态与查询时看到的如出一辙。一般作为测试表使用，重启后数据全部丢失。Memory表更为广泛的应用场景是在clickhouse的内部，会作为集群间分发数据的存储载体来使用。例如在分布式in查询场合中，会利用memory保存in子句查询结果

Set

Set表引擎拥有物理存储，数据首先会被写入内存，然后同步到磁盘文件。服务重启数据不丢失。set表引擎使用场景特殊有限，虽然支持insert写入，但并不能直接使用select对其进行查询，set表引擎只能间接作为in查询的右侧条件被查询使用。

Join

Join表引擎可以说是JOIN查询而生的，等同于将join查询进行了一层简单封装。join表引擎底层实现中，与set表引擎公用了大部分处理逻辑，所以join和set表引擎拥有许多相似之处。数据首先写入内存，然后被同步到磁盘中。但是相比set表引擎，join表更有广泛应用场景，既可以作为join查询的链接表，也能够被直接查询使用。

Buffer

buffer表引擎完全使用内存装载数据，不支持文件的持久化存储，当服务重启时候，表内数据会被清空。buffer表引擎不是为了面向查询场景而设计的，作用充当缓冲区。

日志类型

如果使用数据量很小，100万以下，面对的数据查询场景也比较简单，并且是一次写入多次查询模式，那么使用日志家族系列表引擎很好。例如：不支持索引、分区等高级特性；不支持并发读写，当针对一张日志表写入数据时，针对这张表的查询会被阻塞。

TinyLog

日志家族中性能最低，存储结构由文件和元数据两部分组成。

StripeLog

StripeLog表引擎的存储结构由固定的3歌文件组成，分别是：
data.bin,index.mrk,
sizes.json

Log

接口类型

自身并不存储任何数据，而是像粘合剂一样可以整合其他的数据表。在使用这类表引擎的时候，不用担心底层复杂性，就像接口一样，为用户提供了统一的访问界面

MERGE

Merge表引擎可以代理查询任意数量的数据表，这些查询会异步并且并行执行，并最终合并成一个结果返回集。

Dictionary

Dictionary表引擎是数据字典的一层代理封装，它可以取代字典函数，让用户通过数据表查询字典。字典内数据被加载后，会全部保存到内存中。

Distributed

Distributed表引擎自身不存储任何数据，能够作为分布式表的一层中间透明代理

其他类型

Live View

事件监听器

Null

如果用户向null表写入数据，系统会正确返回，但是null表会自动忽略数据，永远不会保存，如果用户向null表发起查询，那么将返回一张空表。

URL

类似于http客户端，能够代理调用远端的rest服务