评测｜PolarDB MySQL 版 Serverless

评测｜PolarDB MySQL 版 Serverless

目录

一、测试背景

1.1、云原生数据库 PolarDB Serverless新架构概念

1.2、Serverless资源弹性扩缩触发条件

二、PolarDB的Serverless能力与同类型产品进行对比

三、动态弹性升降资源的能力测试

3.1、测试资源

3.2、测试一、主节点Serverless弹性压测

3.2.1、设置Serverless弹性策略

3.2.2、主节点Serverless弹性压测

（1）、初始化相关数据

（2）、256并发读写混合压测

（３）、Serverless性能监控指标

3.2.3、测试结论

3.3、测试二、只读节点Serverless弹性压测

3.3.1、设置Serverless弹性策略

3.3.2、读写混合压测

（1）、初始化相关数据

（2）、读写混合压测

（３）、性能监控

3.3.3、测试结论

3.4、测试三、只读节点Serverless并发压测

3.4.1、设置Serverless弹性策略如测试3.3

3.4.2、只读并发压测

（一）自动扩容能力测试

（二）自动缩容能力测试

（三）性能监控

3.4.3、测试结论

3.5、测试四、全局一致性（SCC）测试

 3.5.1、设置Serverless弹性策略

 3.5.2、全局一致性（SCC）测试

 3.5.3、测试结论

四、异常反馈

4.1、数据库节点异常

4.2、只读节点异常

五、测试总结

一、测试背景

1.1、云原生数据库 PolarDB Serverless新架构概念

云原生数据库 PolarDB：

　　云原生数据库 PolarDB 是阿里云自研产品，在存储计算分离架构下，利用了软硬件结合的优势，为用户提供秒级弹性、高性能、海量存储、安全可靠的数据库服务。100%兼容MySQL和PostgreSQL生态，支持分布式扩展，高度兼容Oracle语法。产品具有多主多写、多活容灾、HTAP 等特性，交易性能最高可达开源数据库的6倍，分析性能最高可达开源数据库的400倍，TCO 低于自建数据库50%。

　　数据库是现代企业IT系统中非常重要的一部分。在创建数据库时，客户往往需要比较保守地去配置数据库集群的资源，包括CPU、内存、存储以及连接数等多种参数配置，以确保业务能够在波峰和波谷都能平稳运行。在这种情况下，客户购买的集群资源在业务波谷时期会被闲置，导致整体成本偏高；而在业务压力增长阶段，集群资源又应对不足。

　　第一代云原生数据库无法实现计算和内存资源解耦，导致目前云原生数据库价格依然高于RDS和自建数据库，这也是其无法占据大部分市场的核心原因。

　　随着PolarDB Serverless新架构的率先提出，原生数据库的困境出现极大改变。

PolarDB Serverless的最大创新之处在于：

　　▶ 在业内首次实现了内存与计算/存储的解耦，内存进一步池化，形成三层池化，使得弹性能力有数量级的提升。

　　▶ 内存池化大幅度降低了成本，实现了完全地按量使用和按需弹性，贴合各种场景。

Serverless集群的技术架构图

　　PolarDB Serverless构建了一个全新的数据库形态，即DCaaDB（Datacenter as a Database）。整个IDC形成一个多租户的大数据库，其全部的CPU、内存和存储构成三个独立的资源池。在资源池未耗尽的情况下，任何一个用户（租户）都可以任意的弹性扩展任何一种资源到任何一个规格，用户为其SQL动态消耗的CPU、内存和存储买单，不需要预置任何的规格。

　　这种情况下，CPU和内存资源因其池化其使用率将会大幅度提升，云原生数据的成本将会远低于自建和RDS等一体化数据库，云原生技术的价值将会得到充分的体现

　　Serverless数据库能够使得数据库集群资源随客户业务负载动态弹性扩缩，将客户从复杂的业务资源评估和运维工作中解放出来。

1.2、Serverless资源弹性扩缩触发条件

纵向扩缩：指节点的性能（CPU和内存的规格）发生变化。
横向扩缩：指只读节点的数量发生变化。

资源弹性扩展触发条件

纵向扩展触发条件:

　　PolarDB主要监控主节点和只读节点的CPU使用率、内存使用率和其他内核层面指标。

　　在监控周期内，出现如下三种情况中的任意一种时，通常会触发Serverless资源纵向扩展：

　　▶ 当单节点的CPU使用率高于80%，会触发本节点资源扩展。

　　▶ 当单节点的内存使用率高于90%，会触发本节点资源扩展。

　　▶ 当只读节点的规格小于主节点规格的一半时，会触发只读节点资源扩展。例如，当只读节点的规格是4 PCU，主节点的规格是10 PCU时，会触发只读节点资源扩展到不小于5 PCU的规格。

横向扩展触发条件:

　　当只读节点已经纵向扩展到设定上限，集群中现有的只读节点的CPU使用率或内存使用率仍然满足纵向扩展的条件（CPU使用率高于80%或内存使用率高于90%），则会触发只读节点的横向扩展。

资源弹性收缩触发条件：

　　当单节点的CPU使用率低于50%且内存使用率低于80%时，会触发本节点资源收缩。

说明：
　　以上条件适用于Serverless集群和普通集群的Serverless功能。
　　以上阈值指标是默认值，在不同集群内核参数以及不同Serverless配置策略下，会有所调整。

二、PolarDB的Serverless能力与同类型产品进行对比

　　在业务波动较大的场景下，普通集群和Serverless集群资源使用和规格变化情况如下图：

　　由上图可以看到，在业务波动较大的场景下：

普通集群：

　　在波谷期浪费的资源较多，在高峰期资源不足，业务受损。

Serverless集群：

　　由于其规格随业务需求量随时调整，总体浪费的资源很少，提升了资源利用率，降低了资源使用量。在高峰期也能完全满足业务需求，保证业务不受损，提高了系统的稳定性。打破固定资源付费模式，做到了负载与资源动态匹配的按量付费模式，可节省大量成本。无需手动变配，提高了运维效率，提升了运维管理人员和研发人员的幸福感。具备弹性扩缩能力，适合业务数据量大、并具有典型的业务访问波峰波谷场景。

三、动态弹性升降资源的能力测试

3.1、测试资源

3.1.1、场景资源信息⬇️

• 云服务器ECS

　　云服务器（Elastic Compute Service，简称ECS）是阿里云提供的性能卓越、稳定可靠、弹性扩展的IaaS（Infrastructure as a Service）级别云计算服务。一台云服务器ECS实例等同于一台虚拟服务器，内含CPU、内存、操作系统、网络配置、磁盘等基础的组件。

　　ECS实例ID：i-uf6c2imr50uapz33734j

　　CPU&内存：16核(vCPU)64 GiB
　　操作系统：Alibaba Cloud Linux 2.1903 LTS 64位
　　当前使用带宽：5Mbps （峰值）

• 云原生关系型数据库PolarDB

　　云原生关系型数据库PolarDB是阿里巴巴自主研发的下一代云原生关系型数据库，100%兼容MySQL、PostgreSQL、高度兼容Oracle语法。 计算能力最高可扩展至1000核以上，存储容量最高可达 100TB。

数据库1名称：mytest
数据库2名称：sct
数据库3名称：sbtest
数据库账号名称：test_user
数据库登录密码：Password123
PolarDB实例ID：pc-uf6x937e5n0fw6138、pc-uf68j17rqld9xwh9d
PolarDB集群私网地址：
pc-uf6x937e5n0fw6138.rwlb.rds.aliyuncs.com
pc-uf68j17rqld9xwh9d.rwlb.rds.aliyuncs.com

3.1.2、测试工具⬇️：

• Sysbench工具

　　Sysbench是一款开源的多线程性能测试工具，可以执行数据库只读、只写、读写混合等类型的性能测试。

• SCC（Strict Consistency Cluster）服务

　　严格一致性集群SCC（Strict Consistency Cluster）服务。SCC功能为PolarDB for MySQL Serverless提供了跨节点无损读扩展的能力。PolarTrans事务系统利用提交时间戳技术CTS和RDMA网络，在内核层面提供集群强一致性读SCC服务，在不损失性能的基础上，保证发往集群任意副本的读请求都可以获得强一致性的结果。

3.2、测试一、主节点Serverless弹性压测

3.2.1、设置Serverless弹性策略

• 单节点资源弹性上限为：32 PCU。
• 单节点资源弹性下限为：1 PCU。
• 只读节点个数扩展上限：0。
• 只读节点个数扩展下限：0。
• 是否开启无活动暂停：关闭。
• 定时执行：立即执行

3.2.2、主节点Serverless弹性压测

　　本测试模拟客户端对PolarDB发起写请求，验证主节点的Serverless智能弹性能力。通过Sysbench脚本访问集群地址进行压测，PolarDB主节点的规格能够根据负载进行自动伸缩与自动配置，达到Serverless的能力。

　　本样例使用读写混合的压测类型（oltp_read_write），并发数为32线程。

（1）、初始化相关数据

切换至Web Terminal。

执行如下命令，初始化相关数据。

sysbench /usr/share/sysbench/oltp_read_write.lua --mysql-host=pc-uf6x937e5n0fw6138.rwlb.rds.aliyuncs.com --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弹升，初始化执行完毕后等待2-3min，在规格下降到初始状态（1PCU）后，再执行下面的正式的压测命令。

（2）、256并发读写混合压测

　　执行如下命令，开始进行256并发读写混合压测。

sysbench /usr/share/sysbench/oltp_read_write.lua --mysql-host=pc-uf6x937e5n0fw6138.rwlb.rds.aliyuncs.com --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

输出结果：

　　根据Sysbench输出返回结果可以直接观察到，

　　随着时间的推移，在同样的并发数下，tps逐渐上升，延迟（lat）逐渐下降，最终到达一个稳定值，这说明PolarDB的处理能力借助Serverless弹性获得提升。

（３）、Serverless性能监控指标

　　在计算节点页签，查看主节点负载情况。

　　可以看到随着主节点PCU CPU使用率的不断提升，PCU数量从

　　状态（1）2023-11-23 19:17:17 PCU=1，

　　迅速上升至

　　状态（2）2023-11-23 19:17:53 PCU=32，

　　（本次测试用时为36秒）

　　不到1分钟内从1 PCU弹升到最大上限32 PCU。

　　压测持续一段时间后，切换至Web Terminal中执行Ctrl+C，停止压测脚本。

　　切换至性能监控，

　　可以观察到，当压测请求完全停止后，主节点PCU CPU使用率会立即下降，而PCU数量随后也会逐步自动缩小至1 PCU。

3.2.3、测试结论

　　通过Sysbench脚本访问集群地址，模拟客户端对PolarDB发起写请求，进行压测，PolarDB主节点的Serverless能够根据负载进行自动伸缩与自动配置，具有智能弹性能力。PolarDB的处理能力借助Serverless弹性获得提升。

　　资源弹升速度快，不到1分钟时间内（本次测试用时为36秒）从1 PCU弹升到最大上限32 PCU，1秒内完成弹升。

3.3、测试二、只读节点Serverless弹性压测

　　只读节点Serverless弹性压测

　　本测试模拟客户端对PolarDB发起读请求，验证只读节点的Serverless智能弹性能力。PolarDB for MySQL Serverless集群除了支持主节点自动弹性伸缩之外，还支持创建只读节点分摊主节点的读请求。当使用集群地址时，PolarDB for MySQL Serverless可以基于读负载的比例，智能地调整只读节点的个数和各自的规格，来达到最佳的Serverless能力。

　　PolarDB for MySQL Serverless集群主节点PCU扩容到弹升上限后，会自动创建新的只读节点并分摊部分主节点的读负载，最终使整个集群能够支撑更高的TPS请求量。

3.3.1、设置Serverless弹性策略

• 单节点资源弹性上限为：32 PCU。
• 单节点资源弹性下限为：1 PCU。
• 只读节点个数扩展上限：7。
• 只读节点个数扩展下限：0。
• 是否开启无活动暂停：关闭。
• 定时执行：立即执行

3.3.2、读写混合压测

（1）、初始化相关数据

　　切换至Web Terminal。

　　执行如下命令，初始化相关数据。

sysbench /usr/share/sysbench/oltp_read_write.lua --mysql-host=pc-uf68j17rqld9xwh9d.rwlb.rds.aliyuncs.com --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弹升，初始化执行完毕后等待2-3min，在规格下降到初始状态（1PCU）后，再执行下面的正式的压测命令。

（2）、读写混合压测

　　执行如下命令，开始进行读写混合压测。

　　切换至Web Terminal。

　　执行如下命令，通过访问PolarDB for MySQL Serverless集群私网地址发起256并发读写混合压测请求。

sysbench /usr/share/sysbench/oltp_read_write.lua --mysql-host=pc-uf68j17rqld9xwh9d.rwlb.rds.aliyuncs.com --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

　　从Sysbench输出可以直接观察到，随着时间的推移，在同样的并发数下，tps逐渐上升，延迟（lat）逐渐下降，最终到达一个稳定值。这说明PolarDB的处理能力借助Serverless弹性获得提升。

（３）、性能监控

　　在监控页上，可以查看到集群维度的Serverless监控指标，选择压测的时间段可以看到类似如下信息：

　　从监控可以看出，PolarDB收到读写混合请求后，主节点会首先迅速弹升到最大的32 PCU，之后监控逐步出现两个只读节点。当只读节点分摊主节点的读请求后，主节点CPU使用率逐步下降，规格最终稳定在24PCU。

　　第一个只读节点创建后，也会立刻弹升到32 PCU。此时系统会尝试继续创建只读节点，分摊读请求。第一个只读节点稳定在30PCU。第二个只读节点稳定在29PCU。

　　我们可以看到，由于目前第二个只读节点没有到最大规格32 PCU，系统判断目前Serverless规格已经满足实际负载，不会再继续增加新的只读节点。

3.3.3、测试结论

　　初始状态下，在读写混合场景下，读写流量会首先转发到集群唯一节点，即主节点（RW）中。

　　当主节点弹升到最大规格后，Serverless系统会逐个创建只读节点，分摊主节点的读请求，直到只读节点的数量满足当前负载。

　　当只读节点分摊读请求后，主节点负载会降低，触发PCU弹降，为未来支持更多写负载预留了弹升空间。

3.4、测试三、只读节点Serverless并发压测

3.4.1、设置Serverless弹性策略如测试3.3

3.4.2、只读并发压测

（一）自动扩容能力测试

　　切换至Web Terminal。

　　打开一个新的Terminal（第一个测试3.3Terminal中的压测命令先不要停止）。

　　在新的Terminal中执行如下命令，通过访问PolarDB for MySQL Serverless 集群地址发起256并发的只读请求。

sysbench /usr/share/sysbench/oltp_read_write.lua --mysql-host=pc-uf68j17rqld9xwh9d.rwlb.rds.aliyuncs.com --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

　　当数据库接收到新的只读负载后，首先当前的2个只读节点会弹升到最大规格32 PCU，之后Serverless系统会继续创建新的只读节点，直到满足新增只读负载的要求。

选择性能监控。

　　在监控页上，可以查看集群维度的Serverless监控指标，选择只读请求的压测时间段，查看Serverless的状态：

（二）自动缩容能力测试

　　切换至Web Terminal。

　　执行Ctrl+C停止所有的Sysbench脚本（包括oltp_read_write和oltp_read_only）。

（三）性能监控

　　在监控页上可以看到PolarDB for MySQL Serverless的计算节点首先会自动缩容（预计耗时1-2min），之后新增的只读节点会逐步回收（预计耗时15-20min）。

　　等待较长时间后，最终PolarDB会缩容到只有一个主节点的状态。

　　说明：时间比较久，预计需要15-20min。趁着只读节点还没回收，可以直接做下一个全局一致性测试。

3.4.3、测试结论

　　从上面的实验可以看出，PolarDB for MySQL Serverless的节点数量和规格都能够根据负载进行自动伸缩与自动配置。

3.5、测试四、全局一致性（SCC）测试

　　全局一致性（SCC）测试

　　高性能全局一致性SCC特性可以为PolarDB for MySQL Serverless提供跨节点无损读扩展的能力，即RO的无损强一致读。传统的Serverless的方案均是基于单机原地升降配实现，其规格受限于单物理机资源。而当RO能借助SCC提供无损强一致读后，针对大部分读多写少业务，可以跨机提供CPU资源，上限远超单物理机限制。

　　开源的mysqlsct工具用于检验数据库集群的强一致性读能力, 该工具通过跨session的写入+读取+结果对比的方式来测试数据库集群强一致性读的功能和性能。

　　本测试使用mysqlsct工具验证的无损强一致读的特性。在Serverless默认开启SCC的状态下，PolarDB通过RO实现读扩展，且不会读到不一致的数据。在关闭SCC后，同样测试条件下，使用RO分摊读请求则无法满足强一致。

　　为了更方便地测试RO一致性读，先调整Serverless配置，确保测试过程中，至少保留一个只读节点。

 3.5.1、设置Serverless弹性策略

• 单节点资源弹性上限为：32 PCU。
• 单节点资源弹性下限为：1 PCU。
• 只读节点个数扩展上限：7。
• 只读节点个数扩展下限：1。
• 是否开启无活动暂停：关闭。
• 定时执行：立即执行

　　设置参数后，实例状态为配置切换中，切换预计需要1-2min，请等待实例状态变成运行中后再执行后面的操作。

 3.5.2、全局一致性（SCC）测试

　　切换至Web Terminal。

　　执行如下mysqlsct测试命令。

/root/mysqlsct --host-rw=pc-uf68z4el2op35ozy1.rwlb.rds.aliyuncs.com --host-ro=pc-uf68z4el2op35ozy1.rwlb.rds.aliyuncs.com --port-rw=3306 --port-ro=3306 --user=test_user  --password=Password123 --iterations=100000 --table-cnt=1 --table-size=1000 -f=0 --concurrency=1 --database=sct --sc-gap-us=0 --report-interval=2 --test-mode=sct

执行后，可以看到一致性检查全部通过，输出的信息类似如下截图：

　　选择参数配置。

　　单击页面左上角的修改参数按钮，修改loose_innodb_polar_scc参数为OFF，单击提交修改，单击确定，关闭SCC特性。

　　切换至Web Terminal。

　　重新执行mysqlsct测试命令。

/root/mysqlsct --host-rw=pc-uf68z4el2op35ozy1.rwlb.rds.aliyuncs.com --host-ro=pc-uf68z4el2op35ozy1.rwlb.rds.aliyuncs.com --port-rw=3306 --port-ro=3306 --user=test_user  --password=Password123 --iterations=100000 --table-cnt=1 --table-size=1000 -f=0 --concurrency=1 --database=sct --sc-gap-us=0 --report-interval=2 --test-mode=sct

　　执行后，可以看到一致性检查出现失败，输出的信息类似如下截图：

 3.5.3、测试结论

　　从上面的实验可以看出，PolarDB for MySQL Serverless借助高性能全局一致性SCC特性，提供了跨节点无损读扩展的能力。

四、异常反馈

4.1、数据库节点异常

　　正常情况下，当主节点升至32 PCU时，此时系统会尝试继续创建只读节点，分摊读请求。而只读节点到最大规格32 PCU时，系统判断目前Serverless规格超出实际负载，会继续增加新的只读节点。

　　但测试过程中，碰到过几次不断增加并发压测，但数据库节点不增加只读节点的情况。此时在性能监控显示页里也没有增加只读节点。等了很久时间也没有增加只读节点，数据显示也不正常。

4.2、只读节点异常

　　出现了只读节点PCU数量为0的异常情况。不断增加并发压测，但有一个只读节点PCU数量始终为0不变化。

五、测试总结

　　在PolarDB Serverless架构下，我对数据库性能进行了测试。 纵向扩缩：指节点的性能（CPU和内存的规格）发生变化。横向扩缩：指只读节点的数量发生变化。

1. 资源弹升速度：PolarDB可支持5秒探测窗口，1秒内完成弹升。资源弹升速度快，不到1分钟时间内（本次测试用时为36秒）从1 PCU弹升到最大上限32 PCU。

2. 资源伸缩广度：PolarDB支持自动纵向扩展（0~32核）和横向扩展（0~8个节点），支持0~256核范围内伸缩。

3. 资源伸缩的稳定性：PolarDB支持对业务无感的纵向扩缩容与横向扩展

4. 资源伸缩的颗粒度：PolarDB支持最小0.5PCU颗粒度的资源伸缩

5. 可支持自动启停：PolarDB可支持在没有访问需求时，计算资源可缩为0。当有访问需求时，10秒即可唤醒资源。

6. 全局数据的强一致性：PolarDB可支持所有只读节点的数据强一致性，并且性能不下降。

　　云原生数据库 PolarDB MySQL版Serverless能够根据业务负载，对集群资源进行秒级动态弹降，具有动态弹性升降资源的能力，通过多节点架构保障集群的高可用，自动弹升范围广，单集群支持无感伸缩，可实现秒级弹升，能够从容应对业务负载突增，全程对业务无影响。PolarDB MySQL版Serverless支持自动启停能力。当没有连接时，集群自动暂停，释放计算成本；当请求到来时，集群自动无感启动。

             推荐阅读：