ClickHouse 挺快，esProc SPL 更快

开源分析数据库 ClickHouse 以快著称，真的如此吗？我们通过对比测试来验证一下。

ClickHouse vs Oracle

先用 ClickHouse（简称 CH）、Oracle 数据库（简称 ORA）一起在相同的软硬件环境下做对比测试。测试基准使用国际广泛认可的 TPC-H，针对 8 张表，完成 22 条 SQL 语句定义的计算需求（Q1 到 Q22）。测试采用单机 12 线程，数据总规模 100G。TPC-H 对应的 SQL 都比较长，这里就不详细列出了。

Q1 是简单的单表遍历计算分组汇总，对比测试结果如下：

 

CH 计算 Q1 的表现要好于 ORA，说明 CH 的列式存储做得不错，单表遍历速度很快。而 ORA 主要吃亏在使用了行式存储，明显要慢得多了。

但是，如果我们加大计算复杂度，CH 的表现怎么样呢？继续看 TPC-H 的 Q2、Q3、Q7，测试结果如下：

 

计算变得复杂之后，CH 性能出现了明显的下降。Q2 涉及数据量较少，列存作用不大，CH 性能和 ORA 几乎一样。Q3 数据量较大，CH 占了列存的便宜后超过了 ORA。Q7 数据也较大，但是计算复杂，CH 性能还不如 ORA。

做复杂计算快不快，主要看性能优化引擎做的好不好。CH 的列存占据了巨大的存储优势，但竟然被 ORA 用行式存储赶上，这说明 CH 的算法优化能力远不如 ORA。

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

CH 和 ORA 都基于 SQL 语言，但是 ORA 能优化出来的语句，CH 却跑不出来，更证明 CH 的优化引擎能力比较差。

坊间传说，CH 只擅长做单表遍历运算，有关联运算时甚至跑不过 MySQL，看来并非虚妄胡说。想用 CH 的同学要掂量一下了，这种场景到底能有多大的适应面？

esProc SPL 登场

开源 esProc SPL 也是以高性能作为宣传点，那么我们再来比较一下。

仍然是跑 TPC-H 来看 ÿ