PolarDB Serverless POC测试中有没有坑与发现的疑问-CSDN博客

本文链接：https://blog.csdn.net/liuhuayang/article/details/138941362

开头还是介绍一下群，如果感兴趣PolarDB ,MongoDB ,MySQL ,PostgreSQL ,Redis, Oceanbase, Sql Server等有问题，有需求都可以加群群内有各大数据库行业大咖，可以解决你的问题。加群请联系 liuaustin3 ，（共2300人左右 1 + 2 + 3 + 4 +5 + 6）新人奖直接分配到5群,开始建6群，另欢迎 OpenGauss 的技术人员加入。

新的项目要使用PolarDB Serverless ，之前一直嚷嚷 Serverless 会改变很多事情，到了要开始用的时候，其实我是犹豫的，但项目本身的诉求如此，就必须开始搞serverless of databases .

这里我们先从购买一个带有serverless的部分开始，但比较搞笑的是阿里云的客服不是太专业，我一个小白都知道，serverless 应该是可以在初始化的时候选择，或者在购买了固定产品后，在进行开启，但客服一开始告诉我只能初始化购买，后面不能开启，在我再三的对他的疑问后，并且我给他找出了阿里云某个技术人员的博客中提到的两种方法，才回去又找了一会，告诉我可以。

可见这个serverless 用的人不多，否则不会这样的一开始就让我觉得不专业。这里可以看到Serverless 在一开始购买的时候，是由优惠的，5折

在开始选择了serverless后，可以非常明显看到一些不同，服务的不同从页面上看明显是特殊对待了，提供了成本工具和免费体验。这里我们就是要开始用serverless 所以没有什么犹豫的。

下面的图中，我们选择企业版，标准版我不建议在实际的业务中使用，原因不能多说，要不那天又要组团来灭妖了。已经灭了我一次了详情见下面的连接。

临时工访谈：庙小妖风大-PolarDB 组团镇妖之他们是第一

下面这个位置是一个关键，这里有一个需要注意的地方只读节点个数下限，基于之前使用POLARDB 中的一些地方，一般是会有固定的必须不少于一个的只读节点的POLARDB 的存在的，但选择了serverless 后明显的和之前的页面不一样，可能在文档中提示，至少只读节点数伸缩下限是1 不是0的原因也是这个。至于只读节点的上限，最大是15，但我不认为有什么情况要15个只读节点在发生问题的时候，被制造出来，那也都是钱，这里我们选择2.

下面选择的时PCU ，具体PCU是一个什么东西，这里官方的解释是，一个PCU 等于1个CPU，也就是这里最低的是1个PCU 最高32 PCU，同时一个PCU 带有2G的内存。

坑：你当然可以选择PCU 为32，但你怎么知道你的业务是否会触发多少PCU，如果阿里云稍微的用一点手段，让你持续的运行在32PCU ，那么可以看一下一个小时就要 20块钱。所以这里选择PCU 还是悠着点，选择16PCU 或者 8PCU 就好。这里为了要测试，直接使用的32PCU 看看我们压测时候是不是能压测到峰值。数据库建立的速度比较快，对比普通的POLARDB FOR MYSQL 建立的速度至少快了一半。（这个需要长期的使用才能发现问题）

那么serverless 关键的地方就是弹性，到底怎么弹，指标是什么,在产生主机后，在下面截图的右侧有serverless配置

然后我们随之开始增加压力进行serverless 部分的压测，一开始压力不大的情况下，PCU 持续在1-2个左右，后续压力持续加大，PCU 逐渐增长，可以看到监控图中的部分，随着压力的增加PCU 也是阶段性的提高，并且增加的速度越来越慢，这也符合相关的原理。

这里一遍进行初步压测一边针对PolarDB 的触发规则进行学习

1 当单节点CPU 使用率高于80% 会触发提升PCU的工作
2 当单节点的内存使用率高于90% 会触发提升PCU的工作
3 当写节点的规格是只读节点200%的情况下，或者只读节点是写节点的规格的 50%以下时，会触发只读节点的升配工作。（非常不能容忍这样的设计，有硬伤）

这点我非常的不认可，第三点，如果我是一个纯写的任务，比如批量导入数据，然后读节点是不会有相关的业务压力的，然后就要提升只读节点的规格，非常不合适，非常不对，非常错误的一个设计。
哪怕你应该让用户来选择，同时在学习SERVERLESS的部分时，发现这个SEVERLESS 比较死，很多地方都是不可调的。

实际在业务使用数据库中，有一些特殊的需求

1 系统性能达到多大的触发点，这点明明可以让用户来选择，哪怕你给几个选择 60% 70% 80% 90% 95% 等，这里非常的死80% 不可调，为什么？

2 为什么只读节点的规格小于主节点一半就要进行节点的资源扩展？这个也可以调整，比如让用户来选择 40% 50% 60% 70% 80% ，由于主节点和从节点的资源差，发起从节点的升配工作。

3 定时升配的工作，这个属于让用户理解错误的选择想，用户要的是什么，我们要的是我们知道一些业务在某个时间短就是要作妖，然后我们定时在发生问题的之前我们就升配，升级PCU ，然后大约在多长时间后我们要求可以进行降配。

如果这三点可以进行配置，那么POALRDB 在SERVERLESS 方面的积木数据库的属性才能更切合实际，现在的状态POALRDB是积木数据库，而POLARDB SERVERLESS 是一个铸铁焊死的铁疙瘩。NO NO NO 用户不要这样。

当然目前仅仅是初级的压测，后面我们还将开展更多的方式的压测，不过就目前的状况来说，平稳升配的平稳，如果按照做车的理念，至少三大件目前没有太多的问题。同时在我们切断压测程序的情况下，PCU 马上就降下去，这里不夸张的，马上就降下去，按照POLARDB 的文档来说，是需要一点时间，但此次的压测中，没有延迟的情况。这里我记得今年年初参加POALRDB 数据库大会，负责这块的老师非常有信息，对于这块的稳定性和性能的部分，看来的确是做了实际的工作。