【数据库评测】揭秘 Cloudwave 4.0 版本多表联合join零耗时

简介: 【数据库评测】揭秘 Cloudwave 4.0 版本多表联合join零耗时

一、评测结果


  • 64核256g内存的机器上,在ssb100g数据集下,Cloudwave4.0 单机版在维度表与事实表之间做多表联合join时,查询耗时几乎为零(1ms),CPU占用几乎为零;2张表的join到3张表的join耗时增加几乎都可以忽略不计,CPU占用增加也几乎可以忽略不计。


  • 64核256g内存的机器上,在ssb100g数据集下,Starrocks3.0 单机版在维度表与事实表之间做多表联合join时,查询耗时在亚秒级别,CPU占用达到70%以上;2张表的join到3张表的join耗时增加50%,CPU占用变化不大(因为耗时增加了,单位时间内的CPU负载变化不大)。



备注:Cloduwave4.0是类snowflake的新一代云原生数据仓库;同时和starrocks一样配备mpp框架和多维向量化引擎;此外,独创的多维分析算法,尤其擅长雪花模型,星型模型等,多表联合join查询资源损耗几乎为零。


26608654-3af867b9e1277791.png


数据库 数据集 SQL1响应时间(ms) SQL2响应时间(ms) SQL1 CPU 最大占用率 SQL2 CPU 最大占用率
Cloudwave4.0 ssb100 10 10 0.275%(17.6%/6400%) 0.28%(17.9%/6400%)
Starrocks3.0 ssb100 590 890 71%(4546%/6400%) 79.5%(5093%/6400%)




二、评测环境


  • 硬件环境:1台 64核256g 云服务器,essd pl1 高效云盘
  • 软件环境:jdk19(Cloudwave4.0官方推荐版本,官方基于jdk19版本里头的的vector api,实现全面向量化引擎)、jdk8(starrocks安装推荐jdk版本,主要用于fe,亦可少踩坑)、mysql8(作为starrocks的客户端)
  • 软件版本:Cloudwave 4.0,Starrocks 3.0
  • 评测数据集:ssb100




三、评测SQL


  • 评测SQL1:select count(*) from lineorder,customer where lo_custkey = c_custkey;
  • 评测SQL2:select count(*) from lineorder,customer,supplier where lo_custkey = c_custkey and lo_suppkey = s_suppkey;


第1条SQL是将lineorder这张事实表与customer这张维度表join,加count()是迫使数据库必须把所有的记录都join上。


第2条SQL是将lineorder这张事实表与customer、supplier 这两张维度join,加count(
)同样是迫使数据库必须把所有的记录都join上。



三、评测方法


  • 执行19轮SQL1测试脚本,每轮执行1条测试sql,去除第1轮的测试数据(由于IO原因,第1次查询两边的性能均受IO影响,本测试主要测数据库引擎的算法在同等计算资源的条件下的优劣,因此去除第一轮测试数据),将余下的18轮测试数据做平均,获得sql的平均耗时
  • 观察最大CPU占用




四、开始评测[cloudwave]


  • 启动并导入ssb100数据 到cloudwave


  • 执行cloudwave SQL1测试




./test_ex.sh
  • 可以看到cloudwave CPU最大占用是17.6%
  1. 分析SQL1结果


26608654-ae96ff44e02a43f2.png


./analysis.sh cloudwave "$(ls n*txt)" +
  • 可以看到cloudwave SQL1的耗时0.01秒左右。(截图里的0.04是第一轮查询,IO影响比较大)(天呐!lineorder(数据量6亿),join customer(数据量300万),竟然只需要0.01秒)
  1. 执行SQL2测试


26608654-2dbdbe6c6219a408.png


./test_ex.sh
  • 可以看到cloudwave CPU最大占用是17.9%
  1. 分析SQL2结果


26608654-f2b01726742a42fe.png


./analysis.sh cloudwave "$(ls n*txt)" +
  • 可以看到cloudwave SQL2 的耗时也是0.01秒左右。(天呐!!!lineorder(数据量6亿),join customer(数据量300万),再join supplier(数据量20万)竟然也只需要0.01秒。简直像开了挂——官方说:我们对于事实表与维度表多表联合join的时间应该为零



五、对比评测[starrocks]


  1. 启动并导入ssb100 到 starrocks


26608654-ddbb31b4fdac2cd3.png


./fe/bin/start_fe.sh --daemon
./be/bin/start_be.sh --daemon
./create_db_table.sh ddl_100
  1. 执行SQL1测试


26608654-8ddd6b4371d3ed30.png


  • 可以看到starrocks CPU 最大占用率为 4546%。
  1. 分析SQL1 结果



  • 可以看到starrocks SQL1 的耗时是0.59s左右。
  1. 执行SQL2测试

    26608654-825fe7993138dcf1.png
  • 可以看到starrocks CPU最大占用率为 5093%。
  1. 分析SQL2结果

26608654-4eac3d1b77e6ab6d.png


可以看到 starrocks SQL2 耗时 0.89s 左右。



目录
相关文章
|
4月前
|
存储 算法 Java
实现不同数据库的表间的 JOIN 运算的极简方法
跨库计算是数据分析中的常见难题,尤其涉及多数据库系统时,表间 JOIN 操作复杂度显著提升。esProc 提供了一种高效解决方案,能够简化跨库 JOIN 的实现。例如,在车辆管理、交管和公民信息系统中,通过 esProc 可轻松完成如下任务:按城市统计有车公民事件数量、找出近一年获表彰的车主信息,以及按年份和品牌统计车辆违章次数。esProc 支持不同关联场景(如维表关联与主子表关联)的优化算法,如内存索引、游标处理和有序归并,从而大幅提升编码和运算效率。无论是同构还是异构数据源,esProc 均能灵活应对,为复杂数据分析提供强大支持。
|
5月前
|
监控 数据库
【YashanDB 知识库】ycm 托管数据库时报错 OM host ip:127.0.0.1 is not support join to YCM
在托管数据库时,若 OM 的 IP 被设置为 127.0.0.1,将导致无法托管至 YCM,并使数据库失去监控。此问题源于安装时修改了 OM 的监听 IP。解决方法包括:将 OM 的 IP 修改为本机实际 IP 或 0.0.0.0,同时更新 env 文件及 yasom 后台数据库中的相关配置。经验总结指出,应避免非必要的后台 IP 修改,且数据库安装需遵循规范,不使用仅限本机访问的 IP(如 127.0.0.1)。
|
6月前
|
物联网 测试技术 API
时序数据库 InfluxDB 3.0 版本性能实测报告:写入吞吐量提升效果验证
TSBS 测试表明,对于少于 100 万台设备的数据集,InfluxDB OSS 3.0 的数据写入速度实际上比 InfluxDB OSS 1.8 更慢。 对于 100 万台及以上设备的数据集,InfluxDB OSS 3.0 的数据写入性能才开始超过 InfluxDB OSS 1.8。 InfluxDB OSS 3.0 的数据写入接口与 InfluxDB 1.8 并不兼容,用户无法顺利迁移。
430 7
|
6月前
|
监控 数据库
【YashanDB知识库】ycm托管数据库时报错OM host ip:127.0.0.1 is not support join to YCM
在托管数据库时,若OM的IP被设置为127.0.0.1,则不支持托管到YCM,导致数据库无法正常监控。此问题源于安装时修改了OM监听IP为127.0.0.1。解决方法为将OM的IP修改为本机实际IP或0.0.0.0,并更新yasom后台数据库中的相关配置。建议遵循规范安装,避免使用仅限本机访问的IP(如127.0.0.1),以减少潜在风险。
|
6月前
|
监控 数据库
ycm托管数据库时报错OM host ip:127.0.0.1 is not support join to YCM-YashanDB
ycm托管数据库时报错OM host ip:127.0.0.1 is not support join to YCM-YashanDB
|
10月前
|
SQL 关系型数据库 数据库连接
"Nacos 2.1.0版本数据库配置写入难题破解攻略:一步步教你排查连接、权限和配置问题,重启服务轻松解决!"
【10月更文挑战第23天】在使用Nacos 2.1.0版本时,可能会遇到无法将配置信息写入数据库的问题。本文将引导你逐步解决这一问题,包括检查数据库连接、用户权限、Nacos配置文件,并提供示例代码和详细步骤。通过这些方法,你可以有效解决配置写入失败的问题。
519 0
|
11月前
|
XML 缓存 数据库
Discuz! X3.0 版本的数据库字典
Discuz! X3.0 版本的数据库字典
179 0
|
11月前
|
JavaScript 前端开发 测试技术
[新手入门]todolist增删改查:vue3+ts版本!
【10月更文挑战第15天】[新手入门]todolist增删改查:vue3+ts版本!
|
3月前
|
人工智能 运维 关系型数据库
数据库运维:mysql 数据库迁移方法-mysqldump
本文介绍了MySQL数据库迁移的方法与技巧,重点探讨了数据量大小对迁移方式的影响。对于10GB以下的小型数据库,推荐使用mysqldump进行逻辑导出和source导入;10GB以上可考虑mydumper与myloader工具;100GB以上则建议物理迁移。文中还提供了统计数据库及表空间大小的SQL语句,并讲解了如何使用mysqldump导出存储过程、函数和数据结构。通过结合实际应用场景选择合适的工具与方法,可实现高效的数据迁移。
665 1
|
4月前
|
负载均衡 算法 关系型数据库
大数据大厂之MySQL数据库课程设计:揭秘MySQL集群架构负载均衡核心算法:从理论到Java代码实战,让你的数据库性能飙升!
本文聚焦 MySQL 集群架构中的负载均衡算法,阐述其重要性。详细介绍轮询、加权轮询、最少连接、加权最少连接、随机、源地址哈希等常用算法,分析各自优缺点及适用场景。并提供 Java 语言代码实现示例,助力直观理解。文章结构清晰,语言通俗易懂,对理解和应用负载均衡算法具有实用价值和参考价值。
大数据大厂之MySQL数据库课程设计:揭秘MySQL集群架构负载均衡核心算法:从理论到Java代码实战,让你的数据库性能飙升!

热门文章

最新文章