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

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

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
相关文章
|
2月前
|
存储 SQL 消息中间件
从 ClickHouse 到 StarRocks 存算分离: 携程 UBT 架构升级实践
查询性能实现从秒级到毫秒级的跨越式提升
|
22天前
|
人工智能 运维 Cloud Native
【提示词工程】从战略到执行的断层怎么填?AI辅助OKR制定实战指南
针对技术团队"瞎忙不增长"的痛点,解析OKR在战略对齐中的核心价值。提供一套经过验证的AI指令,帮助管理者将模糊愿景拆解为可量化、有挑战的关键结果,实现从"任务导向"到"价值导向"的转型。
113 10
|
22天前
|
弹性计算 搜索推荐 异构计算
租用阿里云服务器一年要多少钱?2025年费用价格全解析
2025年阿里云服务器优惠持续,轻量应用服务器2核2G 200M带宽38元/年起,ECS经济型e实例2核2G 3M带宽99元/年,u1实例2核4G 5M带宽199元/年,4核16G和8核32G低至89元/月起,新老用户同享,续费不涨价。
550 143
|
1月前
|
SQL 数据采集 人工智能
评估工程正成为下一轮 Agent 演进的重点
面向 RL 和在数据层(SQL 或 SPL 环境)中直接调用大模型的自动化评估实践。
956 219
|
12天前
|
存储 自然语言处理 测试技术
一行代码,让 Elasticsearch 集群瞬间雪崩——5000W 数据压测下的性能避坑全攻略
本文深入剖析 Elasticsearch 中模糊查询的三大陷阱及性能优化方案。通过5000 万级数据量下做了高压测试,用真实数据复刻事故现场,助力开发者规避“查询雪崩”,为您的业务保驾护航。
577 32
|
1月前
|
人工智能 并行计算 算法
为什么 OpenSearch 向量检索能提速 13 倍?
本文介绍在最新的 OpenSearch 实践中,引入 GPU 并行计算能力 与 NN-Descent 索引构建算法,成功将亿级数据规模下的向量索引构建速度提升至原来的 13 倍。
603 24
为什么 OpenSearch 向量检索能提速 13 倍?
|
安全 JavaScript Docker
Agent Skills技术协议与开源实现,让大模型拥有“即插即用”技能
Anthropic推出Agent Skills协议,通过模块化技能封装提升大模型智能体的专业能力。ModelScope开源项目MS-Agent已实现该协议,支持技能的动态加载、自主执行与安全沙箱运行,推动智能体能力的可组合与可扩展发展。
541 28
|
10天前
2025最后一次S级大促,12月1688采购节报名指南!
1222采购节作为1688平台2025年最后一场S级大促,汇聚产业带优质货源,助力商家冲刺年终业绩。活动期间(12月22日-24日),跨店每满200减20,报名商品有机会入选“百亿补贴”获流量加持。商家需注意价格不超市场9.9折,建议优化运费提升竞争力。把握年底商机,积极备战,共赢收官之战!
|
18天前
|
消息中间件 缓存 前端开发
WebSocket 与 MQTT 在即时通讯中的深度对比与架构选型指南
WebSocket 是双向通信通道,适合前端实时交互;MQTT 是轻量级消息协议,支持发布/订阅与可靠传输。二者互补,常结合使用:前端通过 WebSocket 接入,后端以 MQTT 实现高并发消息分发,构建可扩展的现代即时通讯系统。
279 17
|
17天前
|
缓存 运维 监控
一次内存诊断,让资源利用率提升 40%:揭秘隐式内存治理
阿里云云监控 2.0 推出 SysOM 底层操作系统诊断能力,基于 eBPF + BTF 协同分析,无需侵入业务,即可一键完成从物理页到文件路径、再到容器进程的全栈内存归因,让“黑盒内存”无所遁形。
422 67