Clickhouse系列-第一节-概述

Posted 2021-09-13 cfcz48

clickhouse是俄罗斯yandex发布的一款支持OLAP的列式数据库管理系统。他最值得称道的是他的查询速度非常快，表一列出了clickhouse与其他各种数据相比的查询性能提升的倍数。

	clickhouse	Hive	mysql	greenplum
100min.	1	294.48	844.58	24.53
1bn.	1	/	/	18.68

表一 clickhouse与其他数据库性能比较（数据来源于clickhouse官网）

可以看出，在1亿条数据的情况下，clickhouse比hive平均快294倍，比MySQL快844倍，比greenplum快24倍。这种惊人的性能提升是非常令人吃惊的，这种惊人的性能背后一定有着优秀的架构设计。

clickhouse是一个非常优秀及经典的工程化项目，是人类计算机工程的结晶。为什么要定义成工程化呢，是因为clickhouse的内核对于查询速度的优化，大部分并没有创造新的理论，而是将前人的研究成功应用到了这个领域。举例来说，数据压缩方便使用的lz77算法。在存储引擎方便借鉴了leveldb的LSM算法……

为了揭开clickhouse背后的秘密，本系列将从三个部分对clickhouse进行分析，最终将clickhouse的性能的奥秘揭示在读者面前。

• 第一部分：原理。
• 第二部分：基本面：clickhouse的存储引擎和计算引擎的架构设计。
• 第三部分：clickhouse源码对于上述设计的实现。

第一部分原理，主要回答了一个问题：对于大数据联机分析中，影响查询速度的因素到底是什么？这个问题其实是所有内容的起源。为了解决这个问题，前人做了哪些改进？

第二部分基本面主要向读者揭示clickhouse在第一部分的基础上，如何进行了更进一步的优化。并且详细介绍了clickhouse的存储引擎的原理，供读者体会clickhouse在存储上的极致优化。当然，一个结构有其优点的同时，也同时必然地存在缺点。因此这一部分也会想读者分析clickhouse不擅长做的事情。介绍完了存储引擎，clickhouse在计算引擎也有一项伟大的工程创新——向量化计算引擎，本部分也会对其做一些分析。这两大引擎地架构设计共同组成了clickhouse的基本面。

第三部分则是从源码层面想读者展示clickhouse是如何实现第二部分地架构。这一部分也探讨了架构设计和源码编写之间的一些关系，有丰富经验地程序员其实能或多或少感觉到一点：代码的编写方式会影响架构设计的结果。我喜欢把架构设计成为一套系统的基本面，基本面决定了系统的上限，但编码的质量却有可能将这个上限拉得很低。再好的架构，如果编码出现问题，那么无法完全发挥架构的威力。比如如果使用了过多的锁，那么根据阿姆达尔定律，系统是无法达到架构设定的上限的。同时，编码质量也会影响复用性和易用性，这三者之间存在一些限制。本部分不会过多介绍这方面的内容，但是会就clickhouse的源码为读者分析clickhouse是如何处理这一部分问题的。这一部分我喜欢称其为微观架构，后续有机会的话，我会再写个专栏单独讲这个系列。本系列会直接使用里面的一些推论。当然读者也可以存在不同的反对意见，毕竟只是推论，欢迎大家与我一起探讨。

最后，本系列会简要介绍clickhouse的分布式架构，因为clickhouse在设计时突出了单机的处理能力，在分布式显得不是很上心，并没有使用太多的分布式技巧，这可能是开源版本没有将这一块开源出来。但根据现有的源码来看，clickhouse使用mpp架构，在分布式架构属于比较简单的设计。更多的分布式内容会在后续退出的其他系列中详细讲述。届时也会拿clickhouse来对比。

下面，开始我们的clickhouse之旅。