关于clickhouse:Clickhouse系列第一节概述

clickhouse 是俄罗斯 yandex 公布的一款反对 OLAP 的列式数据库管理系统。他最值得称道的是他的查问速度十分快，表一列出了 clickhouse 与其余各种数据相比的查问性能晋升的倍数。

表一 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 之旅。