【数据库评测】Cloudwave 4.0 集群版(4节点) VS Starrocks 3.0 集群版(4节点)

本文涉及的产品
RDS AI 助手,专业版
RDS MySQL DuckDB 分析主实例,集群系列 4核8GB
RDS DuckDB + QuickBI 企业套餐,8核32GB + QuickBI 专业版
简介: 【数据库评测】Cloudwave 4.0 集群版(4节点) VS Starrocks 3.0 集群版(4节点)

一、评测结果



评测结论1:4台64核256g阿里云服务器组成的4节点集群,hadoop3.2.2 作为分布式存储,Cloudwave4.0在 SSB1000g 国际标准测试集下,整体性能优于Starrocks3.0近0.36倍。

评测结论2:在多表联合join场景下,Cloudwave4.0版本,耗时几乎等于零


[附]13条标准测试SQL测试结果表:

数据库 数据集 响应时间(s) CPU 最大占用率 存储压缩比 数据导入时间
Cloudwave4.0 ssb1000 7.602 90%(5763%/6400%) 59%(360g/606g) 58分钟
Starrocks3.0 ssb1000 10.397 66.6%(4266%/6400%) 169%(1024g/606g) 112分钟

[附]2条拓展测试SQL测试结果表

数据库 数据集 拓展SQL1响应时间(s) 拓展SQL1 CPU 最大占用率 拓展SQL2响应时间(s) 拓展SQL2 CPU 最大占用率
Cloudwave4.0 ssb1000 0.012 0.0935%(6%/6400%) 0.014 0.118%(7.6%/6400%)
Starrocks3.0 ssb1000 2.79 78.7%(5037%/6400%) 4.8 90.5%(5797%/6400%)



二、评测环境


  • 硬件环境:4台 64核256g 云服务器(组成2节点的集群),essd pl1 高效云盘
  • 软件环境:jdk19(Cloudwave4.0官方推荐版本,官方基于jdk19版本里头的的vector api,实现全面向量化引擎)、jdk8(starrocks安装推荐jdk版本,主要用于fe,亦可少踩坑)、mysql8(作为starrocks的客户端)、hadoop 3.2.2(作为cloudwave 和 starrocks 共同的分布式存储,副本数=2)
  • 软件版本:Cloudwave 4.0(最新版在2023年5月份发版),Starrocks 3.0(最新版在2023年4月份发版)
  • 评测数据集:ssb1000
表名 行数 说明
lineorder 60 亿 SSB 商品订单表
customer 3000 万 SSB 客户表
part 200 万 SSB 零部件表
supplier 200 万 SSB 供应商表
dates 2556 日期表


26608654-7488fec35bcce2f4.png



硬件环境

jdk版本



mysql版本

hadoop版本



Starrocks版本

Starrocks版本



三、评测方法


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

多表联合join测试

  • 测试方法:执行19轮SQL测试脚本,每轮执行1条多表联合join拓展测试sql,去除第1轮的测试数据(由于IO原因,第1次查询两边的性能均受IO影响,本测试主要测数据库引擎的算法在同等计算资源的条件下的优劣,因此去除第一轮测试数据),将余下的18轮测试数据做平均,获得sql的平均耗时
  • 观察最大CPU占用
  • 统计耗时
  • 多表联合join拓展测试SQL1:select count(*) from lineorder,customer where lo_custkey = c_custkey;
  • 多表联合join拓展测试SQL2:select count(*) from lineorder,customer,supplier where lo_custkey = c_custkey and lo_suppkey = s_suppkey;




四、开始测试[cloudwave]


  1. 查看为hadoop准备的存储空间


./sync_scripts.sh 'df -h' | grep home


  1. 格式化hadoop


hdfs namenode -format


  1. 启动hdfs,并查看服务状态


start-dfs.sh 
./sync_scripts.sh 'jps'


  1. 创建ssb1000数据上传目录

    26608654-85f9ee70f1d59fe7.png
hdfs dfs -mkdir /cloudwave
hdfs dfs -mkdir /cloudwave/uploads
hdfs dfs -put ssb1000 /cloudwave/uploads/


  1. 检查数据上传结果


  • 可以看到ssb1000的数据,占用606GB的存储空间
hdfs dfs -du -h /
du -sh /home/cloudwave/ssb-poc-0.9.3/ssb-poc/output/data_dir/ssb1000



启动cloudwave数据库,并导入ssb1000数据



  • 启动数据库
./start-all-server.sh


26608654-8775e271b5991b4a.png


  • 导入数据
./cplus_go.bin -s 'loaddata ssb1000'


26608654-1894080203ee7175.png


  • 可以看到3493秒导入完成,也就是58分钟。

26608654-c8fb7cfb758d193f.png

  • 上图通过hdfs命令,可以看到cloudwave做了数据压缩,ssb1000数据的原始大小是606G,导入cloudwave数据库之后,压缩到了360g(图中的720G 表示hdfs两个数据副本的总大小),压缩比为59%。
  1. [cloudwave]开始测试13条标准测试SQL


image.png



  • 执行测试脚本./test_ssb.sh,七镜观察到cloudwave 的4节点集群测ssb1000 CPU最大占用是90%(5763%/6400%)


  • 执行分析脚本./analysis.sh cloudwave "$(ls n*txt)" +,可以看到13条标准测试SQL的合计时间平均是7.6s
  1. [cloudwave] 开始测试2条多表联合joinSQL




  • 执行测试脚本 ./test_ex.sh,七镜观察到cloudwave的4节点集群测ssb1000 的拓展SQL1的CPU最大占用是0.0935%(6%/6400%)

26608654-259aba0b4519ac46.png

  • 执行分析脚本./analysis.sh cloudwave "$(ls n*txt)" +,可以看到拓展SQL1耗时是12ms。


  • 执行分析脚本./analysis.sh cloudwave "$(ls n*txt)" +,可以看到拓展SQL1耗时是12ms。



  • 将sql_ex.sql里的sql换成拓展SQL2,执行测试脚本 ./test_ex.sh,七镜观察到cloudwave的4节点集群测ssb1000 的拓展SQL2的CPU最大占用是0.118%(7.6%/6400%)


26608654-b123f9f3a73987ba.png


  • 执行分析脚本./analysis.sh cloudwave "$(ls n*txt)" +,可以看到拓展SQL2耗时是14ms。




五、对比测试


  1. 清空hdfs



[starrocks] 启动 starrocks3.0 fe



./fe/bin/start_fe.sh --daemon
  1. [starrocks] 添加starrocks3.0 be


26608654-24670f883dfd4b95.png


mysql -uroot -h127.0.0.1 -P9030
ALTER SYSTEM ADD BACKEND "172.17.161.33:9050"; 
ALTER SYSTEM ADD BACKEND "172.17.161.32:9050"; 
ALTER SYSTEM ADD BACKEND "172.17.161.31:9050"; 
ALTER SYSTEM ADD BACKEND "172.17.161.30:9050"; 


[starrocks] 启动 starrocks 3.0 be



./sync_scripts.sh "cd $(pwd)/be/bin && ./start_be.sh --daemon &&ps -ef | grep starrocks_be"
  1. [starrocks] 验证集群状态,4个节点的 Alive=true 即可。


26608654-01805cbfd954e93e.png


26608654-c0010ec7010f75ba.png


  1. [starrocks] 创建表


  2. [starrocks] 开始导入数据,ssb1000导入时间是

26608654-57cc69edc9c38ad7.png


  • 如上图所示,8点58分开始执行的导入命令。
date && ./bin/stream_load.sh data_dir/ssb30 && date

26608654-0170a6c9927bf88f.png


  • 如上图所示,导入过程中,发现在我设置的hdfs副本数默认=2的配置下,starrocks自己把自己建的文件副本数改成了3。


  • 如上图所示,10点50分导入结束,总计耗时112分钟。

26608654-e132b07f06de640c.png

  1. [starrocks] 查看ssb1000 压缩比,ssb1000数据的原始大小是606G,导入starrocks数据库之后,神奇的发现,占用了1T的分布式存储(压缩呢???)。


26608654-ab8dfd53d2a45a79.png


  1. [starrocks] 开始测试
  • 执行测试脚本./test_ssb.sh,七镜观察到 starrocks 的4节点集群测ssb1000 CPU最大占用是4266%/6400%

26608654-6a28df0be03dee20.png



  1. [starrocks]分析测试结果
  • 执行分析脚本./analysis.sh starrocks "$(ls n*txt)" +,去掉第一轮查询(42.57s)的平均时间是10.39秒

26608654-7ddf625226436171.png


[starrocks] 开始测试2条多表联合joinSQL



  • 执行测试脚本 ./test_ex.sh,七镜观察到starrocks的4节点集群测ssb1000 的拓展SQL1的CPU最大占用是78.7%(5037%/6400%)


  • 执行分析脚本./analysis.sh starrocks "$(ls n*txt)" +,可以看到拓展SQL1耗时是2.79s。


  • 将sql_ex.sql里的sql换成拓展SQL2,执行测试脚本 ./test_ex.sh,七镜观察到starrocks的4节点集群测ssb1000 的拓展SQL2的CPU最大占用是90.5%(5797%/6400%)

26608654-413fbb23f04a416f.png

  • 执行分析脚本./analysis.sh starrocks "$(ls n*txt)" +,可以看到拓展SQL2耗时是4.8s。




五、附加


  1. Cloudwave 测试脚本


#!/bin/bash
# Program:
#       test ssb
# History:
# 2023/03/17    junfenghe.cloud@qq.com  version:0.0.1
rm -rf ./n*txt
for ((i=1; i<20; i++))
do
    cat sql_ssb.sql |./cplus.sh > n${i}.txt
done


Starrocks 测试脚本

#!/bin/bash
# Program:
#       test ssb
# History:
# 2023/03/17    junfenghe.cloud@qq.com  version:0.0.1
rm -rf ./n*txt
for ((i=1; i<20; i++))
do
    cat sql_ssb.sql | mysql -uroot -P 9030 -h 127.0.0.1 -v -vv -vvv >n${i}.txt
done


分析脚本

#!/bin/bash
#Program:
#       analysis cloudwave/starrocks logs of base compute
#History:
#2023/02/20     junfenghe.cloud@qq.com  version:0.0.1
path=/bin:/sbin:/usr/bin:/usr/sbin:/usr/local/sbin:/usr/local/bin:~/bin
export path
suff="(s)#####"
if [ -z "${1}" ]
then
        echo "Please input database'name"
        exit -1
fi
if [ -z "$2" ]
then
        echo "Please input times of scanner"
        exit -f
fi
if [ -n "${3}" ]
then
        suff=${3}
fi
for current in ${2}
do
        result_time=""
        if [ "${1}" == "starrocks" ]
        then
            for time in $( cat ${current} | grep sec  | awk -F '('  '{print $2}' | awk -F ' ' '{print $1}' )
            do
                result_time="${result_time}${time}${suff}"
            done
        elif [ "${1}" == "cloudwave" ]
        then
            for time in $( cat ${current} | grep Elapsed | awk '{print $2}'| sed 's/:/*60+/g'| sed 's/+00\*60//g ; s/+0\*60//g ; s/^0\*60+//g' )
            do
                result_time="${result_time}${time}${suff}"
            done
        fi
        echo ${result_time%${suff}*}
done
exit 0


sql_ssb.sql

use ssb1000;
select sum(lo_revenue) as revenue from lineorder,dates where lo_orderdate = d_datekey and d_year = 1993 and lo_discount between 1 and 3 and lo_quantity < 25;
select sum(lo_revenue) as revenue from lineorder,dates where lo_orderdate = d_datekey and d_yearmonthnum = 199401 and lo_discount between 4 and 6 and lo_quantity between 26 and 35;
select sum(lo_revenue) as revenue from lineorder,dates where lo_orderdate = d_datekey and d_weeknuminyear = 6 and d_year = 1994 and lo_discount between 5 and 7 and lo_quantity between 26 and 35;
select sum(lo_revenue) as lo_revenue, d_year, p_brand from lineorder ,dates,part,supplier where lo_orderdate = d_datekey and lo_partkey = p_partkey and lo_suppkey = s_suppkey and p_category = 'MFGR#12' and s_region = 'AMERICA' group by d_year, p_brand order by d_year, p_brand;
select sum(lo_revenue) as lo_revenue, d_year, p_brand from lineorder,dates,part,supplier where lo_orderdate = d_datekey and lo_partkey = p_partkey and lo_suppkey = s_suppkey and p_brand between 'MFGR#2221' and 'MFGR#2228' and s_region = 'ASIA' group by d_year, p_brand order by d_year, p_brand;
select sum(lo_revenue) as lo_revenue, d_year, p_brand from lineorder,dates,part,supplier where lo_orderdate = d_datekey and lo_partkey = p_partkey and lo_suppkey = s_suppkey and p_brand = 'MFGR#2239' and s_region = 'EUROPE' group by d_year, p_brand order by d_year, p_brand;
select c_nation, s_nation, d_year, sum(lo_revenue) as lo_revenue from lineorder,dates,customer,supplier where lo_orderdate = d_datekey and lo_custkey = c_custkey and lo_suppkey = s_suppkey and c_region = 'ASIA' and s_region = 'ASIA'and d_year >= 1992 and d_year <= 1997 group by c_nation, s_nation, d_year order by d_year asc, lo_revenue desc;
select c_city, s_city, d_year, sum(lo_revenue) as lo_revenue from lineorder,dates,customer,supplier where lo_orderdate = d_datekey and lo_custkey = c_custkey and lo_suppkey = s_suppkey and  c_nation = 'UNITED STATES' and s_nation = 'UNITED STATES' and d_year >= 1992 and d_year <= 1997 group by c_city, s_city, d_year order by d_year asc, lo_revenue desc;
select c_city, s_city, d_year, sum(lo_revenue) as lo_revenue from lineorder,dates,customer,supplier where lo_orderdate = d_datekey and lo_custkey = c_custkey and lo_suppkey = s_suppkey and (c_city='UNITED KI1' or c_city='UNITED KI5') and (s_city='UNITED KI1' or s_city='UNITED KI5') and d_year >= 1992 and d_year <= 1997 group by c_city, s_city, d_year order by d_year asc, lo_revenue desc;
select c_city, s_city, d_year, sum(lo_revenue) as lo_revenue from lineorder,dates,customer,supplier where lo_orderdate = d_datekey and lo_custkey = c_custkey and lo_suppkey = s_suppkey and (c_city='UNITED KI1' or c_city='UNITED KI5') and (s_city='UNITED KI1' or s_city='UNITED KI5') and d_yearmonth  = 'Dec1997' group by c_city, s_city, d_year order by d_year asc, lo_revenue desc;
select d_year, c_nation, sum(lo_revenue) - sum(lo_supplycost) as profit from lineorder,dates,customer,supplier,part where lo_orderdate = d_datekey and lo_custkey = c_custkey and lo_suppkey = s_suppkey and lo_partkey = p_partkey and c_region = 'AMERICA' and s_region = 'AMERICA' and (p_mfgr = 'MFGR#1' or p_mfgr = 'MFGR#2') group by d_year, c_nation order by d_year, c_nation;
select d_year, s_nation, p_category, sum(lo_revenue) - sum(lo_supplycost) as profit from lineorder,dates,customer,supplier,part where lo_orderdate = d_datekey and lo_custkey = c_custkey and lo_suppkey = s_suppkey and lo_partkey = p_partkey and c_region = 'AMERICA'and s_region = 'AMERICA' and (d_year = 1997 or d_year = 1998) and (p_mfgr = 'MFGR#1' or p_mfgr = 'MFGR#2') group by d_year, s_nation, p_category order by d_year, s_nation, p_category;
select d_year, s_city, p_brand, sum(lo_revenue) - sum(lo_supplycost) as profit from lineorder,dates,customer,supplier,part where lo_orderdate = d_datekey and lo_custkey = c_custkey and lo_suppkey = s_suppkey and lo_partkey = p_partkey and c_region = 'AMERICA'and s_nation = 'UNITED STATES' and (d_year = 1997 or d_year = 1998) and p_category = 'MFGR#14' group by d_year, s_city, p_brand order by d_year, s_city, p_brand;
相关实践学习
每个IT人都想学的“Web应用上云经典架构”实战
本实验从Web应用上云这个最基本的、最普遍的需求出发,帮助IT从业者们通过“阿里云Web应用上云解决方案”,了解一个企业级Web应用上云的常见架构,了解如何构建一个高可用、可扩展的企业级应用架构。
MySQL数据库入门学习
本课程通过最流行的开源数据库MySQL带你了解数据库的世界。 &nbsp; 相关的阿里云产品:云数据库RDS MySQL 版 阿里云关系型数据库RDS(Relational Database Service)是一种稳定可靠、可弹性伸缩的在线数据库服务,提供容灾、备份、恢复、迁移等方面的全套解决方案,彻底解决数据库运维的烦恼。 了解产品详情:&nbsp;https://www.aliyun.com/product/rds/mysql&nbsp;
目录
相关文章
|
负载均衡 算法 关系型数据库
大数据大厂之MySQL数据库课程设计:揭秘MySQL集群架构负载均衡核心算法:从理论到Java代码实战,让你的数据库性能飙升!
本文聚焦 MySQL 集群架构中的负载均衡算法,阐述其重要性。详细介绍轮询、加权轮询、最少连接、加权最少连接、随机、源地址哈希等常用算法,分析各自优缺点及适用场景。并提供 Java 语言代码实现示例,助力直观理解。文章结构清晰,语言通俗易懂,对理解和应用负载均衡算法具有实用价值和参考价值。
大数据大厂之MySQL数据库课程设计:揭秘MySQL集群架构负载均衡核心算法:从理论到Java代码实战,让你的数据库性能飙升!
|
Cloud Native 关系型数据库 分布式数据库
登顶TPC-C|云原生数据库PolarDB技术揭秘:Limitless集群和分布式扩展篇
阿里云PolarDB云原生数据库在TPC-C基准测试中以20.55亿tpmC的成绩刷新世界纪录,展现卓越性能与性价比。其轻量版满足国产化需求,兼具高性能与低成本,适用于多种场景,推动数据库技术革新与发展。
|
存储 NoSQL 数据库
Redis 逻辑数据库与集群模式详解
Redis 是高性能内存键值数据库,广泛用于缓存与实时数据处理。本文深入解析 Redis 逻辑数据库与集群模式:逻辑数据库提供16个独立存储空间,适合小规模隔离;集群模式通过分布式架构支持高并发和大数据量,但仅支持 database 0。文章对比两者特性,讲解配置与实践注意事项,并探讨持久化及性能优化策略,助你根据需求选择最佳方案。
1107 5
|
存储 缓存 数据库
数据库数据删除策略:硬删除vs软删除的最佳实践指南
在项目开发中,“删除”操作常见但方式多样,主要分为硬删除与软删除。硬删除直接从数据库移除数据,操作简单、高效,但不可恢复;适用于临时或敏感数据。软删除通过标记字段保留数据,支持恢复和审计,但增加查询复杂度与数据量;适合需追踪历史或可恢复的场景。两者各有优劣,实际开发中常结合使用以满足不同需求。
1331 4
|
Cloud Native 关系型数据库 分布式数据库
登顶TPC-C|云原生数据库PolarDB技术揭秘:Limitless集群和分布式扩展篇
云原生数据库PolarDB技术揭秘:Limitless集群和分布式扩展篇
|
12月前
|
Cloud Native 关系型数据库 分布式数据库
客户说|知乎基于阿里云PolarDB,实现最大数据库集群云原生升级
近日,知乎最大的风控业务数据库集群,基于阿里云瑶池数据库完成了云原生技术架构的升级。此次升级不仅显著提升了系统的高可用性和性能上限,还大幅降低了底层资源成本。
|
负载均衡 算法 关系型数据库
大数据新视界--大数据大厂之MySQL数据库课程设计:MySQL集群架构负载均衡故障排除与解决方案
本文深入探讨 MySQL 集群架构负载均衡的常见故障及排除方法。涵盖请求分配不均、节点无法响应、负载均衡器故障等现象,介绍多种负载均衡算法及故障排除步骤,包括检查负载均衡器状态、调整算法、诊断修复节点故障等。还阐述了预防措施与确保系统稳定性的方法,如定期监控维护、备份恢复策略、团队协作与知识管理等。为确保 MySQL 数据库系统高可用性提供全面指导。
|
存储 SQL 并行计算
【赵渝强老师】达梦数据库MPP集群的架构
达梦数据库提供大规模并行处理(MPP)架构,以低成本实现高性能并行计算,满足海量数据存储和复杂查询需求。DM MPP采用完全对等无共享体系,消除主节点瓶颈,通过多节点并行执行提升性能。其执行流程包括主EP生成计划、分发任务、各EP并行处理及结果汇总返回。为确保高可用性,建议结合数据守护部署。
588 0
|
9月前
|
缓存 关系型数据库 BI
使用MYSQL Report分析数据库性能(下)
使用MYSQL Report分析数据库性能
548 158
|
9月前
|
关系型数据库 MySQL 数据库
自建数据库如何迁移至RDS MySQL实例
数据库迁移是一项复杂且耗时的工程,需考虑数据安全、完整性及业务中断影响。使用阿里云数据传输服务DTS,可快速、平滑完成迁移任务,将应用停机时间降至分钟级。您还可通过全量备份自建数据库并恢复至RDS MySQL实例,实现间接迁移上云。

热门文章

最新文章