【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数据。