自AWS在2009年发布第一个数据库服务RDS MySQL以来,其数据库架构已经发展了13年,这个过程中一直都保持着快速的更新,到现在为止,云数据库架构已经有了一定的复杂度。该架构图系列系统通过适当的简化,帮助开发者能够快速的了解,如何选择适合自己的业务场景的RDS架构与规格。如下:
该架构图包含了高可用架构、CPU架构选择、存储类型选择等内容。该架构图不包括性能、精确的对应关系(如SQL Server支持的存储空间大小与MySQL有什么差别)等内容,暂时不包括Aurora架构(后续考虑补充)、Custom、Outpost类型等。
AWS RDS的高可用架构包括了单可用区(Single-AZ / Single DB instance)、多可用区(Multi-AZ DB instance)这两种常见类型,RDS MySQL/PostgreSQL还提供了多可用区集群版(Multi-AZ DB Cluster)。
该选项清晰的描述了实例的在可用区级别的容灾能力:
这是Amazon RDS在去年发布新的架构形态,详细参考:AWS RDS发布三节点形态,哪些业务场景应该选择?。该形态主要解决原来的“多可用区版本”备节点完全不可用(相对成本较高)的问题。
“多可用区集群版”使用了数据库的类似的半同步复制机制(参考系统参数判断出来的),数据库的事务写入需要至少两个(多数派)写入成功才成功,但因为有两个备节点,所以相比“多可用区版本”性能会更好,另外,因为是数据库层的复制,而不是块级别,写入和同步路径会更短,也会让延迟更低一些。
该版本,似乎是当前Amaozn RDS主推的版本(从RDS创建流程中的默认选项和选项顺序来看)。
关于该版本的架构、优缺点等相关信息可以参考该文章获得更多详细内容:AWS RDS发布三节点形态,哪些业务场景应该选择?
主流的云厂商都逐步开始提供X86和ARM架构的CPU,AWS在这方面是在这方面动作最早的。在2018年re:Invent上推出了第一代的Graviton,2019年推出了Graviton 2,2021年推出了Graviton 3(参考)。可以认为,当前产品已经有一定的成熟度,根据Percona做的MySQL测试,我们也看到,Graviton在不同的并发类型,都表现出了与Intel X86差不多的性能,并且在高并发(并发数超过CPU核心数量)时,Graviton表现还要更好一些。
性能比较接近,成本又更低,所以,目前已经有不少客户在尝试通过Graviton实例降低成本。目前,AWS RDS也有非常多的Graviton的规格供选择。
当前的建议是:可以考虑在部分业务中尝试使用Graviton降低成本,根据企业内部的负载情况,再逐步考虑扩大范围使用。
另外,值得一体的是,AWS RDS提供的最大规格是db.x2iedn.32xlarge,具备128vCPU 4096GB,一般来说,企业内部绝绝大多数业务都是满足需要的。
接着来看看AWS RDS提供了哪些存储类型。
AWS RDS当前主流的存储类型包括了gp2、gp3、io1(预留IOPS的SSD),以及一个已经过时的HDD存储。其中:
在实际的选择中,开发测试环境则可以使用gp2类型、一般业务使用gp3类型,对于核心业务则可以使用io1类型。
关于规格代码,国内的云厂商一般不是太强调,也不是太关注。但是AWS因为其规格代码非常规范,也非常简洁,所传达的含义也比较准确,所以很多时候,在提及规格时,大家会使用其规格代码,而不是使用vcpu数量和内存大小。
例如,db.m6gd.16xlarge,则可以知道这是一个数据库实例,64vCPU,256GB内存,并且为Graviton架构的第六代(Graviton 2)实例,并且在本地具备额外的NVMe SSD。
可用区可以理解为一片机房区域。例如,在东京东部的某个机房区域,通常会有数栋机房。一个大区域(Region,例如东京)会有多个可用区。