导读：ClickHouse速度快的秘诀在于——利用存储引擎的特殊设计充分减少磁盘I/O对查询速度的影响。

ClickHouse为什么查询速度快？本文来揭秘。

1

从存储引擎视角看

ClickHouse速度快的秘诀在于——利用存储引擎的特殊设计充分减少磁盘I/O对查询速度的影响。从用户提交一条SQL语句进行查询到终输出结果的过程中，大量的时间是消耗在了磁盘I/O上，在很多情况下，I/O所占用的时间可以达到整个时间的90%以上。对存储引擎磁盘I/O的优化可以获得非常大的收益。ClickHouse的存储引擎设计中大量优化的目的也是为了减少磁盘I/O。本节将从该视角对ClickHouse存储引擎的优化进行解读。

1、预排序

ClickHouse与传统事务数据库的一个不同之处在于ClickHouse写入数据文件的数据时有序的，这就是本节将要介绍的预排序：将数据在写入磁盘前进行排序，以保证数据在磁盘上有序。

预排序在数据库系统是一个被广泛使用的技术，在实现范围查找时，可以将大量的随机读转换为顺序读，从而有效提高I/O效率，降低范围查询时的I/O时间。在点查找时，预排序能做到和未排序数据相同的性能。因此，预排序可以在不降低点查找性能的情况下，有效提高范围查询的性能。

2、列存

列存数据库和行存数据库根本的区别在于列存数据库将一行数据拆分到多个数据文件中。在列存数据库中，同一列的所有数据都在同一个文件中，因此在硬盘上是连续的。这种特性特别适合OLAP的低范式查询场景。

3、压缩

ClickHouse的另一个降低I/O的手段是压缩，压缩可以减少读取和写入的数据量，从而减少I/O时间。并不是所有场景下都可以引入压缩的，很显然，压缩必然带来压缩和解压缩的CPU消耗，这是一个利用CPU时间换I/O时间的手段。事务数据库由于大部分情况下是针对行的操作，因此如果对每一行都进行一次压缩解压缩，带来的时间消耗是远大于磁盘I/O时间的。这就是事务数据库没有使用压缩技术的原因。

而ClickHouse则不同，ClickHouse的小处理单元是块，块一般由8192行数据组成，ClickHouse的一次压缩针对的是8192行数据，这就极大降低CPU的压缩和解压缩时间。同时，ClickHouse是列存数据库，同一列的数据相对更有规律，因此能够带来比较大的压缩比。因此，块+压缩在ClickHouse中成为一个非常关键的优化手段。

2

从计算引擎视角看

不同于存储引擎的设计，ClickHouse计算引擎的设计在很多方面都有着很大的争议，一方面向量化引擎的精妙设计让人拍案叫绝，另一方面相对粗糙的SQL解析和优化（解释）器也让ClickHouse在执行某些操作时让用户咬牙切齿。

1、 ClickHouse速度快的前提

在正式进入本节内容之前，我们首先需要明确一个前提：ClickHous不是在所有场景下都能获得很强的性能。因此，需要先分析ClickHouse在满足哪些前提下才能获得强的查询性能。

ClickHouse计算引擎精妙的设计在于向量化引擎，那么ClickHouse由于计算引擎原因导致的快，肯定是来自向量化引擎的加持。而ClickHouse的计算引擎导致的慢是因为缺乏代价优化器，那么由于计算引擎导致的慢也来自缺乏代价优化器带来的缺陷。基于这两个逻辑，我们可以分析出ClickHouse速度快的前提。

1）大量使用向量化运算

ClickHouse提供了很多内置函数，在使用这些内置函数时，ClickHouse会自动进行向量化优化。因此尽可能使用提供的内置函数进行计算，而不是自己写SQL语句。下面展示错误的SQL写法以及正确的写法。

SELECT (2/(1.0 + exp(-2 * x))-1) as tanh_x  ……    // 错误的写法SELECT tanh(x) as tanh_x ……    // 正确的写法，直接使用ClickHouse的内置函数

2）查询语句中没有使用Join子句，或尽可能少的使用Join操作

ClickHouse没有代价优化器，这导致了ClickHouse在Join操作时会出现内存不足等情况，导致查询失败。Join的性能问题其实并不仅仅是ClickHouse才遇到，任何数据库在遇到大表Join时都有可能导致查询时间暴增。

大数据中的Spark计算引擎对Join操作做了非常多的优化，借助其强大的CBO实现了Join算法的自动选择。更是在此基础上，通过AQE（Adaptive Query Execution,自适应查询引擎），解决了大表Join操作时遇到数据倾斜时的性能问题。

正是由于ClickHouse没有实现CBO，因此ClickHouse在实现Join操作时，选择余地很少。尤其是分布式大表Join操作时，ClickHouse只实现了广播连接（Broadcast Join）算法，极大地降低了ClickHouse的Join能力。

在使用ClickHouse时，应当尽可能避免Join操作。而Join操作在ODS建模的过程中大量存在。因此，ClickHouse在设计良好的DW上运行向量化查询的性能高。读者应该尽可能避免将ClickHouse用于ODS的建模工作中。当数据量大时，这类建模工作还是尽可能下推到Spark上执行。

2、ClickHouse快的本质

ClickHouse在满足上面提到的两个条件时，在不考虑存储引擎影响的情况下，应当能够在计算引擎上达到大的性能。ClickHouse计算引擎快的本质是利用了CPU提供的硬件加速特性。

除此之外，ClickHouse客观上的确在一些环节存在着一些问题，个人认为这些问题和ClickHouse的定位有关。ClickHouse在设计之初就给自身进行了清晰的定位——充分发挥单机性能的OLAP引擎。在此基础上，分布式的join能力其实并不重要，毕竟业界已经有Spark了，完全可以将ClickHouse建立在Spark之上，由Spark解决建模问题，由ClickHouse强大的DW分析能力实现OLAP的后一公里问题。

作为用户，我们应该清晰地了解ClickHouse速度快的前提，有意识地避开ClickHouse的雷区，不要将ClickHouse用于其不擅长的场景。正如此时此刻，大家都意识到了MySQL无法解决大数据量的OLAP问题，这类问题要通过专业的OLAP引擎解决。

开源社区要的并不是什么能力都有的但都不强的平庸的软件，而是百花齐放，各自有着各自擅长的领域，通过组合实现架构上的合力。以上仅代表作者个人观点，欢迎读者有不同意见，大家互相讨论。
 

3

总结

本文分别对ClickHouse的存储引擎和计算引擎进行了简单分析，分别得出了ClickHouse速度快的不同的前提。

存储引擎需求的前提如下。

• 使用MergeTree存储引擎。

• 按照业务需求，正确设置数据表的排序键，查询时需满足左原则。

计算引擎架构要求的前提如下。

• 没有或少用Join操作。

• 尽可能多地使用内置函数。

当满足如上4个条件时，使用ClickHouse才有可能达到比较的性能。