开源分析数据库ClickHouse和开源esProc SPL的性能对比_clickhouse 计算 q1,q2, q3(3)

最新推荐文章于 2024-09-17 09:15:00 发布

2401_84591984

最新推荐文章于 2024-09-17 09:15:00 发布

阅读量1k

点赞数 18

分类专栏：程序员文章标签：大数据面试学习

本文链接：https://blog.youkuaiyun.com/2401_84591984/article/details/138739315

版权

程序员专栏收录该内容

58 篇文章

订阅专栏

既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，涵盖了95%以上大数据知识点，真正体系化！

由于文件比较多，这里只是将部分目录截图出来，全套包含大厂面经、学习笔记、源码讲义、实战项目、大纲路线、讲解视频，并且后续会持续更新

需要这份系统化资料的朋友，可以戳这里获取

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

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

esProc SPL登场

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

仍然是跑TPC-H来看：

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：

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

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

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：

SELECT * FROM test.t ORDER BY amount DESC LIMIT 100

对比测试结果是这样的：

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

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

进一步的差距

差距还不止于此。

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

SQL3：

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

这种情况下，对比测试的结果是CH的计算时间翻倍，SPL则不变：

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

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


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

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

SQL4：

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

这个分组TopN测试的对比结果是下面这样的：

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