一个比ClickHouse还快的开源数据库(1)

简介: 一个比ClickHouse还快的开源数据库


开源分析数据库 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 来看 :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:




这个测试的结果是下图这样: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 amountFROM(      SELECT    mod(id, 10) AS gid,    amount      FROM test.topn      ORDER BY    gid ASC,    amount DESC) AS aGROUP BY gid

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

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


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




































with e1 as (    select gid,1 as step1,min(etime) as t1    from T    where 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 t2    from T as e2    inner join e1 on e2.gid = e1.gid    where 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 t3    from T as e3    inner join e2 on e3.gid = e2.gid    where 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 step3from  e1    left join e2 on e1.gid = e2.gid    left join e3 on e2.gid = e3.gid

ORA 的 SQL 写出来要三十多行,理解起来有相当的难度。而且这段代码和漏斗的步骤数量相关,每增加一步数就要再增加一段子查询。相比之下,SPL 就简单得多,处理任意步骤数都是这段代码。这种复杂的 SQL,写出来都很费劲,性能优化更无从谈起。而 CH 的 SQL 还远不如 ORA,基本上写不出这么复杂的逻辑,只能在外部写 C++ 代码实现。也就是说,这种情况下只能利用 CH 的存储引擎。虽然用 C++ 在外部计算有可能获得很好的性能,但开发成本非常高。类似的例子还有很多,CH 都无法直接实现。


总结一下:CH 计算某些简单场景(比如单表遍历)确实很快,和 SPL 的性能差不多。但是,高性能计算不能只看简单情况快不快,还要权衡各种场景。对于复杂运算而言,SPL 不仅性能远超 CH,代码编写也简单很多。SPL 能覆盖高性能数据计算的全场景,可以说是完胜 CH。


相关文章
|
2月前
|
NoSQL 关系型数据库 MySQL
开源数据库
【8月更文挑战第26天】开源数据库
54 11
|
1月前
|
存储 SQL 缓存
数据库测试|Elasticsearch和ClickHouse的对决
由于目前市场上主流的数据库有许多,这次我们选择其中一个比较典型的Elasticsearch来和ClickHouse做一次实战测试,让大家更直观地看到真实的比对数据,从而对这两个数据库有更深入的了解,也就能理解为什么我们会选择ClickHouse。
数据库测试|Elasticsearch和ClickHouse的对决
|
2天前
|
存储 关系型数据库 MySQL
四种数据库对比MySQL、PostgreSQL、ClickHouse、MongoDB——特点、性能、扩展性、安全性、适用场景
四种数据库对比 MySQL、PostgreSQL、ClickHouse、MongoDB——特点、性能、扩展性、安全性、适用场景
|
2天前
|
存储 关系型数据库 MySQL
一个项目用5款数据库?MySQL、PostgreSQL、ClickHouse、MongoDB区别,适用场景
一个项目用5款数据库?MySQL、PostgreSQL、ClickHouse、MongoDB——特点、性能、扩展性、安全性、适用场景比较
|
1月前
|
关系型数据库 分布式数据库 数据库
开源云原生数据库PolarDB PostgreSQL 15兼容版本正式发布
PolarDB进行了深度的内核优化,从而实现以更低的成本提供商业数据库的性能。
|
2月前
|
SQL Oracle 关系型数据库
DBeaver,一款好用的开源数据库管理软件
DBeaver,一款好用的开源数据库管理软件
|
2月前
|
关系型数据库 Linux Shell
跟我一起来学国内排名NO.1的开源数据库安装
跟我一起来学国内排名NO.1的开源数据库安装
32 0
跟我一起来学国内排名NO.1的开源数据库安装
|
2月前
|
SQL Java 数据库连接
Hibernate 是一款开源 ORM(对象关系映射)框架,封装了 JDBC,允许以面向对象的方式操作数据库,简化了数据访问层的开发。
Hibernate 是一款开源 ORM(对象关系映射)框架,封装了 JDBC,允许以面向对象的方式操作数据库,简化了数据访问层的开发。通过映射机制,它可以自动处理对象与数据库表之间的转换,支持主流数据库,提高了代码的可移植性和可维护性。其核心接口包括 SessionFactory、Session 和 Transaction 等,通过它们可以执行数据库的 CRUD 操作。配置方面,需在项目中引入 Hibernate 及数据库驱动依赖,并创建 `hibernate.cfg.xml` 配置文件来设置数据库连接和 Hibernate 行为参数。
38 1
|
2月前
|
SQL 安全 关系型数据库
【惊天秘密】破解数据库管理难题!——Yearning开源审计平台:你的数据库安全守护神,一键审计,轻松应对挑战!
【8月更文挑战第21天】Yearning是一款基于Python的开源数据库审计平台,简化数据库管理和审计流程,支持MySQL、PostgreSQL等。核心功能包括SQL审计、执行、回滚及备份,提升数据库管理效率。安装简便,支持通过pip安装并快速启动服务。Yearning提供智能SQL审查,确保安全性与合规性,同时还具备友好的用户界面及API客户端支持,适用于多种数据库操作场景。
58 0
|
4月前
|
存储 关系型数据库 数据库
【DDIA笔记】【ch2】 数据模型和查询语言 -- 多对一和多对多
【6月更文挑战第7天】该文探讨数据模型,比较了“多对一”和“多对多”关系。通过使用ID而不是纯文本(如region_id代替&quot;Greater Seattle Area&quot;),可以实现统一、避免歧义、简化修改、支持本地化及优化搜索。在数据库设计中,需权衡冗余和范式。文档型数据库适合一对多但处理多对多复杂,若无Join,需应用程序处理。关系型数据库则通过外键和JOIN处理这些关系。文章还提及文档模型与70年代层次模型的相似性,层次模型以树形结构限制了多对多关系处理。为克服层次模型局限,发展出了关系模型和网状模型。
51 6