新的项目要使用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 数据库大会,负责这块的老师非常有信息,对于这块的稳定性和性能的部分,看来的确是做了实际的工作。
总结,本次的测试大体结果是没有让我们根本不想用serverless的,没有太多的硬伤,但设计上给用户的灵活度上,第一天就发现了一些用户觉得可以改善的地方,后续还会对这部分进行,疯狂的压测,寻找痛点,看看SERVERLESS 到底要不要 被拿上生产的餐桌。
本文分享自 AustinDatabases 微信公众号,前往查看
如有侵权,请联系 cloudcommunity@tencent.com 删除。
本文参与 腾讯云自媒体同步曝光计划 ,欢迎热爱写作的你一起参与!