ClickHouse为什么那么快？
目录
一、MySQL数据库如何读区并查询数据的
以最常见的mysql为例，一条简单的查询语句是如何执行的，然后再以ck架构师的角度去考虑ck应该如何优化。mysql查数据时会先从磁盘读出数据所在页(innodb存储单元) 到内存中，然后再从内存中返回查询结果，所以在我们的认知中sql查询(排除语法词法解析，优化等步骤)总结起来可以为以下两点：
1.磁盘读取数据到内存
2.内存中解析数据匹配结果返回
在现代计算机中，CPU参与运算的时间远小于磁盘IO的时间。所以现代OLAP引擎大部分也选择通过降低磁盘IO的手段来提高查询性能，举例如下：
| 降低磁盘IO | 原理 | 举例 | 劣势 |
| 分布式 | 并行读取数据，降低单节点读取数据量 | hive(texfile) | 数据倾斜,网络耗时,资源浪费 |
| 列式存储 | 将每一列单独存储，按需读取 | hbase | 适合列使用单一的业务 |
二、ClickHouse存储架构
通过以上分析，我们可以得出OLAP查询瓶颈在于磁盘IO，那么ck的优化手段也是借鉴了以上措施，采用了MPP架构(大规模并行处理)+列式存储，拥有类似架构设计的其他数据库产品也有很多，为什么ck性能如此出众？接下来我们具体分析ck的核心特性，进一步体会ck架构师的巧妙的架构理念。
2.1 列式存储
行式存储：把同一行数据放到同一数据块中，各个数据块之间连续存储。
列式存储：把同一列数据放到同一数据块中，不同列之间可以分开存储。
2.2 BLOCK
ClickHouse能处理的最小单位是block，block是一群行的集合，默认最大为8192行。因为每一列单独存储，因此每个数据文件相比于行式存储更有规律，通过对block采用LZ4压缩算法，整体压缩比大致可以8:1。可以看出，ClickHouse通过出色的压缩比与block结构实现了批处理功能，对比海量数据存储下每次处理1行数据的情况，大幅减少了IO次数，从而达到了存储引擎上的优化。
2.3 LSM
LSM的思想: 对数据的修改增量保持在内存中，达到指定的限制后将这些修改操作批量写入到磁盘中，相比较于写入操作的高性能，读取需要合并内存中最近修改的操作和磁盘中历史的数据，即需要先看是否在内存中，若没有命中，还要访问磁盘文件
LSM的原理: 把一颗大树拆分成N棵小树，数据先写入内存中，随着小树越来越大，内存的小树会flush到磁盘中。磁盘中的树定期做合并操作，合并成一棵大树，以优化读性能。
ClickHouse通过LSM实现数据的预排序，从而减少磁盘的读取量。原理就是将乱序数据通过LSM在内存中排序，然后写入磁盘保存，并定期合并有重合的磁盘文件。ClickHouse的写入步骤可以总结为以下几点:
1.每一批次数据写入，先记录日志, 保证高可用机制
2.记录日志之后存入内存排序，后将有序结果写入磁盘，记录合并次数Level=0
3.定期将磁盘上Level=0或1的文件合并，并标记删除，后续物理删除
2.4 索引
ClickHouse的采用一级索引(稀疏索引)+二级索引(跳数索引)来实现索引数据定位与查询。一级索引记录每个block块的第一个，每次基于索引字段查询只需要确定查询第几个block块即可，避免一个查询遍历所有数据。如上述介绍，一个block块为8192行，那么1亿条数据只需要1万行索引，所以一级索引占用存储较小，可常驻内存，加速查询。 二级索引由数据的聚合信息构建而成，根据索引类型的不同，其聚合信息的内容也不同，跳数索引的目的与一级索引一样，也是帮助查询时减少数据扫描的范围，原则都是“排除法”，即尽可能的排除那些一定不满足条件的索引粒度。
另一方面可以发现，因ck存储引擎按有序集合存储，所以在索引结构上，并不需要再利用B+树排序特性来定位。所以在实际使用过程中，也不需要满足最左原则匹配，只要过滤条件中包含索引列即可。
2.5 向量化执行
向量化计算(vectorization)，也叫vectorized operation，也叫array programming，说的是一个事情：将多次for循环计算变成一次计算。为了实现向量化执行，需要利用CPU的SIMD指令。SIMD的全称是Single Instruction Multiple Data，即用单条指令操作多条数据。现代计算机系统概念中，它是通过数据并行以提高性能的一种实现方式 ( 其他的还有指令级并行和线程级并行 )，它的原理是在CPU寄存器层面实现数据的并行操作。
在计算机系统的体系结构中，存储系统是一种层次结构。典型服务器计算机的存储层次结构如图6所示。一个实用的经验告诉我们，存储媒介距离CPU越近，则访问数据的速度越快。
从左至右,距离CPU越远，则数据的访问速度越慢。从寄存器中访问数据的速度，是从内存访问数据速度的300倍，是从磁盘中访问数据速度的3000万倍。所以利用CPU向量化执行的特性，对于程序的性能提升意义非凡。ClickHouse目前利用SSE4.2指令集实现向量化执行。
三、ClickHouse的舍得
ClickHouse在追求极致性能的路上，采取了很多优秀的设计。如上述讲的列存、批处理、预排序等等。但是架构都有两面性，从一另方面也带来了一些缺点。
•高频次实时写入方面，因ck会将批量数据直接落盘成小文件，高频写入会造成大量小文件生成与合并，影响查询性能。所以ck官方也是建议大批低频的写入，提高写入性能。实际场景中建议在业务与数据库之间引入一层数据缓存层,来实现批量写入。
•查询并发问题，ClickHouse是采用并行处理机制，即一个查询也会使用一半cpu去执行，在安装时会自动识别cpu核数，所以在发挥查询快的优势下，也带来了并发能力的不足。如果过多的查询数堆积达到max_concurrent_queries阈值，则会报出too many simultaneous queries异常，这也是ck的一种限流保护机制。所以日常使用过程中注意慢sql的排查，并发请求的控制是保证ck高可用的关键
四、ClickHouse zookeeper高负载影响
ClickHouse ReplicatedMergeTree引擎强依赖zookeeper完成多副本选主，数据同步，故障恢复等功能，zookeeper在负载较高的情况下，性能表现不佳，甚至会出现副本无法写入，数据无法同步问题。分析ClickHouse对zookeeper相关的使用，以副本复制流程为例，ck对zookeeper频繁的分发日志、数据交换是引起瓶颈原因之一。
外界解决通用方案： 重新实现HaMergeTree引擎，降低对zookeeper日志的请求次数并减少存储的数据量，来达到降低对zookeeper的负载。
我们在实际生产中做的优化：
- 单一ClickHouse 挂载一块独立SSD磁盘（PCI-E更佳），不做RAID，CK的分片复制技术已经足够提供强大的数据安全性保障。
- 减少表实际分区数量。
- Zookeeper（虚拟机即可）单独挂载SSD（KVM 硬盘直通），另外关闭生产中无用的日志。
- Zookeeper 的服务器务必关闭交换分区。
备注：ClickHouse新版本已经剔除zookeeper了。
五、ClickHouse资源隔离的问题
1、依据不同用户的最大内存控制，在超过阈值时会杀死执行的 query。
2、得益于出色的CK进程即服务的理念，可以配合Docker / LXC做出色的进程级资源隔离，诸如CPU，内存，调度优先级等。