一、写在前头
在写上一篇【数据库评测】Cloudwave 4.0 集群版(4节点) VS Starrocks 3.0 集群版(4节点)
，评测的过程中，意外发现starrocks3.0版本在我预先设置hdfs副本数=2的配置下，自行把starrocks自己的hdfs副本数改成3。为了保持环境的一致性，七镜还是决定测一测Cloudwave4.0在hdfs副本数=3的配置下，是什么表现。
二、评测环境
- 硬件环境：4台 64核256g 云服务器（组成4节点的集群），essd pl1 高效云盘
- 软件环境：jdk19（Cloudwave4.0官方推荐版本，官方基于jdk19版本里头的的vector api，实现全面向量化引擎）、jdk8（starrocks安装推荐jdk版本，主要用于fe，亦可少踩坑）、mysql8（作为starrocks的客户端）、hadoop 3.2.2（作为cloudwave 和 starrocks 共同的分布式存储，副本数=3）
- 软件版本：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 | 日期表 |
三、评测方法
- 执行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;
四、开始测试cloudwave4.0
1. 配置hdfs的副本数=3
2. 加载ssb1000数据
- 使用的也是57分37秒
3. 查看压缩比
- ssb1000原始数据的文件系统占用为606G，导入到Cloudwave4.0之后，是360G，压缩比还是59%(360g/606g)
4. 测试13条标准测试SQL
- 从上图可以看到CPU最大占用是89.5%(5731%/6400%)
- 从上图可以看到13条标准SQL的总耗时，19轮查询去掉第一轮查询的平均耗时是：7.42秒
四、评测结论
结合Starrocks3.0的测试数据，汇总出下表
Cloudwave4.0集群版在4台64核256g内存的云服务器上，hdfs副本数=3的环境下，测ssb1000国际标准测试集，优于Starrocks3.0集群版近0.4倍
[附]13条标准测试SQL测试结果表：
| 数据库 | 数据集 | 响应时间（s） | CPU 最大占用率 | 存储压缩比 | 数据导入时间 |
|---|---|---|---|---|---|
| Cloudwave4.0 | ssb1000 | 7.416 | 89.5%(5731%/6400%) | 59%(360g/606g) | 57分37秒 |
| Starrocks3.0 | ssb1000 | 10.397 | 66.6%(4266%/6400%) | 169%(1024g/606g) | 112分钟 |
翰云云原生数据仓库（Cloudwave4.0）未来可期，七镜后续还将带来翰云云原生数仓在S3对象存储上的性能表现、更大的数据集上的表现、不同的数据集上的表现、以及在云的加持下，Cloudwave4.0的云原生架构是如何发挥其自身优势的，敬请期待。
