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

本文涉及的产品
RDS MySQL DuckDB 分析主实例,集群系列 4核8GB
RDS AI 助手,专业版
简介: 在评估数据库性能时,如何同时衡量“算得快”和“算得省”一直是工程师关注的核心问题。

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
相关文章
|
4月前
|
存储 SQL 消息中间件
从 ClickHouse 到 StarRocks 存算分离: 携程 UBT 架构升级实践
查询性能实现从秒级到毫秒级的跨越式提升
|
3月前
|
存储 缓存 Cloud Native
EMR StarRocks Stella 内核正式发布,登顶 TPC 榜单全球第一
EMR Serverless StarRocks 重磅发布全新企业级版本内核 Stella (StarRocks Efficient and Lightening-fast Lakehouse),完全兼容开源 StarRocks,为用户提供企业级的产品功能、卓越的性能及稳定性保障。
|
8月前
|
NoSQL Java 数据库连接
实战|StarRocks 通过 JDBC Catalog 访问 MongoDB 的数据
本文章介绍如何通过 StarRocks 的 JDBC Catalog 功能,结合 MongoDB BI Connector,将 MongoDB 数据便捷接入 StarRocks,实现数据打通和 SQL 查询分析,以下是整体流程图。
|
8月前
|
人工智能 监控 中间件
深入解析|Cursor编程实践经验分享
本文是近两个月的实践总结,结合在实际工作中的实践聊一聊Cursor的表现。记录在该过程中遇到的问题以及一些解法。问题概览(for 服务端): 不如我写的快?写的不符合预期? Cursor能完成哪些需求?这个需求可以用Cursor,那个需求不能用Cursor? 历史代码分析浅显,不够深入理解? 技术方案设计做的不够好,细节缺失,生成代码的可用性不够满意?
1682 10
深入解析|Cursor编程实践经验分享
|
6月前
|
存储 人工智能 算法
Java 大视界 -- Java 大数据在智能医疗影像数据压缩与传输优化中的技术应用(227)
本文探讨 Java 大数据在智能医疗影像压缩与传输中的关键技术应用,分析其如何解决医疗影像数据存储、传输与压缩三大难题,并结合实际案例展示技术落地效果。
|
SQL 监控 API
Flink教程(27)- Flink Metrics监控
Flink教程(27)- Flink Metrics监控
976 1
|
SQL 存储 缓存
降本60% ,阿里云 EMR StarRocks 全新发布存算分离版本
阿里云 EMR Serverless StarRocks 现已推出全新存算分离版本,该版本不仅基于开源 StarRocks 进行了全面优化,实现了存储与计算解耦架构,还在性能、弹性伸缩以及多计算组隔离能力方面取得了显著进展。
1309 62
|
运维 监控 网络协议
运维工程师日常工作中最常用的20个Linux命令,涵盖文件操作、目录管理、权限设置、系统监控等方面
本文介绍了运维工程师日常工作中最常用的20个Linux命令,涵盖文件操作、目录管理、权限设置、系统监控等方面,旨在帮助读者提高工作效率。从基本的文件查看与编辑,到高级的网络配置与安全管理,这些命令是运维工作中的必备工具。
1065 3
|
人工智能 自然语言处理 机器人
手把手带你搭建一个语音对话机器人,5分钟定制个人AI小助手(新手入门篇)
本文介绍了如何从零开始搭建一个语音对话机器人,涵盖自动语音识别(ASR)、自然语言处理(NLP)和文本到语音合成(TTS)三大核心模块。通过使用开源工具如FunASR、LLaMA3-8B和ChatTTS,以及FastAPI和Gradio等技术,详细指导读者轻松实现个人AI小助手的构建,适合技术新手快速上手。
6097 1
|
机器学习/深度学习 弹性计算 编解码
阿里云服务器c7/c8a/c8y/c8i/g7/g8a/g8y/g8i/r7/r8a/r8y/r8i实例区别及选择参考
在阿里云目前的活动中,除了特价的轻量应用服务器和经济型e及通用算力型u1实例之外,属于计算型实例的实例有计算型c7/c8a/c8y/c8i,属于通用型实例的有通用型g7/g8a/g8y/g8i,属于内存型实例的有内存型r7/r8a/r8y/r8i。本文将详细介绍阿里云服务器中的c7、c8a、c8y、c8i、g7、g8a、g8y、g8i、r7、r8a、r8y、r8i等实例规格的性能、适用场景及选择参考,帮助用户更好地选择合适的云服务器实例。