PolarDB 杀疯了，Everywhere Everytime Everydatabase on Serverless

PolarDB for MySQL SeverLess 有了新功能，什么新功能，定时serverless配置生效的功能。

这个功能本身有什么意义，从使用Serverless 的用户角度来说，意义非常大，正如题目上讲的，PolarDB ServerLess Everywhere ,Everytime, Everyone in time!

总体来说，这就是将ServerLess 的功能在PolarDB 上全面开花，数据库可以在你指定的时间，直接允许弹升（不是真的弹，是数据库可以弹），在你不想数据库弹升的时间去掉弹升的资源。一句话，如你所愿，想弹就弹，多维度多时间点的跟随业务的起伏波动来让数据库的硬件和业务一起波动起伏，且动态计算成本。

我们来说以下几个场景：

1 每到月底，财务集中做账，上传，查询报表的工作，这在每个单位都是一样的，这是一种行业行为，而平时在过了月底，月初这段时间后，财务就没有这样的工作，而如果是提供记账服务的Saas 公司，就需要在月底，月初为这些集中的计算付出更多的计算的能力的支持。

2 定期客户进行报表的查询，比如银行中的大客户定期对自己在银行的资产进行查询，计算，这样的公司也是在月底或月初多一些，或者突发的一些政策或事件发生后，会对金融体系的系统产生性能需求和风险。

3 学校的成绩查询系统，这个就更特殊，就在每年的特殊月份的几天内查询量巨大，基本很多的情况下，如高考结束查分，总有一小段时间什么都查不出来。

4 一些大型跨国公司，月底进行各个分支公司的数据上报，数据的写入量巨大

5 民生行业，如交通行业，在节假日，上班，下班高峰，餐饮行业，在节假日，特殊节日，等等这些时间需要大量的计算资源支持业务，而在其他时间如淡季，则服务器的资源空耗，很多情况都是，忙时吃不饱，闲时太浪费。

那么对于这类企业这是一个定期的工作，尤其国内大量的Saas企业，且可以预估。月底，月初进行数据库服务器的PCU 提升，进行只读节点的定期添加。

这里我们需要普及一个知识，跨机弹升和本地机弹升，跨机弹升是需要一定时间的，也是云原生数据库和RDS数据库在同样具有serverless的功能中，最大的不同，这也是为什么云原生的数据库产品比RDS在弹性上要先进的地方。

但这里跨机弹升是需要更多的时间，比本地弹升要复杂，在这样的情况下，如果我们能在这些事情发生之前，就进行CPU内存等部分的提升，在这些任务预估不在大量运行的情况下，将系统的CPU 调低下调，降低费用。

在之前PolarDB是没有这个功能的，就在上个月Serverless提供了这个功能，可以进行预期的系统的弹升的设置。

这里我们假设一个复杂的场景，一个月每个工作日，每天9：30AM就弹升5个PCU ，每天10:30PM 就将弹升的PCU 下降到1个

这个例子比较具有代表性，在工作日对系统的PCU 进行提升，在下班后就降低PCU ，很多企业都有类似的需求。

另外我们在举一个例子，比如10月1日到10月7日，我们要加一个只读的弹性节点。在10月8日这个节点下线。这里我们需要配置两个策略，1 自动添加弹性节点，这里我们在9月29日22:00，对所在的PolarDB进行弹性节点的添加。

然后我们在10月8日的 22：30 下线这个只读的弹性节点。（图中有误不是11月是10月）

通过这样的操作来在国庆节系统高峰，弹起只读节点，在国庆节高峰过去后，将只读节点弹下。

这样的案例特别适合，国庆节一些景点和游乐场所,热门的餐厅,票务，以及10月1后的 股票市场，Everywhere Everytime Everydatabase on Serverless

总结：在我们之前对于数据库的弹性，大部分认为我们需要的是敏态的弹性，这样的弹性在我们需要的时候，自动进行系统的弹升，在不需要的时候进行系统的弹下，而阿里云POLARDB Serverless的定时系统弹升的功能，让我们有了新的一些应用场景中得满足，尤其在我们有预料的情况下，将弹升做到前面，同时在不需要的时候，将系统的的性能或节点弹下，满足成本上的降低的需求，这样方便了客户在使用SERVERLESS 上的灵活性，和成本的需求。