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资源陆续释放,实现降本增效

相关推荐
冬奇Lab11 小时前
每日一个开源项目(第134篇):Zvec - 阿里开源的嵌入式向量数据库,向量搜索界的 SQLite
数据库·人工智能·llm
ClouGence1 天前
Oracle CDC 架构优化:从主库直连到 DataGuard 备库同步
数据库·后端·oracle
无响应de神1 天前
三、用户与权限管理
数据库·mysql
大树882 天前
金刚石散热越强,管路越先见顶
大数据·运维·服务器·人工智能·ai
摇滚侠2 天前
Linux CentOS7 rpm 安装 MySQL 5.7
linux·运维·mysql
霸道流氓气质2 天前
领域驱动设计(DDD)在 Spring Boot 微服务中的实践指南
运维·spring boot·微服务
小宇宙Zz2 天前
Maven依赖冲突
java·服务器·maven
Inhand陈工2 天前
基于台达PLC与映翰通IG502的智慧水产养殖精准投喂与远程运维解决方案
运维·人工智能·物联网·阿里云·信息与通信
酣大智2 天前
ARP代理--工作原理
运维·网络·arp·arp代理
麦聪聊数据2 天前
数据服务化时代:企业数据能力输出的核心路径
数据库