《Everything is Table，我该使用哪种表引擎》- part 2

书接上回，今天放出第一章节的第二部分，我专门新建了一个专辑方便大家回看，传送： ClickHouse实战系列课程

怎么选择表表引擎

说了这么多表引擎的背景知识，那么你在使用 ClickHouse 的时候到底应该怎么选择表引擎呢？我在《ClickHouse 原理解析与应用实践》一书中按照表引擎的性质，将它们归为了合并树、外部存储、内存、文件、接口和其他 6 大类型，但是在这个更加偏实战性质的专栏中，我将按照实际用途将它们归为 4 个阵营。

阵营 1：数据查询类表引擎

这里主要是指 MergeTree 家族的表引擎。MergeTree 是 ClickHouse 的王牌表引擎，业务数据最终都应该保存在使用了 MergeTree 系列引擎的表或者视图中，业务系统中 90% 以上的查询也都将会面对这些表进行查询。众所周知，MergeTree 在 ClickHouse 中有着两层语意，第一层语义表示合并树表引擎家族；第二层语义表示合并树家族中最基础的 MergeTree 引擎。

整个合并树家族目前一共有 7 个表引擎，除开 MergeTree 之外还有另外 6 个变种引擎。

合并树家族的 7 个表引擎图

l 基础的 MergeTree 提供了所有 MergeTree 家族共有的基础功能，包括列式存储、数据分区、分区索引、一级索引、二级索引、数据 TTL（生命周期）、多磁盘存储等；

l ReplacingMergeTree 支持数据去重，可以提供删除重复数据的能力；

l SummingMergeTree 和 AggregatingMergeTree 支持数据预聚合，能够提供数据立方体的能力；

l CollapsingMergeTree 和 VersionedCollapsingMergeTree 支持行级数据修改和删除的能力。

在后面的课程中，我将会详细介绍每种 MergeTree 的应用场景和使用方法，在这里我就不再一一讲述了。

阵营 2：高可用类表引擎

高可用阵营由 Replicated 和 Distributed 表引擎组成，其中，以 Replicated 开头的表引擎们拥有数据副本的能力。值得一提的是 Replicated 并不是表引擎的名称，它和 MergeTree 是组合关系，为 MergeTree 加入了副本的能力，具体类型有 ReplicatedMergeTree、ReplicatedReplacingMergeTree、ReplicatedSummingMergeTree 等，如下图所示：

Replicated 和 MergeTree 组合关系图

这些表引擎的解读方法如下所示:

l ReplicatedReplacingMergeTree 表示拥有副本能力的去重 MergeTree；

l ReplicatedSummingMergeTree 表示拥有副本能力的聚合 MergeTree。

其他引擎的解读方法以此类推。

Distributed 则等同于分库分表中间件，它自身不会存储任何数据，它的功能是作为数据分片的透明代理。当你面向 Distributed 查询的时候，它可以将查询请求自动的路由下推到集群中的各个分片节点，所以 Distributed 需要和其他分片表一起协同工作。

阵营 3：数据接入类表引擎

前文也提到过，作为一款 OLAP 分析数据库，ClickHouse 本身并不直接生产业务数据，数据会来源于它的上游系统，例如，业务系统的 MySQL 数据库或者 Kafka 这样的消息中间件。

基于高内聚的设计理念，ClickHouse 直接内置了 MySQL、Kafka、JDBC、HDFS 和 URL 这些表引擎，它们将作为内外部数据连接的桥梁。你可以直接借助这些表引擎将外部数据转储到 ClickHouse。例如:

l MySQL 表引擎可以直接读取上游 MySQL 数据库;

l Kafka 表引擎可以直接消费 Kafka 的数据；

l HDFS 表引擎可以直接读取 HDFS 上的文件。

其他引擎的解读方法以此类推，总的来说它们的实际用途都是为了可以直接打通外部存储，方便我们将数据导入到 MergeTree。

阵营 4：工具类表引擎

剩余的表引擎可以全部归为工具类，因为它们就像是 ClickHouse 内置的服务接口，每个接口都可以用来解决一类特定问题的。常用的包括有Null、Merge、Buffer、Memory、File 这几个表引擎。其中:

Null 表引擎的作用就和 Unix 系统的空设备 /dev/null 很相似，如果用户向 Null 表写入数据，它会自动忽略数据永远不会保存。如果用户向 Null 表发起查询，那么它将返回一张空表。在使用物化视图的时候，如果不希望保留源表的数据，那么将源表设置成 Null 引擎将会是不错的选择。

Merge 表引擎本身不存储任何数据，也不支持数据写入，但是它可以合并多个查询的结果集。Merge 表引擎可以代理查询任意数量的数据表，将多个查询最终合成一个结果集返回。如果我们在数据库中将业务数据按年实施了分表存储，则可以利用 Merge 表引擎实现跨年度的查询。

Buffer 表引擎的实质是一条数据管道，在数据写入时可以起到缓冲区的作用。例如我们直接向 MergeTree 写入数据时，可能会出现写入速度大于合并速度的情况。这个时候就可以使用 Buffer 表在 MergeTree 之前架设一层缓冲区，数据先向 Buffer 表写入，再由 Buffer 表自动流转到目标的 MergeTree。

Memory 表引擎的数据只会留在内存中，并不会进行持久化，所以今后我们在储存重要业务数据的时候千万可别在使用这个表引擎了。它更多是充当临时表的作用，或者是作为共享数据的载体在集群间传播。

File 表引擎主要被用在 clickhouse-local 中，clickhouse-local 是ClickHouse 内置的一个轻量级的应用程序，可以理解成是单机版微内核的ClickHouse。clickhouse-local 可以使用 Shell 的方式独立的运行大部分SQL查询，而不需要依赖任何 ClickHouse 的服务进程。通过 clickhouse-local 创建的表只能使用 File 表引擎，数据直接以文件的形式保存在硬盘上。

总结

这一课时我介绍了 ClickHouse 表引擎的设计初衷，按照实际用途将表引擎分为了 4 个阵营并带你快速浏览了它们的作用。希望今后在面对 ClickHouse 这么多表引擎的时候，你不再会一头雾水不知如何选择。

通过本课时的学习以后，你也会发现其实在真实的业务场景中我们基本都是在使用 MergeTree，所以在下一课时我会详细介绍 MergeTree 家族各类变种表引擎的特点和使用场景。在后面的课程中，我也会通过一些实际案例详细地介绍其他一些重要表引擎的使用方法。