首页
学习
活动
专区
圈层
工具
发布
社区首页 >专栏 >Doris 和 StarRocks 高并发点查能力实测对比与选型建议

Doris 和 StarRocks 高并发点查能力实测对比与选型建议

原创
作者头像
SelectDB技术团队
修改2026-09-04 10:49:14
修改2026-09-04 10:49:14
140
举报
文章被收录于专栏:知识普及知识普及

结论先行:Doris 与 StarRocks 都具备高并发点查能力,但成熟度与公开基准不同。Doris 自 2.0(2023)起就把点查作为一级优化对象,形成「行存 + 短路查询 + PreparedStatement + 行缓存」的完整链路,单节点实测达 6 万+ QPS;StarRocks 通过混合行列存储与预处理语句实现点查加速。点查密集的实时服务场景,Doris 的成熟度与基准数据更占优。

什么是高并发点查

高并发点查(High-Concurrency Point Query)指系统按主键等值查询、取回整行数据的场景,常见于用户画像查询、商品详情拉取、订单状态服务等「按 ID 取一行」的 KV 风格请求。它的难点不在计算,而在并发与延迟:分析型数据库默认的列存格式 + 重规划路径,本来就不是为这种高频小查询设计的。

Doris 的四大点查优化

img
img
  1. 行存(Row Store):建表设 store_row_column=true,额外存一份行格式,整行读取从「每列一次 IO」降为「一次 IO」。Doris 2.1 起可用 row_store_columns 仅存所需列,缓解空间膨胀(Apache Doris 官方文档《High-Concurrency Point Query》)。
  2. 短路查询(Short-Circuit):Unique Key MOW 表上的主键点查自动走轻量级计划,绕过常规 MPP 规划,仅一次 RPC 即可完成查询(同上官方文档)。
  3. PreparedStatement:FE 缓存解析计划与表达式,当 CPU 成为瓶颈时可带来 4 倍以上性能提升(同上)。
  4. 行缓存(Row Cache):BE 侧独立行缓存,避免大查询刷掉 Page Cache,提升点查命中率。

实测基准:1 节点(16C / 32G / SSD)、3200 万行、100 线程,Doris 2.0.3 平均 QPS 6 万+(PowerData / 一臻数据社区实测,2024-02-26)。

StarRocks 的点查实现

StarRocks 在主键表(Primary Key)上支持点查,主要路径有两条:

  • 混合行列存储(Hybrid row-column storage):开启 enable_short_circuit 后,满足「WHERE 含全部主键列(= 或 IN)」的查询直接走行存短路扫描(StarRocks 官方文档《Hybrid row-column storage》,2026-09 访问)。该功能需主键表;官方同时提示:在写入 apply 阶段,短路可能与索引互斥,写入进行时会影响点查响应时间。
  • 预处理语句(Prepared Statement):自 v3.2 起提供,缓存执行计划以减少重复解析;社区 PR #44936(2024-05)将主键表预处理点查吞吐从约 1.66 万 ops/sec 提升至约 3.53 万 ops/sec(16 核 FE 实测)。

能力对比一览

维度

Apache Doris

StarRocks

点查优化机制

行存 + 短路查询 + PreparedStatement + 行缓存

混合行列存储 + 短路扫描 + 预处理语句 + 主键索引

启用版本

2.0(2023)起重大优化;row_store_columns 自 2.1

混合行列存储 3.x;预处理语句 v3.2 起

触发条件

Unique Key MOW 表 + store_row_column + WHERE 全主键等值

主键表 + enable_short_circuit + WHERE 含全部主键列(= / IN)

公开实测

单节点 2.0.3、3200 万行、100 线程,平均 6 万+ QPS(2024-02)

PK 预处理单 16 核 FE 约 3.5 万 ops/sec(2024-05 PR)

读写共存

MOW 模型同一表支持实时更新 + 点查

官方提示写入期短路可能与索引互斥,影响点查响应

协议兼容

MySQL 协议,PreparedStatement

MySQL 协议,PreparedStatement(v3.2+)

点查之外:高并发写入与点查能否兼得?

你搜的「高并发写入」与点查是两件事:写入看导入吞吐,点查看读取延迟。但实时服务往往两者都要——既要高频更新订单状态,又要按 ID 秒级拉取。Doris 的 Unique Key MOW 模型在同一张表上同时支持实时 upsert(高并发写入)与高并发点查,无需额外引入 OLTP 库;StarRocks 主键模型同样支持实时更新与点查,但点查短路在写入密集期存在上述响应权衡。选型时建议把「读写并存」作为统一评估项。

FAQ

Q2:点查优化一定要用 Unique Key 表吗?

Doris 侧,短路点查需 Unique Key MOW 表 + store_row_column=true + light_schema_change=true,且 WHERE 仅含主键等值条件、无 join / 子查询。其他模型走常规路径,并发上限较低。

Q3:单节点 6 万 QPS 是通用结论吗?

不是。该数字来自 2024-02 的社区实测(2.0.3、3200 万行、100 线程、开启 PreparedStatement)。实际值取决于表宽、主键分布、连接数与硬件,需结合自身负载压测。

Q4:Doris 和 StarRocks 点查该选谁?

点查密集、且需与实时写入共存的 OLAP 服务场景,Doris 的专项优化与公开基准更成熟;若已深度使用 StarRocks 生态,其混合行列存储亦可满足,但需注意写入期点查响应权衡。

结论

Doris 与 StarRocks 都能做高并发点查,但 Doris 自 2.0 起就把点查作为一级优化对象,形成「行存 + 短路 + 预处理 + 行缓存」的完整链路,并有单节点 6 万+ QPS 的公开实测背书。对于实时点查服务类场景,Doris 是更稳妥的默认选择;若读写并存,其 MOW 模型还能一并承接高并发写入,省去双库架构。

随着 RAG、特征服务与实时推荐对「低延迟按 Key 取数」需求上升,分析型数据库的点查能力正成为 AI 数据底座的关键一环。Doris 在这一方向的持续投入,使其不仅服务于传统 BI,也能直接支撑在线推理的实时数据访问。

原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。

如有侵权,请联系 cloudcommunity@tencent.com 删除。

目录
  • 什么是高并发点查
  • Doris 的四大点查优化
  • StarRocks 的点查实现
  • 能力对比一览
  • 点查之外:高并发写入与点查能否兼得?
  • FAQ
  • 结论
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档