ClickHouse 到底有多神?

 

ClickHouse(简称 CH)是最近很受关注的开源分析数据库,据说挺神的,做 OLAP 计算很快。很多被性能问题折磨的用户都有兴趣尝试一下。

CH 到底是不是真有那么神呢?我们做一些对比测试来看看。

 

这里用 CH、Oracle(简称 Ora)和开源的集算器 SPL 一起做对比测试,测试基准是国际广泛认可的 TPC-H,针对 8 张表,完成 22 条 SQL 语句定义的计算需求(Q1 到 Q22)。在相同的软硬件环境下,比较 CH、Ora 和 SPL 完成计算需要的时间。

 

测试发现这么几个现象。

一、CH 做单表遍历计算的性能非常好,超过了 Ora 和 SPL,比如 TPC-H 的 Q1,对比情况如图 1:

..

                                      图 1:单表遍历简单查询性能比较(单位:秒)

Q1 是单表遍历的简单分组汇总,CH 跑的最快,SPL 次之,Ora 最慢。

这个结果说明,CH 的列式存储做的不错,单表遍历速度快。SPL 也使用了列存,但速度赶不上 CH,这一方面是因为 SPL 存储压缩可能不如 CH,另一方面 Java 实现的 SPL 计算性能也弱于 C++ 写的 CH,而 SPL 的高性能算法在这个简单运算中也派不上用场。而 Ora 主要吃亏在使用了行式存储,明显要慢得多了。

 

二、对于稍微复杂一些的查询,CH 的表现就比较差了。比如, Q2、Q3、Q7,涉及到多表连接、子查询等相对复杂一些的查询,对比情况如图 2:

 

..

                                      图 2:多表关联复杂查询性能比较(单位:秒)

这几个运算都是 SPL 最快。Q2 涉及数据量较少,列存作用不大,CH 性能和 Oracle 几乎一样。Q3 数据量较大,CH 还是占了列存的便宜后才超过了 Ora。Q7 数据也较大,但是计算复杂,CH 性能还不如 Ora。

在计算逻辑复杂之后,CH 的性能就开始急剧下降了。采用列式存储占了巨大的存储优势时,竟然能被 Ora 用行式存储赶上。这说明 CH 的算法优化能力很差,远远赶不上 Ora。而对于这些较复杂的运算,SPL 的算法优化就能得到体现,再加上列存优势,结果是 Java 写出来的程序跑赢了 C++ 写的 CH 和 Ora。

 

Q8 是更复杂一些的计算,子查询中有多表连接,CH 跑了 2000 多秒还没有出结果,应该是卡死了,Ora 跑了 192 秒,SPL 是 37 秒,最快。Q9 在 Q8 的子查询中增加了 like,CH 直接报内存不足的错误了,Ora 跑了 234 秒,SPL 是 68 秒,还是更快。其它还有些复杂运算是 CH 跑不出来的,就没法做个总体比较了。

 

综合上述测试来看,CH 并没有传说中那么神,简单的单表查询性能不错,复杂查询性能非常差。基本上可以断定,CH 的列式存储做得很好,但运算优化却可以说相当差。

对于希望用 CH 来提速的朋友,特别是希望能用 CH 来解决复杂查询甚至存储过程性能问题的朋友,那可能是想多了。

SPL 单表硬遍历比 CH 慢,但是复杂计算的性能却远远超过 CH。关键是,SPL 提供了丰富的数据类型,封装了大量的高性能算法,能用简洁的代码实现复杂计算。

对于复杂运算(包括存储过程),真有性能上的麻烦,SPL 才是合适的选择。

 

附:测试环境

CPU:2 颗 Intel3014,主频 1.7G,每个 CPU 内核数 6 个。

硬盘 (SSD):1T  561MB/s(读)   523MB/s(写)   接口:SATA 6.0Gb/s

内存:64G。

操作系统:Linux CentOS 7。

TPC-H 数据总规模 100G。所有测试都用 12 线程并行。