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 线程并行。
CK 还是在单表查询上性能不错,多表 join 天生有缺陷,有测试过 StarRocks 吗,听说多表 Join 挺强的
英文版
请问现在是否支持 clickhouse 作为数据源? 没有的话,后续有计划加入么?
支持,jdbc
请问一下,连接 clickhouse 数据源,选择什么数据库类型?驱动程序选择哪个呢?我看到默认配置是没有的。
IDE 新建 JDBC 数据源的时候找不到的就选:other。然后驱动类名和 URL 需要自己手动填写。