林芝市网站建设_网站建设公司_VPS_seo优化

由于项目中选型 OLAP 数据仓库，并且涉及到比较大量的数据更新，经过筛选后比较适合的两款选型是 Doris 和 StarRocks。所以考虑对这两款数仓进行性能测试，从其中选择一款比较适合的来使用。

选型测试的时间为 2025 年 7 月份，比当前发布文章的时间要早将近半年，所以版本是依据当时的稳定版进行测试的。随着后来版本的迭代更新可能会有所变化，本次测试结果可以作为参考。

1. 环境准备

1.1. 软件版本

Doris 版本：2.1.10

StarRocks 版本：3.4.0

操作系统：Ubuntu 20.04.1 LTS

1.2. 硬件环境

测试环境采用 4 台 x86_64 云服务器，磁盘均为 SSD 云盘，网络为共享万兆。

CPU 8 核，内存 64GB	FE
CPU 16 核，内存 128GB	BE × 3

1.3. 软件参数

测试前统一调整操作系统内核参数。

StarRocks 和 Doris 的 FE JVM 内存都调整至 16G

StarRocks 和 Doris 的配置除了导入大小、超时时间参数等其余均保持默认。

2. 测试项目

为了较为全面地评测性能，从业界内的评测标准和项目的业务场景中选定下面 5 个测试项目进行测试。

2.1. SSB Flat 测试

Star Schema Benchmark(SSB) 是一个轻量级的数仓场景下的性能测试集。SSB 基于 TPC-H 提供了一个简化版的星型模型数据集，主要用于测试在星型模型下，多表关联查询的性能表现。另外，业界内通常也会将 SSB 打平为宽表模型（简称 SSB Flat）来测试查询引擎的性能。

2.2. TPC-H 测试

TPC-H 是一个决策支持基准（Decision Support Benchmark），它由一套面向业务的特别查询和并发数据修改组成。查询和填充数据库的数据具有广泛的行业相关性。这个基准测试演示了检查大量数据、执行高度复杂的查询并回答关键业务问题的决策支持系统。TPC-H 报告的性能指标称为 TPC-H 每小时复合查询性能指标 (QphH@Size)，反映了系统处理查询能力的多个方面。这些方面包括执行查询时所选择的数据库大小，由单个流提交查询时的查询处理能力，以及由多个并发用户提交查询时的查询吞吐量。

2.3. TPC-DS 测试

TPC-DS（Transaction Processing Performance Council Decision Support Benchmark）是一个以决策支持为重点的基准测试，旨在评估数据仓库和分析系统的性能。它是由 TPC（Transaction Processing Performance Council）组织开发的，用于比较不同系统在处理复杂查询和大规模数据分析方面的能力。

TPC-DS 的设计目标是模拟现实世界中的复杂决策支持工作负载。它通过一系列复杂的查询和数据操作来测试系统的性能，包括联接、聚合、排序、过滤、子查询等。这些查询模式涵盖了从简单到复杂的各种场景，如报表生成、数据挖掘、OLAP（联机分析处理）等。

2.4. 业务场景：搜索测试

通过搜索业务中常见的基本属性检索、字段分组聚合查询以及多表关联查询来评测在搜索业务场景中数仓的性能表现。

2.5. 业务场景：大量数据更新测试

选用创建主键表，并进行多次更新覆写，评测大量数据更新场景下的性能表现。

3. SSB Flat 测试

数据集大小为 6 亿，分布如下：

表名	行数	说明
lineorder	6 亿	SSB 商品订单表
customer	300 万	SSB 客户表
part	140 万	SSB 零部件表
supplier	20 万	SSB 供应商表
dates	2556	日期表
lineorder_flat	6 亿	SSB 打平后的宽表

测试结果如下，结果单位为毫秒（ms）：

查询	StarRocks	Doris
Q1.1	93	73
Q1.2	43	53
Q1.3	73	76
Q2.1	386	183
Q2.2	330	180
Q2.3	170	143
Q3.1	413	260
Q3.2	266	163
Q3.3	263	133
Q3.4	60	60
Q4.1	456	246
Q4.2	180	116
Q4.3	110	103
合计	2843	1789

结论：大部分查询 Doris 都比 StarRocks 略快。总体时间上来看 SSB 测试中 Doris 比 StarRocks 约快 37% 左右。

4. TPC-H 测试

数据集规模为 100GB，数据分布如下：

表	行数
customer	1500 万
lineitem	6 亿
nation	25
orders	1.5 亿
part	2000 万
partsupp	8000 万
region	5
supplier	100 万

数据导入用时：

1. StarRocks 11 min
2. Doris 8 min

测试结果如下，结果单位为毫秒（ms）：

SQL	StarRocks	Doris
Q1	2413	2850
Q2	323	206
Q3	990	553
Q4	713	270
Q5	1123	910
Q6	90	83
Q7	1033	533
Q8	1403	453
Q9	2103	2950
Q10	1306	1766
Q11	380	336
Q12	366	196
Q13	2413	2130
Q14	253	256
Q15	263	280
Q16	373	390
Q17	323	243
Q18	4140	3350
Q19	340	343
Q20	766	483
Q21	1906	1196
Q22	560	396
合计	23580	20173

查询柱状图如下：

从查询分布上来看，大部分查询 Doris 比 StarRocks 都快，但是对于 Q1、Q9、Q10 StarRocks 有明显的优势。总用时 Doris 比 StarRocks 快 14% 左右。

5. TPC-DS 测试

数据集规模为 100GB，分布如下：

表	行数
call_center	30
catalog_page	20400
catalog_returns	14404374
catalog_sales	143997065
customer_address	1000000
customer_demographics	1920800
customer	2000000
date_dim	73049
household_demographics	7200
income_band	20
inventory	399330000
item	204000
promotion	1000
reason	55
ship_mode	20
store	402
store_returns	28795080
store_sales	287997024
time_dim	86400
warehouse	15
web_page	2040
web_returns	7197670
web_sales	72001237
web_site	24

数据导入用时：

1. StarRocks 35 min
2. Doris 15 min

测试结果如下，结果单位为毫秒（ms）：

SQL	StarRocks (ms)	Doris (ms)
Query01	1071	401
Query02	890	1530
Query03	243	205
Query04	7122	3565
Query05	817	276
Query06	519	276
Query07	739	282
Query08	509	284
Query09	1741	1785
Query10	601	243
Query11	2476	2076
Query12	276	161
Query13	635	335
Query14	6114	5405
Query15	348	282
Query16	878	363
Query17	1083	508
Query18	600	510
Query19	468	244
Query20	295	183
Query21	369	169
Query22	2885	3923
Query23	17385	8947
Query24	1321	2026
Query25	924	400
Query26	425	200
Query27	490	322
Query28	1402	1634
Query29	912	407
Query30	389	251
Query31	940	715
Query32	199	100
Query33	606	265
Query34	501	432
Query35	938	682
Query36	606	1036
Query37	225	167
Query38	1365	1600
Query39	971	1709
Query40	301	172
Query41	160	129
Query42	346	104
Query43	675	445
Query44	480	653
Query45	348	286
Query46	646	416
Query47	1276	1495
Query48	606	269
Query49	713	341
Query50	544	311
Query51	2086	5646
Query52	341	105
Query53	483	205
Query54	597	472
Query55	319	110
Query56	558	283
Query57	1005	1168
Query58	563	297
Query59	1862	1754
Query60	592	251
Query61	775	203
Query62	459	387
Query63	495	211
Query64	910	1632
Query65	1401	1818
Query66	508	299
Query67	5917	14924
Query68	550	333
Query69	585	429
Query70	1584	1126
Query71	605	316
Query72	1577	2348
Query73	418	247
Query74	2049	2309
Query75	1963	1512
Query76	482	405
Query77	785	226
Query78	4442	3601
Query79	810	391
Query80	1009	406
Query81	395	280
Query82	352	238
Query83	280	321
Query84	292	215
Query85	805	605
Query86	431	394
Query87	1391	2004
Query88	1922	1669
Query89	499	293
Query90	270	373
Query91	313	275
Query92	244	102
Query93	441	519
Query94	406	246
Query95	933	306
Query96	435	296
Query97	1308	1545
Query98	461	395
Query99	675	578
合计	113956	100977

查询柱状图分析：

从查询上看短查询 Doris 普遍比 StarRocks 快，中等的查询两者有快有慢。比较值得注意的是对于 Query 04 和 Query 23 Doris 比 StarRocks 有明显的优势，但是对于 Query 51 和 Query67 StarRocks 比 Doris 又快得多，这些复杂的查询也是各有优势，如果感兴趣的话可以深入分析下。总用时来看 Doris 性能比 StarRocks 高 10% 左右。

6. 业务搜索测试

数据源采用 MinIO 的方式提供，来源是将已有的测试数据写入 MinIO，以 Parquet 格式存储。再使用 StarRocks 和 Doris 导入 MinIO 的 Parquet 文件，从而完成数据导入。

因为具体的业务表不方便公开，所以下面的表名和表结构会省略，正常保留测试结果（请谅解 ≧﹏≦）。

数据大小为 226GB，分布如下：

数据表	行数	备注
-	1000279269	业务数据表
-	414	字典表1
-	5111	字典表2
-	3228	字典表3

StarRocks 和 Doris 的数据表结构设置一致，包括分区、分桶、排序键和副本数。

测试 SQL 共有 9 个，分别包含普通多条件搜索、单字段和多字段分组、条件+分组+聚合过滤、条件 + 分组 + UNION、条件 + 单表以及多表 JOIN 这些。

数据导入方式如下：

-- StarRocks 采用 INSERT ... FILES 的方式导入
INSERT INTO <table>
SELECT * FROM FILES ("path" = "s3://data-source/<table>/xxx.parquet","format" = "parquet","compression" = "uncompressed","aws.s3.enable_ssl" = "false","aws.s3.access_key" = "xxxxxx","aws.s3.secret_key" = "xxxxxxxx","aws.s3.use_aws_sdk_default_behavior" = "false","aws.s3.use_instance_profile" = "false","aws.s3.enable_path_style_access" = "true","aws.s3.endpoint" = "http://192.168.1.28:9000"
);
-- Doris 采用 TVF 方式从文件导入
INSERT INTO <table>
SELECT * FROM S3
("uri" = "s3://data-source/<table>/xxx.parquet","format" = "parquet","provider" = "S3","s3.endpoint" = "http://192.168.1.28:9000","s3.region" = "us-east-1","s3.access_key" = "xxxxxx","s3.secret_key" = "xxxxxxxx","use_path_style" = "true"
);

对于数据表有很多个文件的情况，会使用脚本遍历所有的 Parquet 文件，并生成 SQL 然后执行导入。

导入时间：

1. StarRocks 1366s
2. Doris 676s

测试结果如下：

SQL	StarRocks	Doris	StarRocks / Doris
Q0	0.1s	0.1s	1
Q1	0.14s	0.16s	0.88
Q2	5.9s	8.66s	0.68
Q3	15.49s	12.64s	1.23
Q4	0.45s	0.45s	1.13
Q5	0.34s	0.3s	1.13
Q6	0.23s	0.12s	1.92
Q7	0.23s	0.17s	1.35
Q8	0.22s	0.18s	1.22
合计	23.1	22.78	1.01

查询中只有单字段分组 Doris 比 StarRocks 慢的多一些，其余的查询 Doris 都快于 StarRocks，但总的用时上 Doris 和 StarRocks 几乎一致。

7. 大数据量更新测试

测试中基于业务明细表结构为基准创建主键表，同时保证 Doris 和 StarRocks 的主键、分区和分桶以及副本规则都一致。

初始数据会从明细表直接导入到主键表：

-- 采用 INSERT INTO ... SELECT 方式导入
INSERT INTO <主键表> SELECT * FROM <明细表>;

后续执行增量更新时将使用脚本查询分区并按照分区逐个进行更新。

明细表基准大小为 120GB

Doris 更新统计：

1. 第一次全量写入用时 2300s，表大小 142GB
2. 第二次增量更新用时 1244s，更新后表大小 203GB。随着后台版本合并大小不断减小降低至 13 亿（190G）左右出现暂停。
3. 第三次增量更新用时 1153s，更新后表大小 237GB。后台合并不断降低至 16 亿（229GB）左右出现暂停。

StarRocks 更新统计：

1. 第一次全量写入用时 1847s，表大小为 183GB
2. 第二次增量更新用时 1417s，更新后表大小为 260.76GB，后台会不断合并直到没有重复的为止。
3. 第三次增量更新用时 1469s，更新后表大小为 287.6GB，后台会不断合并直到没有重复的为止。

Doris 写入和更新的资源占用指标统计如下，其中的 3 个数字表示 3 次导入的值：

指标	BE1	BE2	BE3
CPU 平均利用率	7%,38%,35%	23%,37.5%,37%	7.5%,37%,34%
CPU 最大利用率	36%,66%,72%	83%,76%,80%	43%,64%,66%
内存平均使用	3.84GB,22.5GB,17.3GB	28.5GB,21.8GB,17.9GB	5.66GB,21.2GB,17.2G
内存最大使用	16.1GB,36.1GB,22.9GB	45.4GB,31.8GB,23.8GB	16.1GB,29.7GB,22.4G
网络读平均（Mb/s）	180,428,459	358,441,465	182,457,451
网络读最大（Mb/s）	743,1420,1130	1040,1060,1310	739,1300,1170
网络写平均（Mb/s）	183,440,469	361,440,463	175,445,441
网络写最大（Mb/s）	932,1140,1270	1460,1200,1430	564,1250,1130
IOPS 读平均（io/s）	103,908,746	184,491,370	97.1,733,604
IOPS 读最大（io/s）	359,1680,2470	1280,1580,1170	321,1730,1840
IOPS 写平均（io/s）	57,193,162	73,211,172	64,214,175
IOPS 写最大（io/s）	481,336,369	427,349,320	451,333,342
IO 读取平均速率（MB/s）	12.7,35.5,32.8	19.5,36.8,33	11.9,34.1,31.1
IO 读取最大速率（MB/s）	54.3,90.7,96.7	118,102,109	58.4,112,105
IO 写入平均速率（MB/s）	26.9,83.6,70.3	26.8,86.5,72.1	27.4,88.4,74.1
IO 写入最大速率（MB/s）	210,141,133	153,143,132	194,139,124
IO 负载平均	27.7%,66.6%,49.2%	29.7%,63.7%,49.8%	27.2%,66.8%,52.2%
IO 负载最大	71.5%,94.9%,84.9%	97.6%,96.3%,86%	63.5%,97.2%,93.4%

StarRocks 写入和更新的资源占用指标统计如下：

指标	BE1	BE2	BE3
CPU 平均利用率	18.5%,32%,31%	19%,33.5%,33%	21.5%,32.5%,32%
CPU 最大利用率	92%,49%,44%	85%,48%,45%	87%,46%,45%
内存平均使用	32.2G,25.4G,25.9G	32.3G,25.4G,25.9G	31.2G,25.1G,25.9G
内存最大使用	38.3G,29.3G,29.2G	38.2G,29.5G,29.2G	38.1G,29.5G,28.8G
网络读平均（Mb/s）	300,390,369	299,389,370	296,384,365
网络读最大（Mb/s）	1240,869,916	1490,903,869	1660,768,868
网络写平均（Mb/s）	290,378,357	300,387,369	304,395,373
网络写最大（Mb/s）	1430,845,899	1740,872,798	1500,833,822
IOPS 读平均（io/s）	194,344,280	207,423,332	204,334,278
IOPS 读最大（io/s）	1050,694,963	1180,713,1010	434,884,721
IOPS 写平均（io/s）	88,178,198	92,180,199	87,180,197
IOPS 写最大（io/s）	679,271,331	728,320,300	585,295,331
IO 读取平均速率（MB/s）	23.3,41.5,32.9	24.3,41.9,34.1	24,43.5,35
IO 读取最大速率（MB/s）	140,90.8,80.9	153,116,81	121,99,73.5
IO 写入平均速率（MB/s）	37.3,69.3,74.5	38,69.7,74	37.9,70.1,73.9
IO 写入最大速率（MB/s）	276,111,118	273,113,114	252,119,126
IO 负载平均	22%,48.3%,45.2%	22.8%,49.8%,47.4%	27.4%,50.6%,46.6%
IO 负载最大	85.8%,80.1%,74.4%	83.5%,77.8%,75.7%	86.6%,87.3%,71.8%

在每次导入后立即对 StarRocks 和 Doris 进行主键表的查询，查询条件和明细表一致。

Doris 查询：

查询	第一次导入	第二次导入	第三次导入
Q0	0.08s	0.08s	0.06s
Q1	0.21s	0.19s	0.2s
Q2	7.42s	7.84s	7.69s
Q3	12.72s	13.33s	12.91s
Q4	0.38s	0.42s	0.38s
Q5	0.29s	0.3s	0.29s
Q6	0.11s	0.11s	0.11s
Q7	0.16s	0.16s	0.16s
Q8	0.16s	0.18s	0.17s

StarRocks 查询：

查询	第一次导入	第二次导入	第三次导入
Q0	0.09s	0.15s	0.17s
Q1	0.29s	0.29s	0.26s
Q2	5.74s	6.2s	5.77s
Q3	16.73s	18.28s	16.87s
Q4	0.45s	0.48s	0.43s
Q5	0.38s	0.39s	0.38s
Q6	0.16s	0.23s	0.21s
Q7	0.18s	0.18s	0.19s
Q8	0.18s	0.2s	0.17s

根据以上的更新和查询结果总结如下：

1. 无论是 StarRocks 还是 Doris，多次的更新并不会影响查询的效率，也就是说在高频的数据更新场景下也可以保证查询的性能。
2. 无论是 StarRocks 还是 Doris，更新写入占用的资源都比初次写入要高，更新写入的速度也都比初次导入速度要快。
3. StarRocks 比 Doris 写入放大更大，在当前的数据表设计前提下大约是 6GB/亿。
4. StarRocks 初次写入占用的 CPU、内存和 IO 资源都比 Doris 高，但是增量更新整体占用的 CPU 和内存和 IO 负载都会略低于 Doris，不过其中写入的 IOPS 又要比 Doris 高，侧面说明 StarRocks 写放大更大一些。
5. 写入速度上初次写入 StarRocks 快于 Doris（10%~20%），但是后续更新写入 Doris 快于 StarRocks（10%~20%）。
6. StarRocks 多次更新时时间会有增加的倾向，Doris 时间上反而有降低的趋势，或者也可以说 StarRocks 写入速度受版本数量影响更大，而 Doris 受版本数量影响更小。
7. StarRocks 会一直占用 1~2 核的 CPU 后台合并版本，直到消除过期版本保证底层数据没有重复为止，也就是说只要底层存在重复 StarRocks 就会一直工作直到完成所有的版本合并；而 Doris 是根据写入情况进行合并，写入活跃合并的就快一些，写入慢合并的就慢，所以版本数量会保持在一定的水平，并不保证在底层完全消除过期的版本。