ClickHouse为何能超越Elasticsearch？

背景

Elasticsearch是一个强大的分布式全文检索和数据分析引擎，也是日志分析系统经常使用的一种实现方案，但近年来随着ClickHouse的发展，Elasticsearch在日志分析领域的地位逐渐被取代，许多公司已经将自己的日志分析解决方案从ES迁移到了ClickHouse，比如阿里、bilibili、快手等公司，公司内部有一些团队的数据分析业务也从ES迁移到了ClickHouse。为什么ClickHouse会受到越来越多人的青睐？它与ES相比有什么过人之处？

ClickHouse是俄罗斯搜索巨头Yandex公司于2016年开源的一个列式数据库管理系统，是面向列式存储的关系型数据库，这两年来Clickhouse凭借其极致的性能，成为OLAP领域的后起之秀，发展速度非常快。下面将从数据存储成本、数据写入吞吐量、数据查询速度三个方面详细分析ClickHouse的优势。

数据存储成本

传统的关系型数据库都是面向行存储，而ClickHouse是面向列存储。列式存储有什么优势呢？

行式存储

行式存储在物理上是逐行存储的，每行的数据在物理上是连续的。

列式存储

列式存储在物理上是逐列存储的，每列的数据在物理上是连续的，ClickHouse每列的数据存储在一个单独的文件中。

列式存储为什么能够降低数据的存储成本呢？因为列式存储更有利于数据的压缩。ClickHouse 采用列式存储，同一列的数据在物理上是连续的，且数据在存储时是经过排序的，这样数据的局部规律性非常强，有利于获得更高的数据压缩比。此外，ClickHouse 除了支持 LZ4、ZSTD 等通用压缩算法外，还支持 Delta、DoubleDelta、Gorilla 等专用编码算法，能够进一步提高数据压缩比。

而ES存储数据时，默认对数据按行存储一份，按列存储一份，并且数据的压缩比没有ClickHouse高。对于相同的数据，ClickHouse占用的磁盘空间只有ES的1/3到1/30，因此ClickHouse更节省磁盘空间，数据存储成本更低。

数据写入吞吐量

ES的数据写入过程

ES在进行数据存储时首先会将数据存到内存中，过一段时间后才会存到磁盘。具体写入过程如下：

写入一个新文档时，首先会对其进行索引，写入到Lucene内存中，此时新写入的文档还不能被检索到。当达到默认的刷新时间或Lucene内存中的数据达到一定量后，会触发一次refresh，Lucene内存中的数据会以一个新的段（segment）的形式刷新到文件缓存系统（也是内存）中，此时新写入的文档数据便能被检索到了。文件缓存系统中的数据需要再等到一定时间或达到一定量才会生成一个新的段，强制flush到磁盘，ES会在后台对这些段进行合并。为防止内存数据丢失，ES对于每一次的写入会追加一条记录到事务日志（TransLog），追加的事务日志也会先保存在内存中，经过一定时间或数据达到一定量才会flush到磁盘。

ClickHouse的数据写入过程

ClickHouse的数据写入更加直接，不会先存到内存再刷新到磁盘，而是直接存到磁盘上，因此也省略了传统的redo日志阶段。ClickHouse建议客户端以相当大的批量写入数据（建议不少于1000行，最好是在10000-100000行），支持海量数据的批量插入，每次插入都会创建一个新的DataPart，每个DataPart中数据按主键排序。ClickHouse支持使用分区键来对数据进行分区，数据插入时属于不同分区的数据会生成不同的DataPart，ClickHouse后台会高效合并这些分区的DataPart，不同分区的DataPart不会合并。每个DataPart都会有一个主索引，DataPart合并时每个DataPart的主索引也会合并。

可以看到，ClickHouse批量写入时，不会去修改已有数据，而是直接创建一个新的DataPart，快速写入，后台再对DataPart进行合并，不需要记录redo日志，而且ClickHouse的写入批量非常大，因此ClickHouse能够支持很大的写入吞吐量，单服务器日志写入量在50MB～200MB/s，每秒写入超过60w记录数，是ES的5倍以上。另外，对于副本同步，ES要求实时同步，写入请求必须同步完所有的副本之后才会返回响应，而ClickHouse使用ZooKeeper的异步磁盘文件同步，不需要同步完所有副本才返回响应。

数据查询速度

ClickHouse在存储层面和计算层面的精心设计使得它的数据查询速度也很快。

存储层面

列式存储及数据压缩

ClickHouse的数据存储是面向列的，列式存储方式对于统计、聚类分析场景具有天然的优势。数据分析行为通常会在列维度上进行，在行存模式下，数据按行连续存储，数据分析时会从存储系统读取所有满足条件的行数据，然后在内存中过滤出需要的字段，这样不参与计算的列也要在IO时全部读出，读取操作被严重放大，导致查询速度慢。

在列存模式下，只需要读取参与计算的列即可，避免多余的数据读取，极大降低了IO消耗，加速查询。

另外，如上文提到的，列式存储使得数据具有更高的压缩比，这就意味着数据量更小，从磁盘读取响应的数据时耗时会更短，也能够加速查询。

数据有序存储

ClickHouse支持在建表时指定排序键，数据存储时会按照排序键进行有序存储，这样的话具有相同排序键的数据在磁盘上会连续存储。在进行等值、范围查询时，查询条件命中的数据都紧密存储在一个或若干个连续的Block中，而不是分散地存储在任意多个Block，这会大幅减少需要IO的Block数量，从而加速查询。另外，连续IO也能够充分利用操作系统page cache的预取能力，减少缺页错误。

数据分区

ClickHouse支持数据分区，在建表时可以指定按照任意列的表达式对数据进行分区操作，比如按月、按天或按事件类型等，不同分区的数据是分开存储的，查询时如果条件包含分区键，ClickHouse会自动排除一些分区。结合业务特点，选择合适的分区表达式，能有效提升查询效率。

主键索引

ClickHouse支持主键索引，它将每列数据按照索引粒度（index_granularity，默认为8192行）进行划分，得到一个一个的索引颗粒（granule），主键索引中存储每个索引颗粒第一行的主键值。

如果在查询时，查询条件含有主键，ClickHouse会利用主键索引进行二分查找，能够直接定位到对应的索引颗粒，避免全表扫描，从而加速查询。

二级索引

使用“非主键”字段查询时，由于不能使用主索引，查询速度会慢很多。ClickHouse支持对任意列创建任意数量的二级索引，即跳数索引，使ClickHouse在查询时跳过那些肯定不匹配的数据块，在特定情况下可以显著提高查询速度。目前支持的跳数索引类型包括：

计算层面

多核并行

ClickHouse支持将数据划分为多个分区，每个分区再进一步划分为多个索引颗粒，ClickHouse利用CPU的多个核分别处理各个数据部分，实现数据并行处理。在这种设计下，单条查询就能利用整机所有CPU，极致的并行处理能力，极大地降低了查询延时。

分布式计算

除了优秀的单机并行处理能力，ClickHouse还提供了可线性拓展的分布式计算能力。在ClickHouse中，数据可以保存在不同的分片，每一个分片都由一组用于容错的副本组成，查询可以并行地在所有分片上进行处理（对用户透明），从而提升查询效率。

向量化执行

什么是向量化执行？简单理解就是，为了制作m杯果汁，非向量化执行的方式是用1台榨汁机重复循环执行m次，而向量化执行的方式是用m台榨汁机只执行1次。列式存储为数据的向量化执行提供了条件，ClickHouse 实现了一套向量引擎，大量的处理操作都是向量化执行的。ClickHouse利用CPU的SIMD指令，使CPU能够按向量（列的一部分）来处理数据，这种方式能够更加高效利用CPU，加速执行效率，从而提升查询效率。

近似计算

ClickHouse支持通过近似计算来加速查询。近似计算以损失一定结果精度为代价，极大地提升查询性能，在海量数据处理中，近似计算价值更加明显。ClickHouse实现了多种近似计算功能：

•用于近似计算的各类聚合函数，如：distinct values,中位数,分位数。

•基于数据的部分样本进行近似查询。

•不使用全部的聚合条件，通过随机选择有限个数据聚合条件进行聚合。

总之，ClickHouse通过减少磁盘IO、增强数据并行计算等方式优化查询，使得ClickHouse具备很快的查询速度，官方宣称，数据在page cache的情况下，单服务器查询速率大约在2-30GB/s，没在pagecache的情况下，查询速度取决于磁盘的读取速率和数据的压缩率。

总结

ClickHouse还有一些其他的优点，比如异步的多主复制技术，能保证系统在不同副本上保持相同的数据，大多情况下能故障后自动恢复；采用SQL语法，比ES的DSL更加简单，学习成本更低……

另外，ClickHouse也有一些缺点：

•没有完整的事务支持。

•无法像ES一样提供全文检索功能。

•无法动态添加字段，需要提前定义好表schema。

•无法支持高并发查询，默认配置QPS为100。

•不适合高频地写入，否则会导致后台合并无法跟上新分区数量。

总的来说，在数据分析场景下，ClickHouse相比ES具有更多的优势，而ES主要优势体现在全文检索上，适合完全搜索场景。当然，没有一个系统能够完全适合所有场景，两者的侧重点不同而已，在OLAP领域，ClickHouse在数据存储成本、写入吞吐量、查询速度等方面都有一定的优势，更适合低成本、大数据量的分析场景。

原文地址：https://blog.csdn.net/qq_32069845/article/details/130586376