前言
在之前的测评中，我们学习过PolarDB MySQL版的基础使用、体验过PolarDB开源版PolarDB-X和PolarDB-PG的安装部署、感受过PolarDB PG版 和 MySQL版 Serverless集群下的极致弹性，而这次，我们将会针对PolarDB MySQL 的四大场景进行一次较为完整的全方位测评。
本次测评地址如下：https://developer.aliyun.com/topic/test/polardb/mysql
过往文章如下：
数据管理的艺术：PolarDB开源版详评与实战部署策略（一）
数据管理的艺术：PolarDB开源版详评与实战部署策略（二）
PolarDB Serverless能力测评：秒级弹升、无感伸缩与强一致性，助您实现高效云数据库管理！
高峰无忧，探索PolarDB PG版Serverless的弹性魅力
顺便一提的是，笔者最近深入学习了中国数据库的发展史，也是感触颇深。我们虽然知道现在中国数据库产业已经取得了巨大的进步，但回顾过去，回顾那段从无到有、从跟随到引领的过程，也能对PolarDB诞生的重大历史意义有更深刻的了解。
如果你也感兴趣，可以参看笔者的以下文章：攻坚克难岁月长，自主腾飞世界强——回顾近代中国数据库的发展与飞跃
PolarDB核心能力与性能免费观测
对照官方给出的场景，我们首先利用免费资源来进行体验，对PolarDB MySQL的核心能力与性能有个初步的了解。
进入上述评测地址，点击右侧【免费观测】。
PolarDB MySQL Serverless 性能表现
默认为【PolarDB MySQL】，点击【创建免费体验任务】。
压测 OLTP 场景默认使用为 oltp_read_write。
显示创建成功。
点击【体验记录】。
看到正在准备中，点击【查看详情】，等待约5—10分钟，待其压测完毕。
当状态为【已完成】，此时，我们可以看到压测状态如下：
在压测期间，该实例的TPS（每秒事务处理量）维持在较高水平，且CPU利用率较为平稳，未见明显高峰，这表明了该实例在处理大量事务时具有良好的性能和资源管理能力。
PolarDB MySQL（列存索引）IMCI
PolarDB列存索引适用于对在线数据有轻量型数据分析需求的场景，如实时报表；而 ETL数据加速计算场景是依托PolarDB基于列存索引提供的强大而灵活的计算能力，在PolarDB中使用SQL来实现ETL功能。
列式存储是一种将数据按列进行组织和存储的方式，它能够更好地支持对大量结构化数据的快速检索和分析操作。与传统的行式存储相比，列式存储具有以下优点：
更快的数据访问速度：由于列式存储只读取需要的信息，因此对于某些特定场景下的查询操作来说，其性能表现通常优于行式存储。
更低的空间占用率：由于列式存储只需要保存每个字段的一部分值，所以它可以节省大量的磁盘空间。
更好的压缩效果：由于不同列之间往往存在一定的相关性，因此使用列式存储可以更容易地实现高效的数据压缩技术。
点击【创建免费体验任务】。
点击确认。
进入体验记录中即可查看当前任务的执行情况：
点击查看详情，进入到实时查询情况界面，我们点击执行SQL。
再点击切换到IMCI去读EndPoint。
最终，我们可以看到对比图如下，在折线图中，绿色曲线表示IMCI（即列式存储）查询耗时，紫色曲线表示正常查询耗时：
可以清晰的看出，在开启IMCI功能后，同一复杂查询语句的执行时间明显缩短了，CPU占用率也明显减少了，这说明列式存储确确实实可以显著提高数据处理速度和效率，也意味着对于需要频繁进行数据分析或报表生成的应用场景来说，采用列式存储能够极大地提升性能。例如，在金融交易分析、电信行业的大数据分析、医疗健康数据统计等领域，这种技术的优势尤为突出。
PolarDB MySQL 弹性并行查询（ePQ）
PolarDB MySQL 弹性并行查询（ePQ）功能: 将一个查询任务拆分为多个子任务，子任务可以被派发到同集群内的任意节点来完成计算，从而有效利用集群内其他节点的空闲计算资源（CPU、内存等）来加速查询。具体优势如下：
实时性分析：统一的底层存储，数据实时可见
开箱即用：零附加成本和运维成本，随集群部署
性能优异：打通节点间的计算资源，突破单机硬件性能瓶颈，性能表现优异
提升能效：充分利用空闲计算资源，提升集群整体资源利用率
实时弹性：按需扩容，提供更灵活的弹性计算能力
按照同样的步骤创建体验任务，点击查看详情：
点击蓝色按钮按照步骤依次执行命令，最终，我们可以看到对比图如下：
从上图中我们可以看到，在开启了ePQ后，能有效利用集群内其他节点的空闲计算资源，从而加速任务的执行时间，这种方式不仅减轻了主节点的负担，还使得整个系统的资源利用率得到了显著提升。
ePQ通过智能地调度和分配计算任务到集群中的各个节点上，确保了数据处理的并行化，进而大幅度提升了查询响应速度。此外，这种优化方式还有助于平衡各节点之间的负载，避免了个别节点过载而影响整体系统性能的情况发生。对于那些需要处理大量数据和复杂查询的应用场景，如大数据分析、商业智能报表等，采用ePQ能够显著改善用户体验，使得数据分析更加高效、快速。
PolarDB MySQL 无感秒切高可用
PolarDB的无感秒切技术从故障探测、切换速度和切换体验三个方面对切换场景进行了优化，包括计划内的切换，如集群升降配和小版本升级，以及计划外的容灾切换。
故障探测：引入全新的高可用模块Voting Disk Service（简称VDS），该模块基于共享存储架构，实现自治的集群节点管理，大幅降低故障检测和集群选主耗时。
切换速度：新增支持全局预热系统的热备节点，通过对存储引擎内部的多个模块提前预热，优化升主的执行耗时。
切换体验：结合数据库代理（PolarProxy），支持连接保持和事务保持功能。在集群升降配或小版本升级过程中，开启连接保持和事务保持功能后，系统会尽可能地保证用户的连接和事务不中断，实现基本无感知的主动运维。
按照同样的步骤创建体验任务，点击查看详情：
开启切换测试：
从图中可以看出，“无感切换”的性能曲线相较于“普通切换”更为平稳，尤其是在触发切换操作时没有明显的性能下降现象。
在21:32时普通切换的TPS（每秒事务数）为0，这表示在此时刻发生了数据库实例的切换，在这个过程中，旧的数据库实例被关闭正在被新的数据库实例取代，因此无法处理任何新的事务请求。相比之下，无感切换的TPS曲线在相同的时间点仍然维持在一个较高的水平，这表明无感切换技术成功实现了在切换期间保持服务的连续性，没有造成明显的性能下降或服务中断。
这表明了无感秒切-PolarDB高可用的特点在于其能够在不影响应用服务的情况下完成数据库实例间的无缝切换，保证了业务连续性和稳定性。当出现故障或者其他需要切换的情况时，系统能够迅速自动地将流量导向备用实例，而不会导致应用程序延迟增加或者中断服务。这样的设计对于企业级应用至关重要，因为它能够最大程度地减少因维护或故障恢复而导致的服务中断时间，从而保护企业的声誉和客户满意度。
PolarDB MySQL Serverless极致弹性
这一部分其实在之前也体验过，这里就简单回顾一下，具体文章可以参看这一篇：PolarDB Serverless能力测评：秒级弹升、无感伸缩与强一致性，助您实现高效云数据库管理！。
设置Serverless弹性策略
复制下方地址，在Chromium网页浏览器打开新页签，粘贴并访问云数据库PolarDB控制台。
https://polardb.console.aliyun.com/
在集群列表页面，找到您的PolarDB实例，单击实例ID。
在基本信息页面的数据库节点区域中，单击右上角的Serverless配置。
设置Serverless参数如下:
主节点Serverless弹性压测
执行如下命令，初始化相关数据
sysbench /usr/share/sysbench/oltp_read_write.lua
--mysql-host=PolarDB实例的集群私网地址
--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
【注释】：
sysbench：sysbench是一个多线程的基准测试工具，用于评估系统性能。
/usr/share/sysbench/oltp_read_write.lua：这是sysbench提供的一个Lua脚本，用于执行OLTP（联机事务处理）类型的读写测试。
--mysql-host：指定PolarDB实例的集群私网地址，表示要连接的MySQL服务器的主机名或IP地址。
--mysql-port：指定MySQL服务器的端口号，通常为3306。
--mysql-user：指定连接MySQL服务器所使用的用户名。
--mysql-db：指定要在MySQL服务器上使用的数据库名称。
--tables：指定在测试期间创建的表的数量。
--table-size：指定每个表的行数。
--report-interval：指定报告输出的时间间隔（以秒为单位）。
--range_selects：指定是否进行范围查询操作。
--db-ps-mode：指定数据库预处理状态，此处为禁用。
--rand-type：指定生成随机数的方式，这里使用均匀分布。
--threads：指定并发线程数，即同时执行的任务数量。
--time：指定测试运行的总时间（以秒为单位）。
prepare：指定执行预备阶段，将在测试之前创建和填充表。
此时可以看到明显的增加。
由于初始化数据的负载也会造成Serverless弹升，在执行完毕后等待2-3min，在规格下降到初始状态（1PCU）后，再执行正式的压测命令。
执行如下命令，开始进行256并发读写混合压测。
sysbench /usr/share/sysbench/oltp_read_write.lua
--mysql-host=PolarDB集群私网地址
--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弹性获得提升。
PolarDB MySQL高可用场景无感秒切
此处实验提纲如下：
对比总览
热备只读节点（开启热备切换功能）与普通只读节点的性能差异总览如下：
通过以上数据可以看出：
主动运维时，开启热备的只读节点与未开启相比，业务中断时间更短，并且可以实现连接和事务不中断。
故障容灾时，开启热备的只读节点相比未开启的情况，业务中断时间更短，并且可以实现连接和事务不中断，业务客户端报错量显著降低。
开启与关闭热备功能的切换效率的详细数据如下：
普通只读节点（未开启热备和事务保持）：TPS跌零10秒以上。
热备只读节点（开启热备和事务保持）：TPS跌零5秒左右。
当发生主节点宕机时，普通只读节点（未开启热备和事务保持）：连接中断报错60秒左右。
当发生主节点宕机时，热备只读节点（开启热备和事务保持）：TPS跌零5秒左右，不会中断。
可以看到在触发故障容灾后，普通RO的TPS跌0，并且连接中断，报错长达一分钟。尽管期间流量不断尝试重新注入，但TPS始终为零;热备RO的TPS紧跌0.5秒随即恢复正常，没有报错，且连接也未中断。
在触发故障容灾且TPS恢复后，普通RO执行查询产生报错，热备RO可以正常执行查询并返回正确数据。在普通RO端重新执行查询，开始重连，重连后重新查询，从结果before test可知事务丢失。在热备RO端继续执行该事务，将其更新为transaction resume success并提交再次查询。从结果可知，事务执行成功，这说明热备RO上触发故障容灾后事务不中断。从本实验结果可知，在故障容灾fail over场景下，热备RO可以实现连接和事务不中断，且不出现中断报错。
PolarDB MySQL 数据备份场景
备份设置
PolarDB支持数据备份和Redo物理日志备份。数据备份即将某个时间点上集群的全量数据生成一个备份集（快照）；Redo物理日志备份即记录生成备份集后的增量数据。您可设置数据备份和Redo物理日志备份的备份策略，如备份方式，数据备份文件保存时长、存储位置，日志备份文件保存时长等。
若存储类型为标准版ESSD云盘，则数据的备份方式主要分为常规备份或高频备份。
常规备份（按备份周期）：自动备份默认每日1次，你可以设置数据自动备份的周期和自动备份开始时间。
高频备份：PolarDB支持增强保护功能，能够缩短备份周期，增加备份密度，从而提升恢复速度。
若集群的存储类型为企业版或标准版PSL4、PSL5，则数据备份按照存储位置可分为一级备份和二级备份，数据备份策略包括一级备份策略和二级备份策略。
高级备份设置
在集群的备份恢复界面切换高级备份设置后，即可使用稀疏备份功能。可以按照每周、每月、每年的方式来设置备份集保留周期，实现间隔很长时间保留一个备份集，尽可能降低RTO（Recovery Time Objective），减少历史备份集数量的目的。同时，在符合等保要求的前提下达到尽可能降低成本的目标。
例如希望最近20年每年保留一个备份集，如果直接将标准存储池的保留时间设置为7300天，备份频率为一周两次，那么一年会有52×2=104个备份集，存储成本非常高，这时候如果使用稀疏备份的策略设置每年仅保留一个备份集，将大幅降低存储成本。
在左侧导航栏中，选择配置与管理 > 备份恢复，切换高级备份设置，进入支持稀疏备份功能的备份策略设置界面。
全量恢复方式
全量恢复是指将PolarDB全量历史数据恢复至一个新的集群，验证新集群数据后，可以再将恢复后的数据迁移至原集群。全量恢复支持从备份集恢复和恢复到过去时间点两种恢复方式。
从备份集恢复
在左侧导航栏中，选择配置与管理 > 备份恢复，恢复数据到新集群。
在克隆实例页面，选择新集群的商品类型，设置对应参数即可。
恢复到过去时间点
在左侧导航栏中，选择配置与管理 > 备份恢复，按时间点恢复。
在克隆实例页面，选择新集群的商品类型，设置对应参数即可。
库表恢复方式
库表恢复是指仅恢复指定的部分库或部分表到原集群。例如游戏业务中有时仅需恢复某个或某些玩家的数据，此时可使用库表恢复方式。库表恢复支持从备份集恢复和恢复到过去时间点两种备份方式。
使用库表恢复对版本有着一定的要求，需查阅官方文档后确保无误再进行操作。
当前库表恢复方式中的从备份集恢复，只支持从一级备份的备份集里恢复，不支持从二级备份恢复。
库表恢复只会恢复指定的表，操作时请确认已选中所有需要恢复的表。
执行库表恢复操作时，若指定的库名或表名在原集群中已存在，则库表恢复会失败。
若选择非整库恢复，该库每次最多支持恢复100张表。若选择恢复库，则支持恢复的表数量为该库下所有的表。
集群内的表（包括系统表）超过50000张时也可以使用库表恢复功能。
库表恢复功能不支持恢复触发器（Trigger），若原表设置了Trigger，该Trigger不会被恢复。
库表恢复功能不支持恢复外键（Foreign Key），若原表设置了Foreign Key，该Foreign Key不会被恢复。
从备份集恢复
在左侧导航栏中，选择配置与管理 > 备份恢复，在备份恢复页面，单击库（表）恢复，在弹出的对话框中，选择恢复方式为按备份集，并在备份集列表中选择目标备份集。
在需要恢复的库和表区域左侧，选中需要恢复的目标库，并在右侧选中目标表，单击确定即可。
恢复到过去时间点
在左侧导航栏中，选择配置与管理 > 备份恢复，在备份恢复页面，单击库（表）恢复，在弹出的对话框中，选择恢复方式为按时间点，并选择需要恢复至的时间点。
在需要恢复的库和表区域左侧，选中需要恢复的目标库，并在右侧选中目标表，单击确定即可。
PolarDB MySQL HTAP场景
PolarDB MySQL支持内存列索引功能（In-Memory Column Index 简称 IMCI)。IMCI 可以将复杂分析查询的速度提升几个数量级， 同时继续保持高性能的实时事务处理能力。
IMCI的主要特性包括实时事务一致的行列混合存储， 支持多线程并行向量化执行的SQL算子，以及100%的MySQL协议兼容。在PolarDB一写多读的架构的基础上，通过创建只读分析类型节点, 规避传统架构所需要的复杂ETL过程。用户可以在一套PolarDB集群中，轻松获得实时数据分析和实时事务处理能力。IMCI使得PolarDB成为一款真正的HTAP数据库。
在基本信息页面的数据库代理企业通用版区域，单击集群地址名称右侧的编辑配置。
在编辑地址配置面板中，设置读写模式为可读可写（自动读写分离），服务节点选择主节点、只读节点和只读列存节点，选择行存/列存自动引流为开启，然后单击确定。
执行如下命令，连接到PolarDB集群。
/usr/bin/mysql --host <连接地址> --port <端口> -u<用户名> -p<密码>
执行如下命令，使用测试数据库tpch1g。
use tpch1g;
单表聚合查询测试。
执行如下查询SQL语句。
select
sum(l_extendedprice * l_discount) as revenue
from
lineitem
where
l_shipdate >= date '1994-01-01'
and l_shipdate < date '1994-01-01' + interval '1' year
and l_discount between .06 - 0.01 and .06 + 0.01
and l_quantity < 24;
返回结果如下，可以看到，该查询SQL语句的查询时间为0.64秒。
执行如下SQL语句，查询上一步SQL语句的执行计划。
explain select sum(l_extendedprice * l_discount) as revenue from lineitem where l_shipdate >= date '1994-01-01' and l_shipdate < date '1994-01-01' + interval '1' year and l_discount between .06 - 0.01 and .06 + 0.01 and l_quantity < 24;
返回结果如下，可以从“IMCI Execution Plan”字样可知，该查询SQL语句使用了列存索引加速。
执行如下SQL语句，关闭列存索引加速，即使用行存索引。
set use_imci_engine = off;
重新执行以上查询，并查询对应的执行计划，可发现，关闭列存索引加速后，该查询使用了原生MySQL的索引进行查询，即行存索引，且行存索引下的查询时间为22.55秒。
select
sum(l_extendedprice * l_discount) as revenue
from
lineitem
where
l_shipdate >= date '1994-01-01'
and l_shipdate < date '1994-01-01' + interval '1' year
and l_discount between .06 - 0.01 and .06 + 0.01
and l_quantity < 24;
explain select sum(l_extendedprice * l_discount) as revenue from lineitem where l_shipdate >= date '1994-01-01' and l_shipdate < date '1994-01-01' + interval '1' year and l_discount between .06 - 0.01 and .06 + 0.01 and l_quantity < 24;
返回结果如下，您可以看到，该查询SQL语句的查询时间为22.55秒。
由此可见，列存索引功能对复杂的SQL查询操作有明显的加速作用，查询性能甚至可以提升百倍。
写在结尾的话
说实在的，PolarDB作为一个极为成熟的产品，经过这么多年的不断发展和完善，已经成为众多企业和开发者信赖的不二选择。它不仅仅提供了一流的数据库服务，还在上述多个方面展现出了独特的优势。
不过，这里还有一点想额外想单拎出来说，就是数据安全相关方面的问题。
最近小道消息称某友商泄露了14亿条数据的传闻也是闹得沸沸扬扬，这也再次提醒我们数据安全的重要性。
即便现在来看，PolarDB的安全性确实还算是不错，但放在未来，随着技术的发展和新的安全威胁的出现，持续改进和增强安全措施仍然是至关重要的。
