Clickhouse系列-第一节-概述

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

clickhouseHiveMySQLgreenplum
100min.1294.48844.5824.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之旅。

9,088条评论

  1. Hey There. I found your weblog the usage of msn. This is a very smartly written article. I’ll be sure to bookmark it and come back to learn more of your useful info. Thank you for the post. I will certainly comeback.

  2. Pingback: meritroyalbet
  3. Pingback: madridbet
  4. Pingback: meritroyalbet
  5. Pingback: child porn
  6. Pingback: grandpashabet