为什么需要Clickhouse

权露

Clickhouse是现在流行的OLAP数据库之一，虽然名声如雷贯耳，但在人们心目中总有一个疑问，到底为什么需要Clickhouse，是哪些优点让字节、腾讯这些大公司都选择它作为最推荐的OLAP数据库。

Clickhouse

Clickhouse是一个开源使用列式存储的OLAP数据库，最初由Yandex公司开发，现在从Yandex拆分出来并成立了独立的Clickhouse Inc.，其功能类似于Google Analytics。它的目标是处理数万亿行和数PB的数据，并快速执行分析和查询。

Clickhouse等OLAP数据库通常用于回答诸如“昨天有多少人访问掘金？昨天有多少人访问CSDN”之类的业务问题。如果使用传统的OLTP数据库来处理，可能需要几分钟甚至几个小时。而如果使用OLAP数据库，几毫秒就可以得到结果。OLTP和OLAP之间的巨大速度差异是因为使用的底层存储结构不同，OLTP数据库通常使用行式存储，OLAP则通常使用列式存储。

列式存储中的每一行数据都是分开存储的。如果需要统计访问次数，数据库首先需要从访问域名列中找到对应的ID，然后再对ID的访问次数列求和。这样数据库就不需要再跨很多磁盘页来检索数据，因为它只需要先获取满足条件的列数据。这就是为什么使用列式存储的数据库进行分析查询，比使用行式存储的数据库快很多。

Clickhouse改变了游戏规则

Clickhouse是一个支持多种数据存储引擎的数据库，几乎支持将任何数据源导入到Clickhouse数据库中，并支持快速灵活的下钻分析。比如，现在微信就使用Clickhouse来存储日志数据，因为日志里面通常有非常多的重复值，使用Clickhouse可以得到非常高的压缩率，减少日志占用的存储空间。Cloudflare，Mux，Plausible，GraphCDN，Panelbear等公司则使用Clickhouse存储流量数据，并在其仪表板中向用户呈现相关报告。而Percona正在使用Clickhouse来存储和分析数据库性能指标。

什么场景不适合Clickhouse

Clickhouse并不能取代关系型数据，也不是为了处理事务性数据而开发的，Clickhouse更多是作为OLTP补充，方便用来进行数据分析。如果需要对数据进行更新和删除，或者需要进行多表关联，那么不推荐使用Clickhouse。

另外也要避免把Clickhouse用作OLTP数据库的副本。当然从技术上讲，我们可以把OLTP數据库的数据通过事件的方式同步到Clickhouse，但好的做法是使用Clickhouse作为数据的真实来源，而不是作为OLTP数据库的镜像。

Clickhouse的优点

开源社区很活跃

在评估开源软件的时候，我们必须考虑它的社区是否活跃，如果使用了一个开源软件，但是这个开源软件突然就不维护了，就会让人很尴尬。比如之前阿里的Dubbo。当然这种情况在开源的世界里面并不少见，需要尽可能地使用有大公司或组织背书的开源软件。如果选择使用Clickhouse就不需要担心这些。不管是国内的字节、腾讯、阿里，还是国外的Cloudflare，eBay，Spotify，这些业界知名的公司都在使用Clickhouse。

飞快的查询速度

根据Marko Medojevic的报告，如果对11 MB数据集进行分析查询，Clickhouse的查询速度会比MySQL快约260倍。然而，也许这种比较并不公平，因为MySQL毕竟是OLTP数据库，但这也从侧面反应了OLAP数据库的优势所在。

Clickhouse实现的性能来自其独特的数据库引擎Merge Tree，而且Clickhouse也比较趋向于使用通用的硬件来做查询性能优化。

小索引（稀疏索引）

大家都知道在数据库中快速查找数据的关键是索引。索引保存在内存中以便快速访问，在OLTP数据库中，索引通常使用B+树来进行存储。

这适用于OLTP数据库，因为主键本质上是必不可少的。在OLTP数据库中，通常是通过主键ID查询数据库，但是，一旦数据增长到数十亿行并且索引在内存中放不下的时候，这种类型的索引局限性就非常明显。

Clickhouse使用的索引和Kafka类似，其仅存储索引数据的子集。这样的好处是索引相对较小，就算是很大的数据量，其索引在内存里面也放得下。

想象一下如果要使用SELECT SUM（visit）FROM visit WHERE date BETWEEN 2022-10-01 AND 2022-10-31进行查询，数据库使用稀疏索引的方式就很合适，因为查询条件是日期范围，而不是主键ID。这就是为什么稀疏索引在OLAP数据库中经常使用的原因。

数据压缩

由于Clickhouse的数据是按列而不是按行存储的，所以它能够比行式数据库更好地压缩数据。有数据表明，同样的数据放在Clickhouse相比放在PostgreSQL，所需的磁盘空间减少了70 %。另外在Clickhouse中，可以方便地指定列的数据压缩算法和压缩级别。

数据TTL

通常不建议无限制的存储数据，这样会浪费非常多的磁盘空间。一般情况下，设置一个合适的数据保留时间是比较好的选择。在Clickhouse中，可以通过在创建表时设置数据的TTL轻松做到这一点。

适配多种语言

Clickhouse的社区非常活跃，现在就已经支持Java，Go， Python等流行语言的SDK，如果使用Perl小众语言，Clickhouse也支持通过HTTP接口操作访问数据。

水平可扩展和高可用

Clickhouse在构建时就考虑了水平可扩展性和高可用性。我们可以将数据分片到多个节点并将数据复制到另一组服务器中。当然水平可扩展性和高可用性功能会带来额外的复杂度，如果我们使用Kubernetes部署Clickhouse，可以使用Clickhouse Kubernetes Operator进行配置。

实话说，现在如果有数据分析的场景，个人想到的方案就是使用Clickhouse，如果再结合一下Superset等开源BI工具，我们就可以非常快速地搭建起来轻量的数据分析系统，这对于大多数中小公司来说就已经完全够用了。最后，如果想快速试用一下，推荐使用docker进行安装。