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

ClickHouse vs Oracle

先用ClickHouse（简称CH）、Oracle数据库（简称ORA）一起在雷同的软硬件环境下做比照测试。测试基准应用国内宽泛认可的TPC-H，针对8张表，实现22条SQL语句定义的计算需要（Q1到Q22）。测试采纳单机12线程，数据总规模100G。TPC-H对应的SQL都比拟长，这里就不具体列出了。

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

<img alt=".." src="http://img.raqsoft.com.cn/docx/1657614854913100.png">

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

然而，如果咱们加大计算复杂度，CH的体现怎么样呢？持续看TPC-H的Q2、Q3、Q7，测试后果如下：

<img alt=".." src="http://img.raqsoft.com.cn/docx/1657614854984100.png">

计算变得复杂之后，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来看 ：

<img alt=".." src="http://img.raqsoft.com.cn/docx/1657614855059100.png">

Q2、Q3、Q7这些较简单的运算，SPL比CH和ORA跑的都快。CH跑不出后果的Q8、Q9，SPL别离跑了37秒和68秒，也比ORA快。起因在于SPL能够采纳更优的算法，其计算复杂度低于被ORA优化过的SQL，更远低于CH执行的SQL，再加上列存，最终是用Java开发的SPL跑赢了C++实现的CH和ORA。

大略能够失去论断，esProc SPL无论做简略计算，还是简单计算性能都十分好。

不过，Q1这种简略运算，CH比SPL还是略胜了一筹。仿佛能够进一步证实后面的论断，即CH特地善于简略遍历运算。

且慢，SPL还有秘密武器。

SPL的企业版中提供了列式游标机制，咱们再来比照测试一下：在8亿条数据量下，做最简略的分组汇总计算，比照SPL（应用列式游标）和CH的性能。（采纳的机器配置比后面做TPC-H测试时略低，因而测出的后果不同，不过这里次要看相对值。）

简略分组汇总对应CH的SQL语句是：

SQL1：

<pre>SELECT mod(id, 100) AS Aid, max(amount) AS Amax
FROM test.t
GROUP BY mod(id, 100)
</pre>

这个测试的后果是下图这样：

<img alt=".." src="http://img.raqsoft.com.cn/docx/1657614855135100.png">

SPL应用列式游标机制之后，简略遍历分组计算的性能也和CH一样了。如果在TPC-H的Q1测试中也应用列式游标，SPL也会达到和CH同样的性能。

测试过程中发现，8亿条数据存成文本格式占用磁盘15G，在CH中占用5.4G，SPL占用8G。阐明CH和SPL都采纳了压缩存储，CH的压缩比更高些，也进一步证实CH的存储引擎做得的确不错。不过，SPL也能够达到和CH同样的性能，这阐明SPL存储引擎和算法优化做得都比拟好，高性能计算能力更加平衡。

以后版本的SPL是用Java写的，Java读数后生成用于计算的对象的速度很慢，而用C++开发的CH则没有这个问题。对于简单的运算，读数工夫占比不高，Java生成对象慢造成的连累还不显著；而对于简略的遍历运算，读数工夫占比很高，所以后面测试中SPL就会比CH更慢。列式游标优化了读数计划，不再生成一个个小对象，使对象生成次数大幅升高，这时候就能把差距拉回来了。单纯从存储自身看，SPL和CH相比并没有显著的优劣之分。

接下来再看惯例TopN的比照测试，CH的SQL是：

SQL2：

<pre>SELECT * FROM test.t ORDER BY amount DESC LIMIT 100</pre>

比照测试后果是这样的：

<img alt=".." src="http://img.raqsoft.com.cn/docx/1657614854638100.png">

单看CH的SQL2，惯例TopN的计算方法是全排序后取出前N条数据。数据量很大时，如果真地做全排序，性能会十分差。SQL2的测试后果阐明，CH应该和SPL一样做了优化，没有全排序，所以两者性能都很快，SPL稍快一些。

也就是说，无论简略运算还是简单运算，esProc SPL都能更胜一筹。

进一步的差距

差距还不止于此。

正如后面所说，CH和ORA应用SQL语言，都是基于关系模型的，所以都面临SQL优化的问题。TPC-H测试证实，ORA能优化的一些场景CH却优化不了，甚至跑不出后果。那么，如果面对一些ORA也不会优化的计算，CH就更不会优化了。比如说咱们将SQL1的简略分组汇总，改为两种分组汇总后果再连贯，CH的SQL写进去大抵是这样：

SQL3：

<pre>SELECT *
FROM (
SELECT mod(id, 100) AS Aid, max(amount) AS Amax
FROM test.t
GROUP BY mod(id, 100)
) A
JOIN (
SELECT floor(id / 200000) AS Bid, min(amount) AS Bmin
FROM test.t
GROUP BY floor(id / 200000)
) B
ON A.Aid = B.Bid</pre>

这种状况下，比照测试的后果是CH的计算工夫翻倍，SPL则不变：

<img alt=".." src="http://img.raqsoft.com.cn/docx/1657614854774100.png">

这是因为SPL不仅应用了列式游标，还应用了遍历复用机制，能在一次遍历过程中计算出多种分组后果，能够缩小很多硬盘访问量。CH应用的SQL无奈写出这样的运算，只能靠CH本身的优化能力了。而CH算法优化能力又很差，其优化引擎在这个测试中没有起作用，只能遍历两次，所以性能降落了一倍。

SPL实现遍历复用的代码很简略，大抵是这样：

AB
1=file("topn.ctx").open().cursor@mv(id,amount)
2cursor A1=A2.groups(id%100:Aid;max(amount):Amax)
3cursor=A3.groups(id\200000:Bid;min(amount):Bmin)
4=A2.join@i(Aid,A3:Bid,Bid,Bmin)

再将SQL2惯例TopN计算，调整为分组后求组内TopN。对应SQL是：

SQL4：

<pre>SELECT
gid,
groupArray(100)(amount) AS amount
FROM
(
SELECT

  mod(id, 10) AS gid,  amount

FROM test.topn
ORDER BY

  gid ASC,  amount DESC

) AS a
GROUP BY gid</pre>

这个分组TopN测试的比照后果是上面这样的：

<img alt=".." src="http://img.raqsoft.com.cn/docx/1657614854827100.png">

CH做分组TopN计算比惯例TopN慢了42倍，阐明CH在这种状况下很可能做了排序动作。也就是说，状况复杂化之后，CH的优化引擎又不起作用了。与SQL不同，SPL把TopN看成是一种聚合运算，和sum、count这类运算的计算逻辑是一样的，都只须要对原数据遍历一次。这样，分组求组内TopN就和分组求和、计数一样了，能够防止排序计算。因而，SPL计算分组TopN比CH快了22倍。

而且，SPL计算分组TopN的代码也不简单：

A
1=file("topn.ctx").open().cursor@mv(id,amount)
2=A1.groups(id%10:gid;top(10;-amount)).news(#2;gid,~.amount)

不只是跑得快

再来看看电商零碎中常见的漏斗运算。SPL的代码仍然很简洁：

AB
1=["etype1","etype2","etype3"]=file("event.ctx").open()
2=B1.cursor(id,etime,etype;etime>=date("2021-01-10") && etime<date("2021-01-25") && A1.contain(etype) && …)
3=A2.group(id).(~.sort(etime))=A3.new(~.select@1(etype==A1(1)):first,~:all).select(first)
4=B3.(A1.(t=if(#==1,t1=first.etime,if(t,all.select@1(etype==A1.~ && etime>t && etime<t1+7).etime, null))))
5=A4.groups(;count(~(1)):STEP1,count(~(2)):STEP2,count(~(3)):STEP3)

CH的SQL无奈实现这样的计算，咱们以ORA为例看看三步漏斗的SQL写法：

<pre>with e1 as (

select gid,1 as step1,min(etime) as t1from Twhere etime>= to_date('2021-01-10', 'yyyy-MM-dd') and etime<to_date('2021-01-25', 'yyyy-MM-dd')   and eventtype='eventtype1' and …group by 1

),
with e2 as (

select gid,1 as step2,min(e1.t1) as t1,min(e2.etime) as t2from T as e2inner join e1 on e2.gid = e1.gidwhere e2.etime>= to_date('2021-01-10', 'yyyy-MM-dd') and e2.etime<to_date('2021-01-25', 'yyyy-MM-dd') and e2.etime > t1   and e2.etime < t1 + 7   and eventtype='eventtype2' and …group by 1

),
with e3 as (

select gid,1 as step3,min(e2.t1) as t1,min(e3.etime) as t3from T as e3inner join e2 on e3.gid = e2.gidwhere e3.etime>= to_date('2021-01-10', 'yyyy-MM-dd') and e3.etime<to_date('2021-01-25', 'yyyy-MM-dd') and e3.etime > t2   and e3.etime < t1 + 7   and eventtype='eventtype3' and …group by 1

)
select

sum(step1) as step1,sum(step2) as step2,sum(step3) as step3

from

e1left join e2 on e1.gid = e2.gidleft join e3 on e2.gid = e3.gid</pre>

ORA 的SQL写进去要三十多行，了解起来有相当的难度。而且这段代码和漏斗的步骤数量相干，每减少一步数就要再减少一段子查问。相比之下，SPL就简略得多，解决任意步骤数都是这段代码。

这种简单的SQL，写进去都很吃力，性能优化更无从谈起。

而CH的SQL还远不如ORA，基本上写不出这么简单的逻辑，只能在内部写C++代码实现。也就是说，这种状况下只能利用CH的存储引擎。尽管用C++在内部计算有可能取得很好的性能，但开发成本十分高。相似的例子还有很多，CH都无奈间接实现。

总结一下：CH计算某些简略场景（比方单表遍历）的确很快，和SPL的性能差不多。然而，高性能计算不能只看简略状况快不快，还要衡量各种场景。对于简单运算而言，SPL不仅性能远超CH，代码编写也简略很多。SPL能笼罩高性能数据计算的全场景，能够说是完胜CH。

SPL材料

  • SPL下载
  • SPL源代码