你感觉ClickHouse牛在哪儿 相比于MySQL 面试官

有时刻真的挺替MySQL鸣不平的，被最宽泛地运行在各个系统中，却当着Redis、ES、Oracle的背景板，挨着最狠地骂。

嗯，当天又拿它跟OLAP数据库ClickHouse启动比拟了。

普通来讲，90%多的Java工程师是接触不到ClickHouse的，而用到它的最大要素，无非是拿MySQL硬抗海量数据的统计剖析类的场景真实太费力了，临战换将成ClickHouse之后，顿觉环球时如此美妙。

接上去咱们就来说说，ClickHouse究竟有多牛逼，以及牛逼在哪儿。

在一系列官方发布的基准测试对比中，ClickHouse都遥遥上游对手，这其中不乏一些咱们耳熟能详的名字。

一切用于对比的数据库都经常使用了相反性能的主机，在单个节点的状况下，对一张领有133个字段的数据表区分在1000万、1亿和10亿三种数据体量下口头基准测试，基准测试的范围涵盖43项SQL查问。

在1亿数据群体量的状况下，ClickHouse的平均照应速度是Vertica的2.63倍、InfiniDB的17倍、MonetDB的27倍、Hive的126倍、MySQL的429倍以及Greenplum的10倍。

下图也是ClickHouse官方上发布的测试数据：

接上去咱们详细剖析一下，ClickHouse究竟具有那些个性，以致于它比MySQL的性能高出如此之多。

ClickHouse驳回典型的MPP（Massively Parallel Processing）架构，直译为大规模并行处置架构，可将义务并行的扩散到多个节点上，每个节点各自独立成功自己的计算义务，而后将各节点的处置结果启动二次加工汇总，构成最终的结果启动前往。

MPP架构中的各个计算节点相互独立，具有高性能和易裁减的好处，可在海量数据下成功高吞吐量和低提前的数据处置才干。

而MySQL InnoDB自身是不具有散布式并行计算才干的，普通状况下都是用分库分表两边件启动成功的，也有少局部是间接在工程代码中启动成功。

当然，从完善度友好滑性来讲，必需是不如ClickHouse的一体化处置方案的。

假定这样的一个业务场景，一张有2000多万条记载的people表，咱们须要计算出表中一切人的平均年龄。

对MySQL InnoDB存储引擎比拟相熟的同窗都知道，其存储结构是依照表空间（tablespace）——>段（segment）——>区（extent）——>page（页）的方式启动组织的，而page是MySQL InnoDB的最小IO单元，默以为16k。

而page中存储的才是MySQL InnoDB的行记载（row），每行记载中有若干个列字段值。

那么，关于MySQL InnoDB存储引擎的行式数据库来说，假设须要计算people全表的平均年龄，那就须要以page为IO单元全表扫描出一切数据，再把外面的age数据挑进去启动计算，才干得出最终的结果。

而Clickhouse的存储方式则齐全不一样了，它是以数据列的方式启动组织存储的，每个列字段都领有独立的.bin数据文件，并以列字段的称号命名。

假设须要计算people全表的平均年龄的话，ClickHouse只要要读取age.bin文件中的数据启动计算即可。

这样一来，假定people表中有20个字段，关于计算出表中一切人的平均年龄的需求，ClickHouse所须要读取的数据量只要MySQL InnoDB的大概1/20，那人造想性能不高都难。

咱们来看一下，ClickHouse官方关于行式存储和列式存储的对比配图，还是比拟笼统的。

列式存储：

由于紧缩后的数据不只可以节俭存储空间，还可以缩小磁盘IO和网络传输的数据量，这是高性能数据库必无法少的个性。

并且，ClickHouse列式数据库比MySQL InnoDB存储引擎的行式数据库，对数据紧缩愈加友好。

要素在于，在ClickHouse最罕用的数据表中的同一列数据是保留在一个文件里的，其领有相反的数据类型和业务语义，重复项的或者性人造就很高。比如：订单金额、团体年龄、上班支出等。

而重复项越高，文件紧缩率和数据体量就越小，也就越能缩小磁盘IO和网络传输的压力。

ClickHouse自动经常使用LZ4算法启动数据紧缩的，紧缩比可以到达8:1。

再来说说MySQL InnoDB，可以经过如下SQL语句启动数据紧缩，但紧缩成果普通，仅可以节俭30%到50%的磁盘空间。

  sbtest1 ROW_FORMATCOMPRESSED KEY_BLOCK_SIZE

并且经过性能测试得悉，数据紧缩对数据库主机的负载和CPU经常使用率影响较大，在性能上也并无优化。

这样看来，MySQL InnoDB的数据紧缩仅能节俭有限的磁盘空间，成果比拟鸡肋。

像Flink、Spark、Storm这些散布式计算框架，会将一个大义务拆解成若干个可以并行口头的小义务，以此来优化全体的义务处置吞吐量。

而ClickHouse为了最大限制地将CPU的性能压迫到极致，成功了向量化口头引擎，其外围现实是 充沛应用现代处置器的并行处置才干，来优化代码口头效率。

向量化口头引擎可以对一组数据口头相反的一个指令，在访问速度最快的寄存器层面成功单指令、少数据 （SIMD ）操作，以成功空间上的并行。

各配件访问速度对比，如下图：

ClickHouse与MySQL InnoDB的索引设计方式一模一样，它的一级索引是驳回稀疏索引的方式启动成功的。

在上图左侧的浓密索引中，索引标志和数据记载是逐一对应的，而图右侧的稀疏索引则对应的是蕴含N行记载的一个数据块。

稀疏索引的好处是，仅须要大批索引标志就可以记载海量数据的区间位置信息。假设索引粒度是自动的8192，那一亿条数据仅须要对应12208个索引标志，这样就可以将索引标志放到内存中，可以起到优化查问性能的成果。

在二级索引方面，MySQL InnoDB只允许B+ Tree和Hash两种类型，而ClickHouse则允许minmax、set、bloom_filter、ngrambf_v1、tokenbf_v1和inverted等索引类型。

minmax索引，用来记载N（N = granularity）个数据块内的最大值和最小值，在对某列数据启动范围查问的时刻，可以过滤掉不满足条件的数据区间，其实用于数据区分度比拟高的场景。

set索引，用来记载每个数据块中的不重复值，举个例子，假设该数据块所对应的列中有8000个1，190个2，1个3和1个4，那set中所记载的值就是（1,2,3,4）。

set索引的实用场景为，在区分度低的列上查找列值很少的数据行。比如：在订单表中查问形态为“退款”的订单。

bloom_filter索引，望文生义，是用来构建布隆过滤器的，自动有0.025（可调整）的误差率，会将原本不存在的值误以为已存在。但用在二级索引上是不影响正确性的，仅仅是多查问了一些数据块而已。