开个新坑，新系列启动

在 2020 年的时候，曾经计划和某在线机构合作出一门 ClickHouse 相关的在线课程，后来很遗憾由于一些原因没有合作成功。

虽然没有成功，但是提纲早就拟好了，稿子也是写了不少。所以准备在这个公众号开个新的免费专题系列，陆续的把已经完成的内容呈现出来，也希望能把没有写完的内容补全。

总之就是先挖个坑，然后慢慢填吧 哈哈。

今天先放出第一课的part 1:

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

今天我要和你分享的是关于如何选择表引擎的方法，通过今天内容的学习你不仅能掌握区分表引擎使用场合的基本思路，还能对表引擎背后的设计初衷有一个初步认识。

在开始之前请先听我讲个小故事。

软件领域的“无知之错”

在一次和朋友的聚会中，我曾经听到过这样一则趣闻：有一位老兄在做技术选型时发现了 ClickHouse，在随后的 POC 验证中对十几亿数据进行了各种夸张操作，没想到大部分查询都能够实现毫秒级的响应。于是他信心满满地去找上级（老大）汇报战果，然而在演示脚本过程中恰好有 ClickHouse 进程重启的环节，没想到重启之后表里面的数据就全部消失了。这位老兄当时就蒙圈了，一脸的尴尬，而他的老大心中也可能嘀咕着这个技术怎么如此不靠谱。

听完故事以后我摇了摇头暗自苦笑，心想他肯定是用了 Memory 内存表引擎。在《清单革命》一书中曾提过，人类所犯的错误从宏观上分为两类：

• “无知之错”：没有掌握正确的知识而犯下的错误。
• “无能之错”：掌握了正确的知识，却没有正确使用而犯下的错误。

开篇的那位老兄正是犯了“无知之错”，由于他没有正确理解并掌握表引擎的用法，所以既不能解决工作中的实际问题，还给别人留下了 ClickHouse 不靠谱的初次印象。

其实在软件领域中，“无知之错”是十分常见的，我想这是人类的天性使然吧。由于人们喜欢用历史经验来评价当前事物，所以导致一些人在学习新兴技术的时候显得过于自信，浑然不知产生的认知偏差。作为一门身处 OLAP 领域的新兴技术，ClickHouse 出色的数据库基因显著地降低了它的学习门槛。但正因为如此，也间接导致了一些人会使用其他数据库的经验来脑补 ClickHouse，以至于忽略了 ClickHouse 自身的一些最基本的概念和事实，从而最终导致“无知之错”的发生。

表引擎是在我们使用ClickHouse时怎么都绕不开的基础概念，所以为了避免这方面的 “无知之错” ，在正式进入实战之前我们很有必要了解一些 ClickHouse 表引擎的基础知识。

Everything is table

正如在 Java 语言中，我们常常会说 Everything is object，在 ClickHouse 中则常常会说 Everything is table；如果在 Java 语言中我们常常会说面向接口编程，那么在 ClickHouse 中则常常会说面向表引擎编程。

表引擎是 ClickHouse 设计上的一大特色，在其内部由 IStroage 接口表示。IStroage 是一个顶层接口，旗下有多个实现类，其中每一个 IStroage 的实现类都对应了一个具体的表引擎，如下图所示：

例如，StorageMergeTree 对应的是 MergeTree 表引擎，而 StorageMySQL 则对应了 MySQL 表引擎，其他的引擎以此类推。所以目前 IStroage 接口下有着 30 多种不同的表引擎实现，这么一看是不是觉得很丰富呢？

不过凡事都有两面性，当你看到这么多不同表引擎的时候，心中有没有一丝莫名的恐慌呢？哈哈，恐慌可能有点夸张了，但疑问肯定是会有的，比如为什么需要这么多的表引擎？这些表引擎都是干什么用的呢？以及我该使用哪种表引擎呢？

要弄明白为什么会有这么多表引擎，我就不得不谈一谈 ClickHouse 内部集成的设计哲学了。

高内聚的设计哲学

作为一款数据库，数据的存储和查询是它最基本的核心功能，其最终功能的载体是表，我们可以把它看做数据库的内部 IO。然而在一个真实的应用系统中，一款 OLAP 数据库不可能只和自己的内部 IO 打交道，它一定还会和某些外部系统进行互动，而这些外部系统通常会是上游的其他数据库、消息中间件或者是服务接口，一个最简单的例子就是 ClickHouse 需要从这些上游系统中导入数据。

架构师们在面临数据集成场景时通常有 2 种选择：

• 一种思路是走外部扩展的路线，即数据库只关心本职工作，与其他系统的联通全部交给这些外部系统自己处理；
• 另一种思路则是走内部集成的路线，即与外部系统的集成直接在数据库内部实现。

我在这里且不讨论哪种思路更优，单纯从现状来看 ClickHouse 的设计思路显然是选择了后者，即直接采取内部集成的方式。而从结果来看，这种高内聚的设计方法使 ClickHouse 显得非常“纯粹”。用户在使用 ClickHouse 的时候会觉得它非常轻便简单，以往需要很多复杂系统通力合作才能支撑的场景，现在只需要使用 ClickHouse 本身就能搞定了。

面向表编程

既然是内部集成，那么自然而然地就需要为程序设计一个扩展点。在 Java 体系的系统设计中，我们一直提倡面向接口编程，通过接口达到功能实现解耦的目的；而 ClickHouse 作为一款数据库，按照惯性的方式来思考，会很自然地想到将数据表作为与外部进行交互的接口层。进一步的，为了将表与具体功能实现的载体解耦，自然而然地也就引出了表引擎的概念。

一张数据表最终能够提供哪些功能、拥有哪些特性、数据会以什么格式被保存以及数据会怎样被加载，这些都将由它的表引擎决定。而对于用户而言，始终都只需要面对数据表本身，只需要使用 SQL 语言去查询，而无需关注它背后连接的到底是本地文件、ZooKeeper、HDFS 还是其他接口服务。这是不是一种很优雅的设计呢？

欢迎大家扫码关注我的公众号和视频号: