PolarDB 数据库架构测试 serverless 后的三字真言稳定，灵活，省钱（的用对地方）...-CSDN博客

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

开头还是介绍一下群，如果感兴趣PolarDB ,MongoDB ,MySQL ,PostgreSQL ,Redis, Oceanbase, Sql Server等有问题，有需求都可以加群群内有各大数据库行业大咖，可以解决你的问题。加群请联系 liuaustin3 ，（共2340人左右 1 + 2 + 3 + 4 +5 + 6）5群超过430 已经停止自由申请，新人将进入6群

作为一个数据库架构师，我没有办法，必须断尝试新的东西，并在新的东西里面寻找自己存在的价值，职责是在业务中寻找痛点，并在当前可以使用的技术中，或新的技术中寻找解决的方案，解决难题才是我目前要做的工作，否则就离失业不远了。

Serverless 写了有几篇了，相关的压测，方案，论述，以及和阿里云的沟通对产品的一些部分的改进，已经到了尾声，可我还想写一篇不那么搞笑的风格的纯技术类的对于serverless 如何用，怎么用，哪里用的技术贴。写到这里，得出一个结论，我们的某个项目的确要上serverless了，这一切以我们的压测结果说话。

不知道之前笔者对serverless做了什么的可以看这几篇

1 临时工访谈：PolarDB Serverless 发现“大”问题了之灭妖记续集

2 PolarDB Serverless POC测试中有没有坑与发现的疑问

3 数据库 SERVERLESS 与 RDS 产品逐步淘汰和云数据库的价值

作为对这个部分的一个小结。

第一个问题 serverless 是一个好的技术吗，对于数据库来说？

我的回答是，YES，是的，他是一个好的技术对于数据库来说，或者更大的实话是，对于业务来说是的，他是一个好的技术。这项技术要解决的问题就是成本和性能之间的配比的关系。

比如在我们压测的过程中，PolarDB serverless 提供了比较有意思的功能，对于一些测试的场景是十分适合降低成本的，比如在PolarDB serverless 提供一个停止数据库运行的功能，在云上的使用数据库的小伙伴可能会知晓，云上的RDS 或云原生产品，只能释放，没有数据库关机的这个设定。哪怕你用ECS 去搭建主机，这也是贵的不合算，在这样的设定下，我们云上的费用是一个很难进行控制的部分，尤其是那些测试机，有部分时间他是没有去测试和进行工作的，但我们照样要进行付费。

那么PolarDB 的serverless产品，目前我们进行测试的可以在5分钟之内，在没有任何的延迟可以将你的数据库暂停，而更让我们之前没有的经验是，如果有任意的数据库访问就可以将这个数据库在5秒内唤醒。（暂停期间是不收费的，只收取存储的费用）

这里我不说假话，因为我是实实际际测试了，并且还不是一次，我对这个功能的评价是，很多线下的测试机的确可以上云了，没有必要在下面浪费电费空调费和占一个机房了，成本马上下来了。

这就是我对POLARDB 的第一个字的真言， 省，省成本。

在测试的过程中，我们也对于稳定性有了一些担心，因为我们惧怕在sererless 产品在使用中，会突发因为系统资源被占用100% 的情况下，系统OOM 切换或拒绝服务。

但在我们10万行事务提交，100万行事务提交，长达2个小时的蹂躏下，我们一次都没有遇到全serverless 或固定模式中+ serverless 的系统的罢工或出现任何延迟服务，或者让人担心的切换等问题，在这样的情况下，我们还对于polardb serverless 系统进行了大面积的高并发，DML 操作的压力测试，在系统长达6个小时不间断的100% 疯狂压测的情况下，没有任何的不稳定的状态，因为我们作为为甲方公司服务的人员，是希望能压出问题，如果现在压不出问题，只能说明两点， 1 我们的能力差没有能力压塌一个数据库？2 数据库产品的确是有两把刷子

最后我们各种招数也都用了的情况下，最终在之前一些数据库被压塌的方法下，POALRDB serverless 没有被我们压塌，这点我也只能给出一个字的真言稳 。

最后我们在和阿里云的产品经理和一些技术老师在一些阈值灵活性问题上有一些小的建议也被采纳了，最近就会发版。灵活性方面也是我们发现在使用serverless 上一些对我们业务有利的部分，比如在一些业务高峰时，我们可以通过固定配置+serverless 的方式进行一些我们不愿意长期付出成本，但又要抵御业务高峰，需要数据库提供突发提高性能的场景，或者快速在一分钟之内，扩充一个只读节点的需求，在使用完毕最快的情况30秒去掉这个只读节点的成本需求。

在我们反反复复对于系统进行纵向弹升的触发，和横向快速节点的扩展的情况下，40-50次的恶意的打开关闭serverless 的操作，PolarDB 的灵活性被证明，的确是可以进行组合来为业务节省成本，通过serverless来延迟数据库瓶颈到达，或者无意间的对突发业务性能上的支持，我们都可以从serverless 中进行组合和找到相应的解决方案。根据业务去思索不同的数据库组合的方案，去找到不同组合后，成本降低和性能提升或者应付一些糟糕的业务设计或系统对数据库要求。

所以最后一个真言是 灵，灵动的灵。

总结一下PolarDB 用户在serverless 部分可以在使用中给企业带来亮点的部分

1 测试库，注意不是压测库，是测试库，测试库可以完全使用SERVERLESS 的产品，通过SERVERLESS 可以为企业在测试环境不使用的情况下，节省大量的成本，狠狠地薅阿里云的羊毛，原因见上

2 生产环境：突发业务经常性的数据库，波峰波谷差异较大的业务可以使用固定配置+serverless 的方案来应对业务稳定性和突发业务对数据库性能的需求，并从成本上找一个平衡点。

3 PolarDB for MySQL 的强一致的从库需求，这点也可以在polarDB serverless 中找到解决方案，与固定的PolarDB不同，默认SERVERLESS 的产品就直接是强一致的，这样的情况下，主从就强行一致了，可以解决一些在POALRDB 上一些特殊业务的强一致需求，虽然固定的模式也可以配置，但SERVERLESS 是可以直接进行默认应用主从节点强一致的。

结尾，熟悉我的人都知道，我不是某个数据库的忠实FANS，因为职业的需求，就需要我做一个数据库方面的持续发现新东西的people，或许后面还会发现新的有趣的技术，来有利于推动业务的持续稳定可靠的发展，仅PolarDB serverless 对于PolarDB 来说是一个好功能，如虎添翼，让台风变成飓风的一个特色功能，如果你能用好他的话。

当然我也有我的担心，咱们另起一篇来说我惧怕serverless什么，这么多年积累的做人做事的经验，如果你是一个愿意人云亦云脑子长在别人头上的people ，你只能在别人的后面捡东西吃，follower ！如果对什么敢兴趣，自己亲历发现他，测试他，发现他的价值唯自己利用，你可能会得出一些不一样的结果，最终我们都希望体现自己的价值不是吗？

置顶文章：

MySQL 拜托加个索引能和PG一样简单吗？只能gh-ost了烦人

临时工访谈：问金融软件开发总监哪些业务不用传统数据库

PolarDB Serverless POC测试中有没有坑与发现的疑问

临时工访谈：PolarDB Serverless 发现“大”问题了之灭妖记续集

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

PolarDB for PostgreSQL 有意思吗？有意思呀

PolarDB Serverless POC测试中有没有坑与发现的疑问

往期热门文章：

MySQL 的SQL引擎很差吗？由一个同学提出问题引出的实验

临时工访谈：从国产数据库到普罗大众的产品！与在美国创业软件公司老板对话

PostgreSQL 如何通过工具来分析PG 内存泄露