NineData 联合创始人周复兴(苏普)受邀参加2023年 ACMUG 第一站西安站,发表了《云数据库架构与选型》主题讲演。

ACMUG,全称为我国MySQL用户组 (All China MySQL User Group) ,是 MySQL 和 MariaDB 在我国最大的技能社区,是得到了 Oracle User Group Community、MairaDB Foundation、我国核算机行业协会开源数据库专业委员会等官方认可的社区组织,ACMUG 会约请国内外顶尖互联网公司和大型企业技能专家,同享其在数据库、大数据、云原生、AIOps 等技能方向上的经历以及最新进展。

以下内容,依据周复兴在【2023年 ACMUG 第一站西安站 】线下讲演内容收拾而成。

AWS 在 2009 年发布第一款云数据库产品 RDS MySQL,阿里云于2011年 也发布了自己的 RDS MySQL,到现在,云数据库技能现现已过了 14 年的开展。云数据库的架构现已变得十分杂乱,上星期则借着 ACMUG(我国 MySQL 用户组)的同享则总结了 AWS 和阿里云 RDS 的首要架构特色,并经过一张架构图汇总,协助开发者依据需求在适宜的场景挑选适宜的架构与规范。

一、AWS:挑选适宜的 RDS 架构与规范

1.1 架构与规范大图

如何选择合适的云数据库架构与规格

该架构图包含了高可用架构、CPU 架构挑选、存储类型挑选等内容。该架构图不包含功能、准确的对应联系(如 SQL Server 支撑的存储空间巨细与 MySQL 有什么不同)等内容,暂时不包含 Aurora 架构(后续考虑弥补)、Custom、Outpost 类型等。

1.2 高可用架构

AWS RDS 的高可用架构包含了单可用区(Single-AZ / Single DB instance)、多可用区(Multi-AZ DB instance)这两种常见类型,RDS MySQL/PostgreSQL 还供给了多可用区集群版(Multi-AZ DB Cluster)。

1.2.1 单/多可用区

该选项清晰的描述了实例的在可用区等级的容灾才能:

  • 单可用区版别的数据库仅一个实例,没有高可用节点,假如节点失利,则会重启主机或许运用新的节点,整个过程会比较长。
  • 多可用区版别,则默许会运用两个节点,且必定散布在两个不同的可用区,实例能够完结跨可用区的容灾。当一个可用区呈现毛病的时分,实例会产生切换,容灾到另一个可用区。AWS 的多可用区版别,主备之间运用的是存储层(EBS)的物理仿制,所以因而其功能也会受到必定的约束。

1.2.2 多可用区集群版

这是 Amazon RDS 在去年发布新的架构形状,具体参阅:AWS RDS 发布三节点形状,哪些事务场景应该挑选?。该形状首要处理原来的“多可用区版别”备节点彻底不行用(相对本钱较高)的问题。

“多可用区集群版”运用了数据库的相似的半同步仿制机制(参阅体系参数判别出来的),数据库的事务写入需求至少两个(多数派)写入成功才成功,但由于有两个备节点,所以比较“多可用区版别”功能会更好,别的,由于是数据库层的仿制,而不是块等级,写入和同步路径会更短,也会让推迟更低一些。

该版别,似乎是当时 Amaozn RDS 主推的版别(从 RDS 创立流程中的默许选项和选项次序来看)。

如何选择合适的云数据库架构与规格

当时,多可用区集群版是规范模板中的第一个、也是默许选项。

关于该版别的架构、优缺陷等相关信息能够参阅该文章取得更多具体内容:AWS RDS 发布三节点形状,哪些事务场景应该挑选?

1.3 CPU 架构

干流的云厂商都逐渐开始供给 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,一般来说,企业内部绝绝大多数事务都是满意需求的。

1.4 存储层

接着来看看 AWS RDS 供给了哪些存储类型。

AWS RDS 当时干流的存储类型包含了 gp2、gp3、io1(预留 IOPS 的 SSD),以及一个现已过期的 HDD 存储。其间:

  • gp2 存储定位是适用于开发测验环境,存储巨细最大为64TB,最大 IOPS 为64000。在购买时,只能选定存储空间,其 IOPS 会依据存储空间进行换算,一般的会是存储空间的三倍,可是有一个下限、也有64000的上限。
  • gp3 定位是出产环境的 OLTP 运用,gp3 的最大存储空间和gp2相同,可是,gp3 存储能够独自购买 IOPS,即存储空间和 IOPS 是能够分隔购买的,这就给用户供给了更大的灵敏度。可是,需求留意的是 IOPS 购买的上限/下限也与存储有必定的联系。避免了,购买十分小的存储空间,可是购买十分大的 IOPS 的状况。具体的约束能够参阅其文档介绍。所以,gp3 类型的实例,其计费也是依照存储空间和 IOPS 分隔计费的。
  • gp2、gp3 存储所供给的 SLA 都是99%的恳求在毫秒等级。
  • io1(预留 IOPS 的 SSD)则供给了更高功能的存储,最大存储空间仍旧是64TB,可是其 IOPS 则能够高达25.6万。别的,io1 存储供给的 SLA 也更高,为99.9%的恳求在毫秒等级。计费也是依照存储空间和 IOPS 分隔计费。
  • HDD 存储是过期的存储类型,首要为了坚持兼容性而存在,其最大存储空间为3TB、最大 IOPS 为1000。

在实践的挑选中,开发测验环境则能够运用 gp2 类型、一般事务运用 gp3 类型,关于中心事务则能够运用 io1 类型。

1.5 规范代码

关于规范代码,国内的云厂商一般不是太着重,也不是太重视。可是 AWS 由于其规范代码十分规范,也十分简洁,所传达的意义也比较准确,所以许多时分,在提及规范时,我们会运用其规范代码,而不是运用 vcpu 数量和内存巨细。

例如,db.m6gd.16xlarge,则能够知道这是一个数据库实例,64vCPU,256GB内存,而且为 Graviton 架构的第六代(Graviton 2)实例,而且在本地具有额外的 NVMe SSD。

  • 规范代码中的“db”代表了这是一个用于数据库的实例(ec2);
  • {t|m|r|x}别离代表了突发型实例 t(小规范)、规范实例 m(内存 cpu 比为4)、内存优化型 r(内存 cpu 比为8)、内存优化型 x(内存 cpu 比为16);
  • 跟在这以后的,则是 CPU 的迭代;
  • 数字之后的或许呈现的字母包含:g、d、n、i等。g代表这是一个 Graviton 类型的实例、d 代表该实例本地有额外的、增强的存储资源、n则代表了额外的网络才能、i 代表这是一个 Intel X86 架构的实例。

1.6 其他

1.6.1 关于“可用区”

可用区能够理解为一片机房区域。例如,在东京东部的某个机房区域,一般会稀有栋机房。一个大区域(Region,例如东京)会有多个可用区。

1.6.2 弥补说明

  • 本文内容首要聚焦于运用最多的各个云厂商的 RDS 数据库的架构与选型,并不包含完整的产品系列;
  • 该架构图旨在协助我们从全体结构上了解云数据库全体归纳,并不是准确的架构图,并不求准确、八面玲珑,例如 RDS MySQL、RDS SQL Server在许多细节上是不同的,这儿并没有体现,这些概况能够参阅各个云厂商的相关文档;
  • 这儿不包含价格、功能相关的内容。

二、阿里云:挑选适宜的 RDS 架构与规范

2.1 架构与规范大图

如何选择合适的云数据库架构与规格

一张图读懂阿里云数据库 RDS 架构与选型

在 v1 版别发布的时分,具体的介绍了阿里云数据库 RDS 首要架构类型、资源复用与规范、数据库专属集群、本地盘与云盘版、通用型与独享型、超配比等内容,这儿不再赘述,假如感兴趣能够参阅:一张图读懂阿里云数据库架构与选型。

2.2 首要的架构类型

数据库一般是企业事务架构中的中心组件,数据库的可用性与事务可用性直接相关。所以,高可用是云数据库架构选型第一个需求重视的内容。

从高可用角度,阿里云数据库供给了根底版(即单节点)、双节点高可用版、三节点企业版。不同的版别,则是在本钱、可用性、数据牢靠性之间的平衡:

  • 单节点经过简略的架构,以最低的本钱供给了根本可用的云数据库服务;
  • 双节点高可用版则是合适绝大多数事务场景的形式,两个节点散布于一个区域的两个可用区,毛病时,切换速度较快,数据双副本,牢靠性也比较高;
  • 三节点企业版,则经过 X-Paxos 完结底层数据一致,并以三副本(两份数据+一份日志)保证数据牢靠性。

2.2.1 根底版(即单节点版别)

阿里云根底版运用阿里如此盘作为数据库存储,挂载在数据库的核算节点上,完结了存储与核算的别离。这使得,核算节点呈现毛病的时分,从头运用一个新的核算节点,再从头挂载原来的数据库存储,即可发动数据库,康复呈现毛病的数据库。所以,在核算节点产生毛病的时分,RPO 一般小于1分钟,RTO 则为5分钟~一小时。当整个可用区产生毛病的时分,RPO 和 RTO 的值则依靠数据库备份的频率状况。

2.2.2 高可用版

两节点高可用是用户运用最多的版别,也是数据库最为常见的架构。数据库由主备两个节点组成,经过数据库层的逻辑日志进行仿制。比较单节点,不管是在数据牢靠性、服务的可用性都有十分大的提高。由于主备节点都在同一个大 region,日志推迟一般都十分小,所以产生单节点毛病时,高可用版的数据牢靠性一般是比较高的。留意到,AWS 对应的双节点版别的 RPO 是零,那么阿里云数据库怎样呢?

具体的,对阿里云 RDS MySQL,阿里云的两节点高可用,依据所挑选的参数模板分为如下三类:

  • 高功能:sync_binlog=1000, innodb_flush_log_at_trx_commit=2, async;
  • 异步形式:sync_binlog=1, innodb_flush_log_at_trx_commit=1, async;
  • 默许:sync_binlog=1, innodb_flush_log_at_trx_commit=1, semi-sync。

其间,“高功能”版别和“异步”版别,都是异步仿制,在产生主节点毛病时,由于仿制为异步的,或许会有少部分的事务日志没有传到备节点,则或许会丢掉少部分事务。也便是说,这两个版别为了完结更好的功能,在数据库的 RPO 上做了小的让步。“默许”版别,运用了半同步仿制,一般,数据牢靠性会更高。但由于半同步或许会有退化的场景,所以,该形式下数据仿制仍是在极点的状况下,还会稀有据丢掉的或许性。

那么,既然“异步”形式和“高功能”都稀有据丢掉的危险,他们的差异是什么什么呢?简略的归纳,“异步”产生微小数据丢掉的或许性更小。由于,主备节点经过设置sync_binlog=1,
innodb_flush_log_at_trx_commit=1,能够最大或许性的保证,主节点的数据牢靠性。

事实上,高可用版别是能够满意绝大多数事务场景的需求的,一方面同一个可用区内数据传输推迟十分小,日志传输一般都十分通畅,即使主节点产生毛病,实践的状况中,一般不会呈现日志推迟。别的,主节点失利后,一般能够经过重启等方式康复,云厂商的硬件都有着较为规范的硬件过保筛选的机制,硬件彻底不行用的状况也并不多。别的,底层磁盘会经过硬 RAID 或许软 RAID 的方式,保证磁盘数据存储的牢靠性,数据即使是在一台机器上,也会保存在两块盘上。

两节点高可用版别在某些特别场景下,数据仍是存在一些不行用危险,例如,当其间一个节点产生毛病,而本地数据量又十分大时,需求从头在一台新的机器上建立备节点时,由于数据量较大,重建时刻一般会比较长,而这时分,主节点则会一直单节点运转,假如不幸主节点再呈现毛病,则会呈现不行用或许数据丢掉。假如,对数据的安全性有更高的要求,则能够考虑挑选“三节点企业版”。

2.2.3 三节点企业版

当时仅 RDS MySQL 有该版别。三节点企业版运用了依据 X-Paxos[^4] 的一致性协议完结了数据的同步仿制,适用于数据安全牢靠性要求十分高的场景,例如金融交易数据等。三节点中,有一个节点仅存储日志,以此完结挨近于两个节点的本钱与价格,完结更高的数据安全与牢靠性。

三节点企业版在创立的时分,能够挑选散布在1~3个可用区。假如需求跨可用区的容灾,则能够让三个副本散布于三个可用区,假如需求更高的功能,则能够让三个副本都在同一个可用区。

2.2.4 关于MySQL的参数sync_binlog, innodb_flush_log_at_trx_commit

在阿里云 RDS 的高可用参数模板挑选中,不同的参数模板,最首要的差异便是这两个参数的不同装备。这是 MySQL 和 InnoDB 在数据安全性上最重要的两个参数。双1设置(sync_binlog=1,
innodb_flush_log_at_trx_commit=1)是数据安全性最高的装备。

数据库是日志先行(WAL)的体系,经过事务日志的耐久化存储来保证数据的耐久化。在一般的 Linux 体系中,数据写入磁盘的耐久化需求经过体系调用 fsync 来完结,相关于内存操作,fsync 需求将数据写入磁盘,这是一个十分“耗时”的操作。而上面这两个参数便是操控 MySQL 的二进制日志和 InnoDB 的日志何时调用 fsync 完结数据的耐久化。所以,这两个参数的装备很大程度上反映了 MySQL 在功能与安全性方面的平衡。

其间,sync_binlog 代表了,MySQL 层的日志(即二进制日志)的刷写磁盘的频率,假如设置成 1,则代表每个二进制日志写入文件后,都会进行强制刷盘。假如设置成 0,则代表 MySQL 自己不会强制要求操作体系将缓存刷入磁盘,而由操作体系自己来操控这个行为。假如设置成其他的数字 N,则代表完结N个二进制日志写入后,则进行一次刷写数据的体系调用。

innodb_flush_log_at_trx_commit 则操控了 InnoDB 的日志刷写磁盘的频率。取值能够是 0,1,2。

  • 其间 1 最严格,代表每个事务完结后都会刷写到磁盘中。
  • 假如该参数设置成 0,那么在事务完结后,InnoDB并不会马上调用文件体系写入操作也不会调用磁盘刷写操作,而是每隔1秒才调用一次文件体系写入操作和磁盘刷写操作。那么,在操作体系崩溃的状况下,或许会丢掉1秒的事务。
  • 假如该参数设置成 2,那么,每次 InnoDB 事务完结的时分,都会经过体系调用 write 将数据写入文件(这时分或许只是写入到了文件体系的缓存,而不是磁盘),可是每隔1秒才会进行一次刷写到磁盘的操作。那么,在操作体系崩溃的状况下,或许会丢掉1秒的事务。比较设置成 0,该设置会让 InnoDB 愈加频繁地调用文件体系写入操作,数据的安全性要比设置成 0 高一些。

咱们能够经过下图来理解这两个参数的意义,以及在操作体系中对应的“写入文件体系”与“刷写数据到磁盘”的意义。首要,在数据库的事务处理过程中,会产生 binlog 日志和 InnoDB 的 redo 日志,这两个日志别离在 MySQL Server 层面和 InnoDB 引擎层面保证了事务的耐久性。在事务提交的时分,数据库会先将数据“写入文件体系”,一般文件体系会先将数据写入文件缓存中,该缓存是在内存中,这样就意味着,假如产生操作体系等级的宕机,那么写入的日志就会丢掉。为了避免这种数据丢掉,数据库接着会经过体系调用,“刷写数据到磁盘”中。此时,即能够以为数据现已耐久化到磁盘中。

如何选择合适的云数据库架构与规格

这时,再回头看看阿里云 RDS 的参数模板。在高功能模板中,”sync_binlog=1000,
innodb_flush_log_at_trx_commit=2, async”,代表了在写入1000个 binlog 日志后再进行刷写数据到磁盘的操作,InnoDB 的日志则都会先写入文件体系,然后每隔一秒进行一次刷写数据到磁盘。在“默许形式下,“默许:sync_binlog=1,innodb_flush_log_at_trx_commit=1, semi-sync”,则是最严格的日志形式,也便是会保证每个事务日志安全的刷写到磁盘。

日志的刷写形式对功能有十分大的影响。假如不去重视这些参数,就直接去测验不同云厂商的功能,则会发现,云厂商之间的 RDS 有着十分大的功能差异。一般,这些差异并不是厂商之前的技能才能导致的,更多的是由于他们在关于安全性和功能的平衡时,挑选的不同的平衡点。

2.3 资源复用与规范

从资源同享与隔离上,RDS 又分为:通用型、独享型和同享型。具体的:

  • “通用型”合适一般的事务运用场景,但有必定的 CPU 同享率,也就说是,有必定的概率实例的资源或许会被其他实例争抢而导致功能的动摇 。
  • “独享型”则运用彻底独享的 CPU 的资源和内存资源,不会同享其他人的资源,自己的资源也不会被其他人同享,所以,有更稳定的功能。
  • “同享型”则与通用型相似 CPU 资源会被同享,而且同享率更高,所以性价比更高,一起受到资源争抢的影响的或许性也更大,当时仅 SQL Server 支撑。

除了,上述首要规范类型之外,阿里云还供给了“独占物理机”规范,挑选该规范的用户能够彻底的独占一台物理机的资源:

如何选择合适的云数据库架构与规格

2.4 数据库专属集群 MyBase

专属集群 MyBase 是阿里云推出的一种特别的形状。能够理解为,是一种全保管 RDS 与自建数据库的中间形状。在全保管的 RDS 根底上,供给了两个严重的才能:

  • 答运用户登录数据库所在的主机;
  • 答运用户装备数据库实例 CPU 的“超配比”。

当然,要求是用户一次购买一个十分大的、能够容纳多个 RDS 实例的“大集群”,专属集群则供给了以上两个才能,以及 RDS 其他的根本才能,包含安装装备、监控办理、备份康复等一系列生命周期办理才能。

运用这种规范,用户具有更大的自由度。一方面能够登录主机,观测主机与数据库的状态,或许将自己原有的监控体系布置到专属集群中。另一方面,用户能够依据自己的事务特色,操控集群内的 CPU 资源的超配比。关于中心的运用,则运用资源彻底不超配的集群;关于呼应时刻没有那么敏感的运用,例如开发测验环境,则能够装备高达 300% 的 CPU 超配比,以此大大下降数据库的本钱。

2.5 关于本地盘与云盘版

阿里云的首要版别都会支撑本地 SSD 和高功能云盘。他们的差异在于核算节点与磁盘存储是否在同一台物理机器上,关于运用高功能云盘的规范,一般是经过挂载一个同区域的网络块设备作为存储。

关于阿里云厂商来说,未来主推的将是云盘版。原因是云盘相关于本地盘来说,有许多的优势:

  • 一致运用云盘版,让云厂商的供应链办理变得简略。假如运用本地盘版别,意味着数据库机型定制性会增强,供应链的困难会增加产品的本钱,终究影响价格。别的,简略的供应链也会让产品的布置愈加规范化,愈加敏捷地完结多环境多区域的布置。
  • 运用云盘版,也能够理解为是“存储核算别离”的架构,那么假如核算节点毛病,则能够快速经过运用一台新的核算节点并挂载云盘,而完结高可用。这种方式有着十分好的通用性,不管是哪种数据库都能够运用,而无需考虑数据库种类之间的差异。不管是 MySQL 仍是 PostgreSQL、Oracle 都能够运用这种方式完结高可用。
  • 云盘版别身供给了必定的高可用与高牢靠才能。云盘自身数据能够经过 RAID 或许 EC 算法完结数据的冗余与高可用,而且能够将数据分片到不同的磁盘与机器上,全体的吞吐会更高。
  • 云盘版别身是散布式的,能够供给更高的吞吐,一般还能够供给更大的存储空间。例如,各个云厂商的云盘存储都能够供给 12 TB 或 32 TB 的存储空间,根本上能够满意各类事务需求。

当然,运用云盘也有一些缺陷,例如,比较本地盘,云盘的访问推迟更大,需求经过网络访问,而关于数据库这类 IO 极端敏感的运用,本地磁盘的 IO 功能的稳定性一般会更强一些。

2.6 关于通用型与独享型的功能

独享型规范的资源彻底由用户独立运用,价格一般更贵。而通用型则由于部分资源的同享,会导致功能在某些不行预期的状况下产生一些不行预期的动摇。而独享型规范也更贵,更多的企业级场景,也会引荐运用独享型,会有许多人会以为独享型的功能也更高。而实践上,假如做过实践测验就会发现,一般来说,相同的规范,通用型的功能与吞吐一般都会更高。

所以,实践状况是,通用型的价格愈加廉价,功能也会更好。缺陷在于,或许会呈现一些不行预期的功能动摇,而由于大多数数据库运用都是 IO 密集型的,所以,实践场景中,这种不行预期的动摇并不是十分多。

所以,这两个版别的挑选,需求用户依据自己的实践状况去挑选。假如,能够接受偶尔的功能动摇,则必定是主张挑选通用型的;假如运用对数据库的呼应时刻极端敏感,则应该挑选独享型。别的,当时,通用型最大规范仅支撑 12核 CPU,所以关于压力十分大体系,则只能挑选独享型。

2.7 关于超配比

关于在线数据库运用来说,一般是 IO 或许吞吐密集型的。CPU 资源在许多时分,会有必定的冗余。关于云厂商来说,则能够经过超配 CPU 的售卖率来下降本钱,一起也下降数据库资源的价格,这便是通用型背后重要的逻辑。

而一般来说,能够超配的一般只有 CPU 资源。磁盘资源尽管能够超配,可是实践运用中,是不能重合的,当用户的磁盘占用增到购买值的时分,资源则不能够同享,这与 CPU 的超配并不相同。内存资源则愈加是独享的,Buffer Pool 的一般是满的,不管这些内存页是否被实践运用,数据库总是会极力在内存中存储尽或许多的数据。

MyBase 供给的一个重要装备项,便是能够由用户自界说底层资源的超配比,该比率取值从100%~300%。也便是说,一个 32核 CPU 的资源,最多能够分配给12个8核 CPU 的实例运用,看起来是96=12*8个 CPU 被运用,即完结了 300% 的超配比。

超配比,有时分也会被称为超卖率。

2.8 ARM 架构实例支撑

阿里云数据库在去年11月宣布推出依据 ARM 架构的 RDS 实例,能够向用户供给更高性价比。依据 ARM 芯片的定位,一般性价比更高,可是功能上限比较于 x86 的芯片要差一些。所以,假如数据库实例压力不是很大,而又考虑本钱下降,则能够考虑测验 ARM 架构的 RDS。

别的,zhoujy 在去年11月份对该实例进行测验,相关的数据库能够参阅:MySQL该用哪种CPU架构服务器。

当时,依据 ARM 的 RDS 实例上线时刻还不是很长,假如是出产环境的话,主张做较为全面的测验后再上线。

2.9 RDS MySQL 集群版

在2022年末,阿里云 RDS MySQL 发布了集群版。该产品形状相似于 AWS 供给的“Multi-AZ Cluster”,场景也比较相似。比照最常用的双节点高可用版别,该”集群版”将其备库的衔接地址供给了出来,直接能够用于用户事务,协助用户下降运用本钱。别的,也能够考虑将主库的部分流量直接迁移到备节点,下降主库压力,提高主库的可用性。

假如,在事务场景中,运用了1~2个只读实例的,则能够考虑直接运用该集群版别来替代原有的只读实例。本钱能够得到十分大的下降。

2.10 Serverless 实例

RDS Serverless 是一种优于按量付费、包年包月的资源运用的形式。它供给了自动化的弹性扩缩容,用户无需提早选定规范,后端会依据体系压力进行自动升降配,并依据实践运用计费,当然,用户能够设置 Serverless 实例的最大和最小规范,约束资源最大运用量和最低的服务才能。

关于峰谷显着的事务体系,该形式一方面能够在需求时供给很高的资源规范应对压力,另一方面能够在低峰时下降资源运用量,终究下降本钱。

也留意到,最近阿里云数据库也介绍了客户“微财”运用 Serverless 实例构建云上灾备的事例。运用 Serverless 构建云端低本钱的灾备,确实是一个十分好的场景,一方面满意了客户底层本的诉求,另一方面客户本地的实例假如真的出问题,仍旧能够十分快速的接管。

关于更多 Serverless 测验能够参阅:实测阿里云 RDS Serverless。

2.11 其他

  • 本架构图首要反映阿里云数据库 RDS 的首要架构;
  • ARM CPU 仅部分数据库部分规范支撑,当时仅 MySQL、PostgreSQL 支撑;
  • “集群版”仅 MySQL 和 SQL Server 支撑;
  • 不同数据库的不同的版别,支撑的架构和规范都有不同,这儿并没有体现出来;
  • 不同的区域支撑的数据库、版别均或许不同;
  • 该图的完结得到了阿里云 RDS 团队的协助,在此一起表示感谢;
  • v1 版别发布于2022年5月;v2 版别发布于2023年2月。

三、阿里云 RDS vs AWS RDS 选型差异

AWS 和阿里的数据库产品各自都开展了很长时刻,所在的商场环境、客户场景都有很大的不同,所以,其产品形状也有许多不同的地方,即使是看似相同的名称其意义也或许不同。这儿收拾,阿里云和 AWS RDS 产品的一些差异,以便协助我们更好的挑选产品:

如何选择合适的云数据库架构与规格

3.1 根底版 vs 单可用区版别

不管是在阿里云仍是 AWS,这两个版别都是代表了单节点的架构。可是:

  • 阿里云的“根底版”,着重“根底”,所以均为小规范,最大只有 12v CPU,也没有高可用节点,所以也就只能在一些小场景,如测验环境,中运用。
  • AWS 则着重是“单可用区”版别,并不必定是小规范,其最大规范也能够到 128v CPU,所以其运用场景要更广泛。例如,部分剖析事务节点运用,该类型或许需求十分强的核算才能,可是能够接受必定程度的可用性问题。

3.2 阿里云高可用版 vs AWS多可用区版

这两个版别都是各自厂商的干流版别,是契合大部分 OLTP 事务场景的。但两个厂商的完结各有一些不同,阿里云运用的是数据库层的逻辑仿制,AWS 运用了 EBS 层的同步物理仿制。阿里云 RDS MySQL 在数据维护上,则供给了“高功能”、“异步形式”、“默许”等参数模板,能够让用户在数据维护和功能之间进行必定平衡和挑选,而 AWS RDS 则运用了 EBS 的同步物理仿制,最大极限的维护事务安全。

3.3 阿里云 ARM vs AWS Graviton

阿里云 RDS 的 ARM 规范上线时刻比较短,假如要考虑在出产环境运用,仍是主张做较为充分的事务测验。比较,AWS Graviton 实例现已上线有3年时刻,也有许多的运用事例,相对要愈加的稳定。别的,AWS Graviton 实例在性价比上确实愈加显着,这一点,不管是第三方的测验仍是官方公布的一些数据,都得到了证实。所以,假如部分事务,考虑下降本钱,则能够测验运用 AWS Graviton 实例。

3.4 ESSD vs gp2/gp3/io1

ESSD 的功能上限是更高的,现在 ESSD PL-X 类型现已宣称供给了300万的 IOPS 才能。AWS RDS 所运用的 io1 最大 IOPS 则是25.6万。一直以来,AWS RDS 被诟病比较多的是其依照 IOPS 计费的杂乱逻辑,尽管,看似产品细节十分详尽,可是实践让用户挑选和运用的时分很困惑,另一面,阿里云和其他云厂商都以存储空间计费,愈加简略,并供给与存储空间巨细为必定比率的 IOPS 才能。

AWS 存储的一个优点是,其供给了十分清晰的 IOPS SLA,io1 规范,其 SLA 是99.9%的 IO 恳求呼应时刻是毫秒级,这反响了 AWS 能够向用户供给十分稳定的 IOPS,而不是只是简略的最求 IOPS 上限。

3.5 资源同享 vs 突发型

AWS 在小规范的版别供给了突发功能型实例,能够供给必定的 CPU “超用”(购买了 2v CPU,实践运用更多 v CPU)才能,一起,其“超用”和约束的规则都十分清晰。

阿里云则为了更好的性价比,则向用户供给了“同享型”、“通用型”、“独享型”,让用户在功能稳定性献身十分十分小的状况下,取得更高性价比的实例规范。别的,阿里云供给的 MyBase 规范,更能够自己界说“超卖”比率,让用户依据自己的事务类型和特色进行自界说的装备。阿里云的“独享型”资源则悉数由用户独立运用,也能够保证十分好的功能稳定性。

3.6 规范代码

AWS 的规范代码十分简洁、准确,意义清晰,而且有十分好的连续性。从规范代码中很简单了解到该规范的特色、巨细等特性。

四、最终

阿里云和 AWS 两家的云厂商的数据库服务都经过了十来年的开展,他们在各自的商场和场景下,都十分好的满意了他们客户的诉求,本文档旨在协助我们能够从全体结构加上了解两家厂商首要数据库产品 RDS 的架构。所以在介绍中省掉了十分多的细节内容,也献身了必定的准确性,这些内容能够参阅各种厂商的文档,这儿不做赘述。


周复兴(苏普),NineData.cloud 联合创始人,Oracle ACE(MySQL方向),数据库领域畅销书《高功能MySQL》第三、四版的译者,曾任阿里云数据库资深专家。