img
img

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

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

如果你需要这些资料,可以戳这里获取

FROM test.t
GROUP BY mod(id, 100)


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


![](https://img-blog.csdnimg.cn/48f39dc542ad480b8fc3d058d339cafe.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:



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


对比测试结果是这样的:


![](https://img-blog.csdnimg.cn/79842ca6bb6b4400b79acd86ee4473e7.png)


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


也就是说,无论简单运算还是复杂运算,esProc SPL都能更胜一筹。如果你想学习源代码的话,也是可以的。[SPL源代码](https://bbs.csdn.net/topics/618668825)


### 进一步的差距


差距还不止于此。


正如前面所说,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则不变:


![](https://img-blog.csdnimg.cn/59d198df901f4bf1b44cb733cfba323c.png)


这是因为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测试的对比结果是下面这样的:


![](https://img-blog.csdnimg.cn/d45beffa78b54ba49bb41b49f08d70f8.png)


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


而且,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的代码依然很简洁:




|  |  |  |
| --- | --- | --- |
|  | A  | B  |
| 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写法:





![img](https://img-blog.csdnimg.cn/img_convert/2505fd569d2535f20fe98d3c9d76ff0c.png)
![img](https://img-blog.csdnimg.cn/img_convert/81a6aff99c9fc233a418a54f72609044.png)

**既有适合小白学习的零基础资料,也有适合3年以上经验的小伙伴深入学习提升的进阶课程,涵盖了95%以上C C++开发知识点,真正体系化!**

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

**[如果你需要这些资料,可以戳这里获取](https://bbs.csdn.net/topics/618668825)**

伙伴深入学习提升的进阶课程,涵盖了95%以上C C++开发知识点,真正体系化!**

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

**[如果你需要这些资料,可以戳这里获取](https://bbs.csdn.net/topics/618668825)**

Logo

这里是“一人公司”的成长家园。我们提供从产品曝光、技术变现到法律财税的全栈内容,并连接云服务、办公空间等稀缺资源,助你专注创造,无忧运营。

更多推荐