StarRocks 性能实测:在 Coffee-shop Benchmark 中快 10 倍!

本文涉及的产品
RDS MySQL DuckDB 分析主实例,基础系列 4核8GB
云数据库 PolarDB MySQL 版,列存表分析加速 8核16GB
RDS Agent(兼容OpenClaw),2核4GB
简介: 在评估数据库性能时,如何同时衡量“算得快”和“算得省”一直是工程师关注的核心问题。

3.PNG

在评估数据库性能时,如何同时衡量“算得快”和“算得省”一直是工程师关注的核心问题。

Coffee-shop Benchmark [1] 是由社区研究者提出的公开测试,用于评估不同数据库系统在计算密集型 Join 与 Aggregation 工作负载下的性能与成本表现。由于其查询设计兼具业务代表性与计算复杂度,能够较全面地反映分析型数据库在真实工作负载下的表现,因此被用于对比 Databricks、Snowflake、ClickHouse 等主流系统 [2–6]。

测试内容模拟了典型的零售与门店经营分析场景,涵盖销售趋势、利润分析、折扣策略等多种典型查询类型,能够较全面地反分析型数据库的执行性能与资源效率。


出于研究兴趣与工程验证,我们在相同的测试逻辑与实例规格下,复现了 Coffee-shop Benchmark 的 17 个查询 [1,4],并在 StarRocks 上完成了 500M、1B、5B 三种规模的数据集验证。

结果显示,在这些涉及大量 Join 与高基数聚合的复杂查询中,StarRocks 以更低的成本和更短的运行时间完成了全部测试,整体性能与成本效率较参考系统提升约 2–10 倍。


这一结果不仅验证了 StarRocks 在算子优化、向量化执行和资源调度方面的工程实力,也意味着在广告归因、用户画像、实时看板等典型场景中,企业可以用更少的资源获得更快的分析体验。

对关注实时分析性能与成本优化的开发者和架构师而言,这一测试结果为系统选型与性能评估提供了一个客观、可复现的参考,也进一步印证了 StarRocks 在 Lakehouse 架构下的高性价比优势。

数据集特征

Coffee-shop benchmark 的数据集包含一个事实表 (fact_sales )与两个维度表( dim_locationsdim_products)组成:

  • 维度表:行数固定,不随数据规模变化。
  • dim_locations:1000 行
  • dim_products:26 行
  • 事实表:fact_sales 的行数随规模不同而变化。
    500M scale:0.72B rows
    1B scale:1.44B rows
    5B scale:7.2B rows

在查询类型上,Coffee-shop Benchmark 涵盖了两类典型的 Join 场景:

  1. 等值 Joinfact_salesdim_locationslocation_id 列上进行等值关联。该列为 VARCHAR 类型,能够有效验证系统在大规模分布式 Join 下的并行执行与数据分片效率。
  2. 范围 Join(Range Join)fact_salesdim_products 通过 name 列关联,同时包含时间范围条件 f.order_date BETWEEN p.from_date AND p.to_date。这种模式在实际业务中常见(如带有效期的商品维度表),能够检验系统对复杂 Join 条件的优化与执行效率。


除 Join 外,17 个查询还覆盖了多种 Aggregation 模式。其中包括 COUNT DISTINCT 在内的多种聚合函数,并在不同列组合下进行 GROUP BY。其中最具挑战性的为 Q10 与 Q16,它们执行 COUNT(DISTINCT order_id) 并以多个列进行 GROUP BY。由于 order_id 的唯一值极多,平均每个 key 仅出现不到两次,这类查询对系统的中间聚合、去重和内存管理提出了极高要求。


在这类大量数据 Join 和高基数聚合场景中,StarRocks 在高效的 Hash Map 实现、多阶段聚合、Join Runtime Filter、低基数字典优化等机制协同作用下,能够在复杂的 Join 与聚合查询中稳定保持较高的性能与资源利用率。

测试环境

为确保测试结果具备可比性,我们采用了与前人研究相近的实例配置和数据分布方式:

  • 实例配置
    FE 节点:1 * m7g.2xlarge (8 vCPUs, 32GB Memory),负责查询解析、计划生成、调度与结果返回。
    BE 节点:m7g.8xlarge (32vCPUs, 128GB Memory),负责查询执行。
  • 500M scale:2 或 4 个实例。
  • 1B scale:2 或 4 个实例。
  • 5B scale:8 或 16 个实例。
  • 建表策略:测试使用了 Order Key 与 Hash Bucket Key 的分布策略,具体的建表语句、导入和执行 Query 的脚本详见:Coffee Shop Benchmark on StarRocks。原始测试包含 “Clustered” 与 “Non-clustered” 两种布局,为了保持结果一致性,我们仅展示 Clustered 模式的结果。
  • 数据导入:使用了 ClickHouse 公开的 Coffee-shop 数据集 [4]。借助 StarRocks 的存算分离架构,数据只需导入一次,即可在不同节点配置下进行测试。通过简单调整计算节点数量,即可完成 scale-in / scale-out,无需重复导入数据。
  • 查询语句:完全复现原始 Coffee-shop Benchmark 的 17 个查询,仅对少量不兼容语法(如 CREATE OR REPLACE TABLE)进行等价替换,不改变语义与逻辑。
  • StarRocks 版本:测试基于 StarRocks 4.0.1。除默认配置外,仅对 fact_sales 表的 (order_date, location_id) 列进行了联合统计信息收集,以帮助优化器生成更优计划;其他参数均保持默认。

测试方法

每个查询执行 5 次,取最短一次结果作为 warm-cache 性能。

对比系统(ClickHouse、Snowflake、Databricks)的结果参考了已公开的研究与博客 [2–6],并在相同数据规模(500M、1B、5B)下进行对比,用于评估整体运行时间与成本效率。

测试结果

测试结果:500M Scale (0.72B Rows)

Total Cost

Total Runtime

Cost per Query (Except Q10 & Q16)

Runtime per Query (Except Q10 & Q16)

Cost per Query (Q10 & Q16 Only)

Runtime per Query (Q10 & Q16 Only)

测试结果:1B Scale (1.44B Rows)

Total Cost

Total Runtime

Cost per Query (Except Q10 & Q16)

Runtime per Query (Except Q10 & Q16)

Cost per Query (Q10 & Q16 Only)

Runtime per Query (Q10 & Q16 Only)

测试结果:5B Scale (7.2B Rows)

Total Cost

Total Runtime

Cost per Query (Except Q10 & Q16)

Runtime per Query (Except Q10 & Q16)

Cost per Query (Q10 & Q16 Only)

Runtime per Query (Q10 & Q16 Only)

结果分析

Coffee-shop Benchmark 共包含 17 个查询,覆盖 Join、Aggregation、窗口函数、排序等多种复杂操作。其中 Join 和 Aggregation 是大多数查询的主要计算瓶颈。

在 500M、1B、5B 三种数据规模下,StarRocks 均展现出出色的线性扩展性与资源利用效率:

  • 大部分查询:在 500M 与 1B 规模下,平均查询耗时仅约 0.5 秒,在 5B 规模下也能在 1 秒左右 完成,性能稳定且具备良好的扩展性。
  • 高负载查询(Q10、Q16):面对包含 7.2B 行数据的 Join 与高基数 COUNT DISTINCT 聚合,StarRocks 在 5 的规模下仅需约 10 秒即可完成查询,显著降低了执行开销。
  • 整体性能与成本:在相近的硬件配置与相同的数据规模下,StarRocks 展现出较高的查询性能与成本效率优势,在多数场景下实现了明显的资源节省与执行性能提升。

这些结果表明,StarRocks 在复杂分析型负载下能够充分利用多节点计算资源,并在高 Join、高基数聚合场景中依旧保持稳定的性能与成本平衡。

进一步测试与说明

需要说明的是,Coffee-shop Benchmark 的维度表规模相对较小(分别为 26 行与 1000 行),主要用于验证以事实表为主的数据分析场景。

在更复杂的工业标准测试(如 TPC-DS)中,StarRocks 同样在多表 Join 与大规模聚合等高负载场景下表现稳定,继续保持出色的性能与成本效率平衡。

更多详细测试结果可参考 👉StarRocks TPC-DS Benchmark

引用

  1. Coffee Shop Benchmark
  2. Databricks vs Snowflake SQL Performance Test, Day 1: 721M Rows Test
  3. Databricks vs Snowflake Gen 1 & 2 SQL Performance Test, Day 2: 1.4B & 7.2 Rows Test
  4. Coffee Shop Benchmark for ClickHouse
  5. Join me if you can: ClickHouse vs. Databricks & Snowflake - Part 1
  6. Join me if you can: ClickHouse vs. Databricks & Snowflake - Part 2
  7. Coffee Shop Benchmark on StarRocks
  8. StarRocks TPC-DS Benchmark
相关文章
|
8月前
|
存储 SQL 消息中间件
从 ClickHouse 到 StarRocks 存算分离: 携程 UBT 架构升级实践
查询性能实现从秒级到毫秒级的跨越式提升
|
7月前
|
存储 缓存 Cloud Native
EMR StarRocks Stella 内核正式发布,登顶 TPC 榜单全球第一
EMR Serverless StarRocks 重磅发布全新企业级版本内核 Stella (StarRocks Efficient and Lightening-fast Lakehouse),完全兼容开源 StarRocks,为用户提供企业级的产品功能、卓越的性能及稳定性保障。
|
12月前
|
NoSQL Java 数据库连接
实战|StarRocks 通过 JDBC Catalog 访问 MongoDB 的数据
本文章介绍如何通过 StarRocks 的 JDBC Catalog 功能,结合 MongoDB BI Connector,将 MongoDB 数据便捷接入 StarRocks,实现数据打通和 SQL 查询分析,以下是整体流程图。
|
存储 Java
Bitmap位图(Java实现)
本文介绍了使用Java实现一个简单的Bitmap,通过自定义byte数组存储数据,提供put和exist方法分别用于插入数据和查询数据是否存在。Bitmap利用位操作高效地管理大量布尔值,适用于空间优化的场景。代码中详细解释了位图的核心原理、方法实现及边界检查。后续计划探讨位图在海量数据去重中的应用及JDK BitSet源码分析。
999 7
|
10月前
|
存储 人工智能 算法
Java 大视界 -- Java 大数据在智能医疗影像数据压缩与传输优化中的技术应用(227)
本文探讨 Java 大数据在智能医疗影像压缩与传输中的关键技术应用,分析其如何解决医疗影像数据存储、传输与压缩三大难题,并结合实际案例展示技术落地效果。
|
SQL JavaScript 前端开发
Vue实现动态数据透视表(交叉表)
Vue实现动态数据透视表(交叉表)
605 13
|
SQL 监控 API
Flink教程(27)- Flink Metrics监控
Flink教程(27)- Flink Metrics监控
1139 1
|
SQL 存储 缓存
降本60% ,阿里云 EMR StarRocks 全新发布存算分离版本
阿里云 EMR Serverless StarRocks 现已推出全新存算分离版本,该版本不仅基于开源 StarRocks 进行了全面优化,实现了存储与计算解耦架构,还在性能、弹性伸缩以及多计算组隔离能力方面取得了显著进展。
1642 62
|
人工智能 缓存 前端开发
通过API接口实现1688图片搜索商品功能全攻略
本文详细介绍如何通过API接口实现1688图片搜索商品功能,并对接至自有系统。核心流程包括:用户上传图片后,利用百度AI图像识别API提取特征并生成关键词,再调用1688开放平台的商品搜索接口获取结果。技术方案采用Python开发,涵盖前端交互设计与后端集成要点,如接口服务化、缓存机制及异常处理。此外,文章还提供了性能优化建议和数据解析示例,适用于电商平台及多种扩展场景。
|
运维 监控 网络协议
运维工程师日常工作中最常用的20个Linux命令,涵盖文件操作、目录管理、权限设置、系统监控等方面
本文介绍了运维工程师日常工作中最常用的20个Linux命令,涵盖文件操作、目录管理、权限设置、系统监控等方面,旨在帮助读者提高工作效率。从基本的文件查看与编辑,到高级的网络配置与安全管理,这些命令是运维工作中的必备工具。
1242 3