【PolarDB Serverless】资源伸缩&压测 TPC-C 测评

本文涉及的产品
云数据库 RDS MySQL,集群系列 2核4GB
推荐场景:
搭建个人博客
云原生数据库 PolarDB 分布式版,标准版 2核8GB
云数据库 RDS SQL Server,基础系列 2核4GB
简介: 【PolarDB Serverless】资源伸缩&压测 TPC-C 测评

DataBase数据库,作为基础软件之一,是必不可缺的存在。在云原生流行的今天,许多对可用性要求高的场景任然在使用服务器物理承载数据库,构建集群。在业务逐渐从虚机到容器化再到Serverless的今天,云原生数据库Polardb提供了传统关系型和分布式数据库的能力,Serverless化对底层算力的分配带来了更加精细的粒度。Polardb有多种形态,完全兼容Mysql & Postgre 对应着 Polardb Mysql版和Polardb PostgreSQL版,皆Share Storage,计算存储分离、共享存储的架构。主节点和只读节点使用物理复制、RDMA网络低时延,能够快速同步数据,彻底解决了主从异步复制所带来的备库数据非强一致的问题

Serverless将实现Polardb的资源、存储、网络的垂直隔离,实现弹性灵活高可用的云原生数据库。Polardb Serverless版也是由垂直三部分即,数据库代理PolarProxy+数据库节点RW/RO+数据库分布式存储PolarStore 组成,后续也会围绕数据库的架构展开。

其他有关基础概念不再概述,每一位博主都提过了,可以参考官方的文档:https://help.aliyun.com/zh/polardb/polardb-for-mysql/user-guide/overview-27?spm=a2c4g.11186623.0.0.247f7621KW28hW

一、PolarDB MySQL 版 Serverless 基础

关于购买和开通集群的步骤这里不再赘述,不做重复性搬运了,阿里云官方的文档非常详细。

Serverless已经跳脱传统云服务“几核心几G内存”的概念了,因此在使用Serverless能力之前,必须要了解计费的规则和PCU的概念(PolarDB Capacity Unit)

https://help.aliyun.com/zh/polardb/polardb-for-mysql/user-guide/billing-of-serverless-clusters

完成集群创建后,可在云数据库PolarDB集群列表中看到所创建的集群

点击集群进入集群的详细管理界面。在此界面可详细看到对PolarDB的所有功能,主页【基本信息】也围绕着数据库代理PolarProxy+数据库节点RW/RO+数据库分布式存储PolarStore  三个重要组成部分而展示

1.账户管理

和常规云数据库一样,PolarDB Mysql 集群需要为业务使用创建用户,点击【账号管理】展示当前集群的所有账户

点击【创建账号】,输入账户名同时可选择授权的数据库。PolarDB的数据库高权限账户仅有一个

2.数据库管理

点击【数据库管理】,为后续的测试创建测试数据库DB

【创建数据库】中可支持多种类型的字符集,创建同时可选择授权账号

3.白名单管理

众所周知,云计算的基础是实现租户隔离,PolarDB集群提供了两种安全限制能力,白名单【IP列表】和【安全组】。IP列表白名单针对于IP层的限制,可视为基础ACL;安全组可对于源目的端口或协议类型访问限制,可视为高级ACL。

只有已添加到白名单中的IP地址或安全组中的ECS实例才能访问该集群,白名单对象可以是VPC大内网地址或者公网访问地址。这里添加我们测试所用到的ECS内网地址

同时也可以应用安全组,并且一个PolarDB MySQL版集群中最多可以添加10个安全组。安全组的概念可以参考:

https://help.aliyun.com/zh/ecs/user-guide/create-a-security-group-1#concept-ocl-bvz-xdb

4.Proxy代理地址

PolarDB集群代理,提供了两个入口地址,【主地址】和【集群地址】,【主地址】是直接连接到主节点的服务代理,主节点往往是写入/读取节点,如图

而【集群节点】才是我们业务和使用中对外访问的地址,只有使用【集群节点】地址才算接入自动负载能力,可实现对数据库节点的自动读写分离,如图

在对应代理处点击【配置】,或在代理窗口可以看到,提供【私网】和【公网】两种接入方式,默认提供了对私网的访问能力,也可以点击申请公网+配置白名单就可以在公网进行访问集群

和OSS等云服务一样,这里的域名格式分别为:

主地址私网域名:<集群ID>.mysql.polardb.rds.aliyuncs.com
主地址公网域名:<自定义>.mysql.polardb.rds.aliyuncs.com
集群地址私网域名:<集群ID>.rwlb.rds.aliyuncs.com
集群地址公网域名:<自定义>.rwlb.rds.aliyuncs.com

5.弹性配置

【Serverless配置】,可以说是“极致弹性”的精髓配置,不过相关配置完成后需要等待配置状态完成后才可以进行后续操作

【单节点资源弹升】上限 min: 1PCU~31PCU,max: 1;PCU~32PCU,min<=max

【只读节点个数扩展】上限和下限 0~7个可选, 但下限不能大于上限的值(废话

【是否开启无活动暂停】开启后在设置的无活动暂停的检测时长之内,如果集群无业务连接,则集群自动进入暂停状态;如果有任何业务连接接入集群,那么集群立刻自动启动

也就是说每一个节点的性能资源PCU的规格可动态伸缩,并且伸缩范围是1-32个PCU。1个PCU约等于1核2GB的资源,0.5个PCU约等于0.5核1GB的资源,那么单个节点性能范围约为<1核2G~32核64G>

集群中必存在一个主节点和N个只读节点,只读节点的扩展范围为<0-7>,也就是可以不存在只读节点,极致的省资源和钱钱。

这就是Serverless的横向伸缩和纵向伸缩,即性能资源灵活调整+工作节点灵活调整

二、PolarDB MySQL 版 Serverless 压测和弹性

通过Sysbench脚本访问集群地址进行压测,PolarDB主节点的规格能够根据负载进行自动伸缩与自动配置,达到Serverless的能力。Sysbench是一款开源的多线程性能测试工具,可以执行CPU/内存/线程/IO/数据库等方面的性能测试,可以执行数据库只读、只写、读写混合等类型的性能测试。

1.初始化压测数据

首先粘出来集群访问的域名地址,执行初始化数据命令

POLARDB_URL=xxxx.rwlb.rds.aliyuncs.com
sysbench /usr/share/sysbench/oltp_read_write.lua --mysql-host=$POLARDB_URL --mysql-port=3306 --mysql-user=test_user --mysql-password=Password123 --mysql-db=sbtest --tables=128 --table-size=1000000 --report-interval=1 --range_selects=1 --db-ps-mode=disable --rand-type=uniform --threads=256 --time=12000 prepare

初始化过程如图:

初始化时写入数据的过程,可以在集群监控中观察Serverless监控指标,PCU用量和CPU内存使用率都有明显的升高

初始化完成后,各项指标逐步降低,真的非常的弹性

完成初始化脚本的执行后,我们开始后面的测试

2.并发读写混合压测

调整弹性配置,将上限拉满到32,将只读节点数量置零

并发读写初始只对主节点进行压测

执行压测命令,使用oltp_read_write模块

sysbench /usr/share/sysbench/oltp_read_write.lua --mysql-host=$POLARDB_URL --mysql-port=3306 --mysql-user=test_user --mysql-password=Password123 --mysql-db=sbtest --tables=128 --table-size=1000000 --report-interval=1 --range_selects=1 --db-ps-mode=disable --rand-type=uniform --threads=256 --time=12000 run

--mysql-host=$POLARDB_URL   //连接数据库的地址

--mysql-port=3306  //连接数据库的端口

--mysql-user=test_user   //连接数据库的用户

--mysql-password=Password123   //连接数据库的密码

--mysql-db=sbtest //测试使用的库

--tables=128 //指定表的数量为 128

--table-size=1000000  //指定表行数

--report-interval=1  //指定每秒显示一次进度和性能指标

--range_selects=1  //启用范围选择查询

--db-ps-mode=disable   //禁用数据库预处理语句模式,即禁用基于预处理语句的查询

--rand-type=uniform //指定随机数生成器的类型为均匀分布,影响基准测试中生成的随机数据的分布方式

--threads=256  //指定并发执行的线程数为 256

--time=12000 //指定基准测试的持续时间为12000 秒

随着时间的推移,在同样的并发数下,tps逐渐上升,延迟逐渐下降,此时集群在对压力负载进行伸缩的“伸展“,当最终到达一个稳定值时,我们的数据库集群资源已经伸缩调整完成

回到管理界面查看Serverless监控,如图可以看到第一个上升为初始化数据时消耗的PCU计算额度。后面持续上升的即为现在压测的数据观测

调整监控的时间范围,点击【计算节点】,可以明显看到主节点PCU CPU使用率的不断提升,PCU数量从1分钟内从1 PCU弹升到最大上限32 PCU

当结束压测脚本时,主节点PCU CPU使用率会立马下降,直至默认的1 PCU维持集群的运行

3.主写从读测试

点击集群地址配置,将【主库是否接受读】调整为否。将主节点设置为只写,并保留一个只读节点。设定为集群内一主一从,主写从读的场景。

再次执行上一节并发读写混合压测的命令

sysbench /usr/share/sysbench/oltp_read_write.lua --mysql-host=$POLARDB_URL --mysql-port=3306 --mysql-user=test_user --mysql-password=Password123 --mysql-db=sbtest --tables=128 --table-size=1000000 --report-interval=1 --range_selects=1 --db-ps-mode=disable --rand-type=uniform --threads=256 --time=12000 run

观察Serverless监控信息,可以发现主节点和只读节点的CPU持续工作,但是此时主节点稳定使用8 PUC,只读节点稳定在10.5个PCU。主写从读的此时此刻,读的能力不会拉满主节点资源,并从监控的角度看此时消耗PUC总量较少,更加节省集群资源

4.读写混合压测

继续使用Sysbench工具验证只读节点的Serverless智能弹性能力。验证创建只读节点分摊主节点的读请求。当使用集群地址时,PolarDB for MySQL Serverless可以基于读负载的比例,智能地调整只读节点的个数和各自的规格,来达到最佳的Serverless能力。此时的弹性配置如图:

执行压测命令,使用oltp_read_write模块

POLARDB_URL=xxxxx.rwlb.rds.aliyuncs.com
sysbench /usr/share/sysbench/oltp_read_write.lua --mysql-host=$POLARDB_URL --mysql-port=3306 --mysql-user=test_user --mysql-password=Password123 --mysql-db=sbtest --tables=128 --table-size=1000000 --report-interval=1 --range_selects=1 --db-ps-mode=disable --rand-type=uniform --threads=256 --time=12000 run

参数上同不再赘述

同样压测的参数最终到达一个稳定值,说明PolarDB的处理能力借助Serverless弹性获得提升,趋于稳定


回到界面可以看到只读节点自动创建

观察Serverless监控场景此场景只读节点的创建和性能的提升

5.只读并发压测

当Polardb集群接收到新的只读负载后,首先当前的只读节点会弹升到最大规格32 PCU,之后Serverless系统会继续创建新的只读节点,实现横向扩展

执行压测命令,使用oltp_read_write模块

POLARDB_URL=xxxxx.rwlb.rds.aliyuncs.com
sysbench /usr/share/sysbench/oltp_read_only.lua --mysql-host=$POLARDB_URL  --mysql-port=3306 --mysql-user=test_user --mysql-password=Password123 --mysql-db=sbtest --tables=128 --table-size=1000000 --report-interval=1 --range_selects=1 --db-ps-mode=disable --rand-type=uniform --threads=256 --time=12000 run

参数上同不再赘述

测试开始,只读节点的PCU性能直接拉满

此时集群将自动创建第二个只读节点来分担压力

此时监控情况比较有意思,并没有真的按照文档说明的实现,我们这里仔细观察一下每个节点PCU的资源消耗

a. 压测初期,主节点被只读压力打满到32。黄色节点创建完成,和原有的只读节点逐步负载

b. 过2Min左右,主节点依旧拉满。两个只读节点都均衡负载

c. 压测持续18Min,新建的黄色只读节点和主节点都被拉满了,并存在一个点的震荡。并逐步释放主节点的资源压力,由两个只读节点负载压测

结束压测后,自动创建的只读节点会逐步释放,真的很弹~

整一个集群就是随着压力拓展和释放,自动的能力非常智能

三、TPC-C跑分测试(图一乐)

这个月听说友商的数据库市场份额跃居国内第一,还是之前去打榜TPC-C了。让我对这个老牌数据库榜单有很强烈的兴趣。那么我今天也图一乐,在PolarDB MySQL Serverless上去跑一下TPCC的分数,测试不精准、不严谨、不科学,咱主打一个玩哈

关于这个TPC-C是业界常用的一套Benchmark,由TPC委员会制定发布,用于评测数据库的联机交易处理(偏向OLTP)能力。TPC-C测试评估的性能指标包括每秒事务数(Transactions Per Second, TPS)和平均响应时间。TPS是指数据库系统每秒钟能够处理的事务数量。平均响应时间是指系统对单个事务请求的响应时间。这些指标可以帮助评估数据库系统在处理大量并发事务时的性能。TPC-C使用tpmC值(Transactions per Minute)来衡量系统最大有效吞吐量(MQTh,Max Qualified Throughput),其中Transactions以NewOrder Transaction为准,即最终衡量单位为每分钟处理的新订单数。

基础环境

压测机器使用一台16核64G内存的ECS云服务器,并且安装JDK环境、BenchmarkSQL软件

调整Serverless弹性配置,就默认开一主一读写,看看会触发多少横向和纵向的伸缩

创建测试使用的数据库tpcc,并确保测试账户有对应的权限

进入benchmarksql/run目录,创建props.polardb配置文件,填入连接信息

[root@iZuf6bn8133sc9jl32bqk8Z run]# vim props.polardb 
db=mysql
driver=com.mysql.cj.jdbc.Driver
conn=jdbc:mysql://xxxxx.rwlb.rds.aliyuncs.com:3306/tpcc?useSSL=false
user=test_user
password=Password123
warehouses=50
loadWorkers=10
terminals=256
runTxnsPerTerminal=0
runMins=5
limitTxnsPerMin=1000000000
terminalWarehouseFixed=true
newOrderWeight=45
paymentWeight=43
orderStatusWeight=4
deliveryWeight=4
stockLevelWeight=4
resultDirectory=tpcc_%tY-%tm-%td_%tH%tM%tS

conn:连接串配置,需填入主机名{HOST}、端口号{PORT}

user:用户名

password:密码

warehouses:仓库数

loadWorkers:导入数据并发数

terminals:压测并发数

runMins:压测时间

初始化压测数据

./runDatabaseBuild.sh props.polardb

开始压测,测试时间皆为5Min,并且每次测试完冷静一段时间让资源回收到初始

压测并发数50,tpmC值96732

17:53:06,014 [Thread-33] INFO   jTPCC : Term-00, 
17:53:06,014 [Thread-33] INFO   jTPCC : Term-00, 
17:53:06,015 [Thread-33] INFO   jTPCC : Term-00, Measured tpmC (NewOrders) = 96732.4
17:53:06,015 [Thread-33] INFO   jTPCC : Term-00, Measured tpmTOTAL = 215449.13
17:53:06,015 [Thread-33] INFO   jTPCC : Term-00, Session Start     = 2023-12-16 17:48:05
17:53:06,015 [Thread-33] INFO   jTPCC : Term-00, Session End       = 2023-12-16 17:53:06
17:53:06,015 [Thread-33] INFO   jTPCC : Term-00, Transaction Count = 107735

主页观察资源伸缩情况和弹性响应时长

压测并发数64,tpmC值113437

18:37:12,312 [Thread-60] INFO   jTPCC : Term-00, Measured tpmC (NewOrders) = 113437.13
18:37:12,312 [Thread-60] INFO   jTPCC : Term-00, Measured tpmTOTAL = 252091.54
18:37:12,312 [Thread-60] INFO   jTPCC : Term-00, Session Start     = 2023-12-16 18:32:12
18:37:12,312 [Thread-60] INFO   jTPCC : Term-00, Session End       = 2023-12-16 18:37:12
18:37:12,312 [Thread-60] INFO   jTPCC : Term-00, Transaction Count = 1260713

主页观察资源伸缩情况和弹性响应时长

压测并发数128,tpmC值150772

18:26:05,188 [Thread-106] INFO   jTPCC : Term-00, Measured tpmC (NewOrders) = 150772.4
18:26:05,188 [Thread-106] INFO   jTPCC : Term-00, Measured tpmTOTAL = 334973.82
18:26:05,188 [Thread-106] INFO   jTPCC : Term-00, Session Start     = 2023-12-16 18:21:05
18:26:05,188 [Thread-106] INFO   jTPCC : Term-00, Session End       = 2023-12-16 18:26:05
18:26:05,188 [Thread-106] INFO   jTPCC : Term-00, Transaction Count = 1675499

主页观察资源伸缩情况和弹性响应时长

压测并发数256,tpmC值147031

18:12:16,127 [Thread-45] INFO   jTPCC : Term-00, Measured tpmC (NewOrders) = 147031.89
18:12:16,127 [Thread-45] INFO   jTPCC : Term-00, Measured tpmTOTAL = 327070.27
18:12:16,127 [Thread-45] INFO   jTPCC : Term-00, Session Start     = 2023-12-16 18:07:16
18:12:16,127 [Thread-45] INFO   jTPCC : Term-00, Session End       = 2023-12-16 18:12:16
18:12:16,127 [Thread-45] INFO   jTPCC : Term-00, Transaction Count = 1635841

主页观察资源伸缩情况和弹性响应时长

这个256并发的分值降低我也一时半会找不到原因,免费使用的PCU资源有限,就不一次次的跑测试了hhhhh

最后

全员Serverless化的PolarDB MySQL真的是很智能化的一个云数据库产品,对严重依赖MySQL对于5/8版本的很友好。我自己折腾过开源版Polardb-X在自己的测试K8S集群上研究了半天,学习云原生数据库倒是ok,但是分布式集群的cn、dn、cdc节点数量还是要自己做调整,使用感受没法和线上Serverless版本相比。弹性测试的效果非常好,按照集群资源最大单台32核64G*8节点的集群情况来看处理一个大型项目的数据是足够的,并且还能在数据库请求量小的情况下进行回收释放,对中小型企业更友好。

最想吐槽的点就是平台的监控问题还是蛮大的,延迟明显而且在节点自动添加的时候最离谱,过了很长一段时间才被监控显示出来,我不知道是不是只有我个例;其次本来想测试手动切换业务连续性的,我没找到多节点高可用和多可用区主备手动切换的地方;最后对于共享存储这块,除了走冷数据的方式外是否能提供其他接口直接访问到数据库Data数据。

相关文章
|
1天前
|
存储 弹性计算 关系型数据库
活动实践 | 告别资源瓶颈,函数计算驱动多媒体文件处理测评
本方案介绍了一种高效处理文件的方法,适用于企业办公和社交媒体应用。通过阿里云的函数计算、对象存储OSS和轻量消息队列,实现文件的异步处理,如格式转换和水印添加,有效减轻了核心应用的负担,提高了业务稳定性和资源利用率。方案包括云服务器ECS、云数据库RDS、OSS存储等组件,支持快速部署和资源清理。
|
14天前
|
监控 关系型数据库 Serverless
扩缩容操作对 PolarDB Serverless 性能的影响
扩缩容操作对 PolarDB Serverless 性能的影响
22 3
|
17天前
|
关系型数据库 Serverless 分布式数据库
PolarDB Serverless 模式通过自动扩缩容技术,根据实际工作负载动态调整资源,提高系统灵活性与成本效益
PolarDB Serverless 模式通过自动扩缩容技术,根据实际工作负载动态调整资源,提高系统灵活性与成本效益。用户无需预配高固定资源,仅需为实际使用付费,有效应对流量突变,降低总体成本。示例代码展示了基本数据库操作,强调了合理规划、监控评估及结合其他云服务的重要性,助力企业数字化转型。
25 6
|
14天前
|
关系型数据库 Serverless 分布式数据库
扩缩容操作对PolarDB Serverless的性能有多大影响?
PolarDB Serverless 的扩缩容操作对性能会产生一定的影响,但通过合理的规划、监测和措施,可以将这种影响控制在较小的范围内。同时,随着技术的不断进步和优化,扩缩容操作对性能的影响也会逐渐减小,为用户提供更稳定、高效的数据库服务体验。
|
14天前
|
关系型数据库 Serverless 分布式数据库
PolarDB Serverless 的自动扩缩容机制
PolarDB Serverless 作为一种创新的数据库服务模式,其自动扩缩容功能是其重要的特性之一。这一功能为用户带来了诸多优势,同时也有着复杂而精密的运作机制。
|
1月前
|
运维 Serverless 数据处理
Serverless架构通过提供更快的研发交付速度、降低成本、简化运维、优化资源利用、提供自动扩展能力、支持实时数据处理和快速原型开发等优势,为图像处理等计算密集型应用提供了一个高效、灵活且成本效益高的解决方案。
Serverless架构通过提供更快的研发交付速度、降低成本、简化运维、优化资源利用、提供自动扩展能力、支持实时数据处理和快速原型开发等优势,为图像处理等计算密集型应用提供了一个高效、灵活且成本效益高的解决方案。
81 1
|
2月前
|
运维 监控 Serverless
利用Serverless架构优化成本和可伸缩性
【10月更文挑战第13天】Serverless架构让开发者无需管理服务器即可构建和运行应用,实现成本优化与自动扩展。本文介绍其工作原理、核心优势及实施步骤,探讨在Web应用后端、数据处理等领域的应用,并分享实战技巧。
|
2月前
|
运维 Serverless 数据处理
Serverless架构通过提供更快的研发交付速度、降低成本、简化运维、优化资源利用、提供自动扩展能力、支持实时数据处理和快速原型开发等优势,为图像处理等计算密集型应用提供了一个高效、灵活且成本效益高的解决方案。
Serverless架构通过提供更快的研发交付速度、降低成本、简化运维、优化资源利用、提供自动扩展能力、支持实时数据处理和快速原型开发等优势,为图像处理等计算密集型应用提供了一个高效、灵活且成本效益高的解决方案。
62 3
|
2月前
|
测试技术 持续交付 Apache
Python性能测试新风尚:JMeter遇上Locust,性能分析不再难🧐
【10月更文挑战第1天】Python性能测试新风尚:JMeter遇上Locust,性能分析不再难🧐
154 3
|
3月前
|
测试技术 数据库 UED
Python 性能测试进阶之路:JMeter 与 Locust 的强强联合,解锁性能极限
【9月更文挑战第9天】在数字化时代,确保软件系统在高并发场景下的稳定性至关重要。Python 为此提供了丰富的性能测试工具,如 JMeter 和 Locust。JMeter 可模拟复杂请求场景,而 Locust 则能更灵活地模拟真实用户行为。结合两者优势,可全面评估系统性能并优化瓶颈。例如,在电商网站促销期间,通过 JMeter 模拟大量登录请求并用 Locust 模拟用户浏览和购物行为,可有效识别并解决性能问题,从而提升系统稳定性和用户体验。这种组合为性能测试开辟了新道路,助力应对复杂挑战。
119 2

相关产品

  • 云原生数据库 PolarDB