TiDB替换Starrocks:业务综合宽表迁移的性能评估与降本增效决策

作者: 我是人间不清醒 原文来源: https://tidb.net/blog/6638f594

1、 场景

业务综合宽表是报表生成、大屏幕展示和数据计算处理的核心数据结构。目前,这些宽表存储在Starrocks系统中,但该系统存在显著的性能瓶颈。例如,在高峰时段,查询性能(QPS)仅为20,99th百分位响应时间长达2.5分钟,且CPU和内存资源接近饱和。特别是在2024年,系统多次遭遇后端内存耗尽(OOM)的情况,导致需要手动干预才能恢复正常运行。鉴于Starrocks系统的版本较旧,我们正在考虑对其进行升级或者迁移到Tidb集群中。

为了评估升级Starrocks系统或迁移到TiDB集群的可行性,我们对同一环境下的TiDB集群进行了压力测试。测试结果表明,TiDB集群的性能表现超出了我们的预期,因此我们决定将业务综合宽表迁移到TiDB集群。

2、 宽表信息

3、 集群配置

复制代码
  Starrocks 版本2.3.0 a9bdb09

image760×194 3.54 KB

复制代码
 Tidb 版本 8.0.11-TiDB-v8.1.0

image753×273 4.75 KB

4、 Sql查询对比

image768×642 24.5 KB

\

image765×608 27.2 KB

5、Jmeter压测对比

压测准备:windows11 16核32G 安装jmeter

教程: Jmeter保姆级安装教程(超详细建议收藏加关注)_jmeter安装详细教程-CSDN博客

SQL语句准备:研发提供的复杂sql查询

线程配置:线程数200 ramp-up时间 10,持续300s;10秒钟拉起200个进程,持续300s

image1065×259 64.8 KB

Tidb和Starrocks服务器CPU情况:

image1099×315 37.3 KB

\

image1150×349 49.2 KB

6、结果

根据测试结果分析,Tidb在压力测试期间,除TidbServer的CPU使用率较高外,TiKV和TiFlash的表现均符合预期。然而,Starrocks的三台服务器CPU使用率过高,且吞吐量指标未能达到理想状态。

7、后续规划

鉴于Starrocks系统的性能瓶颈和资源饱和问题,以及TiDB集群在压力测试中表现出的优越性能,我们决定将业务综合宽表从Starrocks迁移到TiDB集群,并将Starrocks资源陆续释放,实现降本增效

相关推荐
YJlio1 天前
PsService·下(7.21):Find/SetConfig 与服务的启动/停止/重启/暂停/恢复
linux·运维·服务器
草莓熊Lotso1 天前
C++ 继承特殊场景解析:友元、静态成员与菱形继承的底层逻辑
服务器·开发语言·c++·人工智能·经验分享·笔记·1024程序员节
weixin_ab1 天前
【雪花算法与主键自增:场景适配指南,从分布式特性到业务需求】
tidb
NPE~1 天前
[手写系列]Go手写db — — 第七版(实现Disk存储引擎、Docker化支持)
数据库·后端·docker·golang·教程·手写数据库
_OP_CHEN1 天前
Linux系统编程:(六)深入理解 Linux 软件包管理器——从原理到 yum 实战全攻略
linux·运维·服务器·yum·软件包管理器·linux生态
路過的好心人1 天前
Nginx 的多个场景配置
运维·网络·nginx
9ilk1 天前
【基于one-loop-per-thread的高并发服务器】--- 前置技术
运维·服务器·c++·笔记·后端·中间件
qq_343247031 天前
docker 下搭建 nacos
运维·docker·容器
人工智能训练1 天前
Ubuntu系统中Docker的常用命令总结
linux·运维·人工智能·ubuntu·docker·ai
workflower1 天前
FDD与其他方法的相似和区别
数据库·算法·需求分析·个人开发