AWS Aurora. PolarDB. Polar DB 优化介绍PolarDB. - LeeHao

1 .Aurora&Polar&Taurus An Introduction to Cloud RDBMS

2 .Issues 传统的云数据库 读写实例和只读实例各自拥有一份独立的数据，用户购买只读实例，不仅需要付出计算的成本，也需要付出存储资源的成本 。 传统备份技术，由于也涉及到拷贝数据，并上传廉价存储，速度因此也受网络影响 。 读写实例和只读实例各自拥有一份独立的数据，新建一个只读实例需要重新拷贝 数据 --- 慢 . MySQL/ PostgreSQL 等并未对当前硬件 / 系统软件新特性进行优化，同时由于存在某些特性，导致日志多份写等， 例如： MySQL Bin Log. 由于物理硬件的限制和备份策略等，使得单节点的数据库容量不能太大 . 读写实例和只读实例通过增量逻辑数据同步，导致语句过在 replica 上进行重复解析，执行，存在多余重复计算。

3 .Issues Amazon S3: Amazon Simple Storage Service

4 .In progress. 网络技术技术的发展 . 更高速的网卡，交换机，光纤技术的使用； 新的系统软件和协议的发展 例如： RDMA. (Remote Direct Memory Access) ； 传统的 TCP/IP 协议 , 网卡 , 操作系统 , TCP/IP 协议栈 , 应用 等 , 导致调用链路过长； RDMA, 可以直接访问网络一段的某个主机上的内存地址，从而减少了过长的调用链路； InfiniBand and Enthernet , 两类协议： iWARP and RoCE ； 新理念 , LOG IS DATABASE. 通过重放 REDO LOG ； Binlog (in MySQL) 不在需要，减少 IO ； 存储和计算分离； 分布式文件系统； 分布式计算； 更加强劲的网络基础设施； 新的需求的提出，例如：低成本，低延时，高吞吐量，低备份 / 修复时间等等 .

5 .AWS Aurora. 由 Amazon 提出的一种新型架构的云数据库 . 基本的理念：存储和计算能力将不再是整个系统的瓶颈，网络才是； 通过将 IO 更加均匀的分散在整个系统下； 使得 IO 操作能够并行进行 同步，上下文切换，读磁盘， Cache Miss ， Cache 置换等等都是影响这个系统整体性能的瓶颈； 2PC 提交，导致系统的整体性能下降 . 系统的可靠性变差 ; 不能容忍分布式环境下的短暂故障； 系统延时增加； ....

6 .AWS Aurora. 贡献 跨多数据中心的具有自治愈的独立容错的存储 服务， 网络环境或者云环境下的存储 failure 具有一定的 容错性； Quorum model ，解决网络环境所导致的关联性失败 (Correlated Failure) 仅仅 写 Redo Log 到存储设备 上， 可以使得网络的 IOPS 降低一个量 级； 将某些复杂和关键的一些 函数，从 一个单次执行的耗时的方法，该为将其分布在分布式系统中的多个节点上 运行，减少了这些函数的执行时间； 备份 和 Redo 恢复

7 .AWS Aurora. Quorum Model 鸽巢原理； 解决由于分布式环境下所带来的由于网络环境噪声所带来的节点不 可用； Vr for reading, and Vw for writing. Vr + Vm > V. 保证读操作总能读到最新的数据。 每个写操作必须能够感知大多数的写操作，从而能够避免写冲突， 为了满足上述需求，必须满足： Vw > V /2 ; 通常的做法是 V =3, Vw = 2 and Vr =2;

8 .AWS Aurora. Quorum Model In Aurora 为了避免 az 间的故障和 az 内的故障， aurora 提供了一个新的方案；容忍（ 1 ）整个 az 挂掉，外加一个节点挂掉 （ AZ + 1 ），而不丢数据；（ 2 ）整个 az 挂掉，不影响写操作；为了完成上述的要求；我们采用 6 副本， 3 az 的方式，每个 az 中放 2 个副本； 当我们采用 v =6 的 quorum 模型时候， Vw =4; Vr = 3 ；在该模型下，我们可以容忍挂掉一个 az ，而不是丢失可读性；丢失两个阶段，（包括：整个一个 az ），仍然保持可写 性； 应用场景假设条件：平均修复时间较短，小于两个非相关的节点 down 掉的时间；即：在很短的时间内可以 修复；

9 .AWS Aurora. Segmentation Storage 将数据库的容量，分成固定大小的 一个个 Segmentation ， 10G ； 每 块复制 6 份，复制到保护组 (Protection Group) ，这样每个保护组内有 6 个 10G 的 seg 存在。分散在 3 个 AZ(Availability Zone) 中 ; 所以存储容量是由一系列的 PG ， concatenated 构成（收尾想接构成）， PG 会随着容量的增加而自动分配，最多可以到 64TB segment ，作为后台独立的单元，进行维修。 10gb 可以在 10gbps 网络环境下， 10s 内修复完成 当某个 seg 坏掉的时候，系统会自动进行数据 迁移； 物理上由 Amazon Elastic Compute Cloud(EC2) ，所提供 带有 SSD 的虚拟主机来完成；

10 .AWS Aurora. LOG IS DATABASE 传统数据库，修改一个 Data page 后，产生 WAL-REDO LOG ； Aurora 仅仅会产生跨网络的 REDLOG 写操作 ; 在数据库层没有 Page 写，没有 CheckPoint ，没有后台写操作，没有 Cache 置换； LOG 被下推到存储层； 后台进程负责依据 REDLO 产生所需要的 PAGE ，类似传统数据库总的 Recovery 操作； 为了防止页面在创建过程中修改链过长，后台会持续的将页面物化； 与 Checkpoint 不一样，只有具有较长修改链的页面需要 进行物化处理，而 CheckPoint 是所有的脏页； 存储服务可以进行 Scale-Out;

11 .AWS Aurora.

12 .AWS Aurora. Primary Node 仅仅将 REDO LOG 写入存储服务中； 同时，将这些 LOG 中所涉及到的更新的元数据写到副本中 ; LOG 是按照目的地址 ( 例如：按照 PG) 进行排序，然后发送到 6 个副本中并进行持久化到磁盘； 4 个副本返回 ACK 就认为是 OK ； 副本根据首的 LOG 信息，进行本地 Buffer Caches 的更新； 测试条件： 100G ,Write-Only

13 .AWS Aurora. Storage Service 目的：最小化写请求的延时时间 - 将所有的写操作后台处理； Aurora 中，后端处理负相关前端处理；传统数据库是正相关； 存储节点所涉及到的 IO 操作

14 .AWS Aurora. （ 1 ）接收 LOG 记录并将其添加到内存中的 Queue 中； （ 2 ）持久化 LOG 并返回 ACK ； （ 3 ）规整 LOG 并查找那些 LOG 丢失； （ 4 ）于其他节点进行 Gossip ，来获得所丢失的 LOG 记录； （ 5 ）整合并应用 LOG ，构成新的数据 Page 影像； （ 6 ）定期的将新页面和 LOG 写入 S3 ； （ 7 ）垃圾处理， Old version 且无用的 LOG ； （ 8 ） Page 进行 CRC 验证 ; 仅仅（ 1 ）和（ 2 ）涉及到与前端交互，其他均是异步处理；

15 .AWS Aurora. LOG 前追 （ LOG Marches Foward ） 目的： 一致性的问题；在没有 2PC 的 状态下，进行一致性的 保证 避免比较昂贵 的 Redo log ， 在 Crash Recovery 时候 ； 通过 异步处理的 方式 这里假设的约束是 ： Redo Log 是已 stream 的方式呈现 ， 且 其 Redo Log 顺序描述 了一系列 变化的 顺序，且每个 LOG 具有一个 LSN ； 维护了一个一致性和持久性的位点，该位点并随着我们 收到未完成的存储请求的 ACK 向前移动； 因为任何一个独立的存储节点都可能会 miss 掉一个或者多个 log ； 使用 gossip ，与他们所在 的 PG 中 的其它成员进行通信，来计算他们之间的 gap （即： lsn 之间的差值 ）； 数据库中有多个未完成的独立的事务，他们将独自完成； 数据库在恢复或者重启后，由他们各自决定是否进行回滚操作；

16 .AWS Aurora. LOG 前追 （ LOG Marches Foward ） 存储服务将会计算出能够保证之前所有 LOG 有效性的最大的 LSN ； Volume Complete LSN, VCL; 当存储进行恢复时候，所有 LSN 大于 VCL 的 LOG 将会被丢弃，因为其是属于一致性和有效性不能被保证的 LOG 记录； 其子集（一个是可以被 truncate ，另外一个），能够保证一致性的所有的 LOG 的 LSN ， CPL ， Consistency Point LSN; VDL ， Volume Durable LSN ，所有小于等于 VCL 中的最大的值 CPL ；即所有小于或者等于 VDL 的 LOG 都已经被持久化；而那些大于 VDL 的 LOG 将会被删除； 在实际中，做 recovery 的时候，数据库告诉存储服务，对每个 PG 建立一个 durable point 并且 使用这些 CPL 建立 VDL ， 并且 将这些大于 VDL 的日志记录进行 truncate 。

17 .AWS Aurora. 基本操作 -Writes in Aruroa 数据库持续的与存储服务进行通信，维护状态以便建立 Quorum 模型 ； 系统中可能同时存在大量并发的事务在运行，进而会有非常多的 LOG 记录产生，而每个 LOG 记录都有一个 LSN ，为了防止 LSN 过多， LSN 的数量不能大于当前 VDL 之 和， LSN Allocation Limit(LAL); 当前的设置是 10 million ； 这样可以减少由于过度的 LOG 记录给存储服务带来的压力； PG 中的每个 Seg 只能看到 影像 自己 Seg 上 Page 的 LOG 记录； Segment Complete LSN, SCL; 存储节点使用 SCL 用来进行 Gossip ，从而可以发现自己 Seg 上所丢失的 LOG 记录

18 .AWS Aurora. 基本操作 -Commits in Aruroa 事务提交是异步进行； 一 个线程处理 commit 请求，将 commit lsn 记录到一个 commit list 中后，继续进行其它操作； 与 WAL 相似，当完成提交后会将 VDL 进行前移，同时给前端返回 ACK ； 当我们的提交事务的 lsn 与 VDL 一样或者是最高的 VDL 大于提交事务的 lsn 时候，那么该机制就和 WAL 等价 了 ( 相当于脏页的刷出 ) 工作线程并不会阻断事务的提交操作，其仅仅是从 commit list 中取出待提交的请求，然后执行；

19 .AWS Aurora. 基本操作 -Reads in Aruroa 传统的数据有脏页被刷出 buffer 时候，需要做 IO ； 但 在 Aurora 中，并不会写出（ write out ） victim 页到 磁盘 ； aurora 中，保证 buffer cache 中的页必须并且一直是最新的数据，这样就不存在着 被换出 (evicting) 的 问题，仅仅将其 swap out 就行 为了上述操作，其满足： page 的 LSN 大于或者等于 VDL （这些 log page 的变化并没有被持久化） 。 该协议其 可以 保证（ 1 ） Page 中所有 的变化均被记录在 log 并且（ 2 ）在 cache miss 的时候，其可以请求其中的一个版本作为当前的 VDL ，这样的话就可以获得最新的 durable version 。 使用 read quorum 模型通常情况下不需要建立一致性约束； 在读操作的时候，建立一个读点 (read-point) 作为 VDL ，这与 MVCC 机制中的所建立的 snapshot 相类似； P rotection Group min read point lsn , PGMRPL( 跨节点间的 ), 代表最小的 read view point ，任何小于这个 值的 page 将不会被 读出（ in PG ）。

20 .AWS Aurora. Replica 在单个共享纯粹节点上可以加载：一个写和最高有 15 个读副本。 副本在更新 LOG 记录时候需遵循： （ 1 ）只有那些 LSN 小于或者等于 VDL 的日志可以本副本使用； （ 2 ）作为单 mini-trans 一部分的 LOG 日志，将由该事务自动在副本上进行更新，这样可以保证，该副本所看到的数据的一致性； 实际使用中，每个副本通常落后写操作很短的时间（ 20ms or less ） . 即，副本和主节点的数据相差不太多，可以做到“准”同步；

21 .AWS Aurora. Recovery in Aurora 传统数据库是依据 WAL ，和 Checkpoint 定期的将脏页刷到磁盘上，并在重启后，通过 WAL 进行恢复 Checkpoint 之后的数据； 恢复操作是一个非常耗时， IO 的操作； 虽然可以通过改变 Checkpoint 的间隔来减少恢复时间，但会有过度的 IO ，而这又会影响整个系统性能，两者之间需要权衡； Redo Log 的回放功能模块从数据库中剥离，放在存储节点上并行执行； 通过从新计算每个 PG 中的 VDL ，来重新构建数据；

22 .AWS Aurora. Aurora 将 MySQL 的读写 Disk 接口改为读写存储服务 (from storage service) ； Aurora InnoDB Redo LOG 记录只是描述了数据的变化，其会在每个 PG 内自动的执行回放，并将这些变化写到存储服务上； Aurora 执行与 InnoDB 一样的事务隔离级别，在数据库层实现，并不影响存储服务层的功能； 存储 服务仅仅表示一个统一的底层数据存储功能，与我们通常所使用的本地存储一样； 存储 服务部署在 EC2 VM 上，并提供最少 3AZ;

23 .AWS Aurora. Aurora 将 MySQL 的读写 Disk 接口改为读写存储服务 (from storage service) ； Aurora InnoDB Redo LOG 记录只是描述了数据的变化，其会在每个 PG 内自动的执行回放，并将这些变化写到存储服务上； Aurora 执行与 InnoDB 一样的事务隔离级别，在数据库层实现，并不影响存储服务层的功能； 存储 服务仅仅表示一个统一的底层数据存储功能，与我们通常所使用的本地存储一样； 存储 服务部署在 EC2 VM 上，并提供最少 3AZ;

24 .PolarDB . Polar DB 优化介绍

25 .PolarDB . 包括使用 3DXpoint 存储介质的 Optane 存储卡、 NVMe SSD 和 RoCE RDMA 网络。同时面向新硬件架构实现软硬一体优化 系统 调用层，优化了系统层的调用链路，使得很多系统调用直接在用户态调用； 网络层的协议栈的简化，例如： TCP/IP 的网络协议栈，可以简化，使用基于网络的直接访问； RDAM ，直接远程内存访问，可以使得网络中的某台机器直接访问另外一台机器的内存数据； Redo log 的使用，在 MySQL 中，事务的提交和 binlog 之间使用 xa 来协同，当我们之间使用 redo log ，将该日志复制到其它的存储节点上，通过直接重放 redo log 来，进行 page 层的数据同步，在丛机上无需进行 io 操作了。 不用 binlog ->relay log ，然后通过执行 relay log 中的 event 来进行数据的同步； parallel raft . 试验证明， redo log 下沉的设计比起经典模式，每个事务平均 IO 次数降低了 85%+ ，而且数据安全性也是类似甚至更高的。

26 .PolarDB . 针对数据库的 smart storage 优化 polardb 在文件系统和存储节点之间做了优化； 对 redo log 进行优化处理； redo log 由 512bytes 调整为 4k ，有利于 ssd 设备 ; double write 优化： polar 节点支持 1mb 的原子写，可以关闭 double write 特性 ； group commit: 将一 次数 千 的 IO 操作，并进行 分割为以 16kb 为单位的多个小的 io , 将 这些 io 分散到多个存储节点上执行（做到了并行执行），降低了 IO 的延迟。

27 .PolarDB . Polar 计算引擎优化 Polar 使用共享存储和物理复制，因此实例的备份和恢复依赖于 redo log 。因此去掉了 binlog 。 使得在数据库服务层无需 xa 支持（需要复杂的 xa 逻辑操作，来支持 xa 的正确性），同事无需 binlog 从而可以减少 io 操作； 锁优化 优化了锁。 把 latch 进行细粒度的优化；或者将 latch 改为计数方式； undo segment mutex , log system mutex 等； 将常用的数据结构改为 lock-free 的数据类型， 例如： MDL 锁等 ； 日志提交优化 为减少 redo log 的切换对性能影响，采用 fallocate 方式，预先分配日志文件；将 512 的磁盘对齐方式，改为 4k 的对齐方式； 在组提交时候，采用 double redo log buffer 提升并行度； 复制优化 由于采用基于 redo log 的物理复制，使得我们可以进行更细粒度的并行化操作；例如：使用 length 来指定长度，无需进行动态 parse ；使用 dummy index, 减少在 malloc /free 上的开销；

28 .PolarDB . 读节点性能 polar 节点是，日志一批批的 apply, replica 上读请求不需要重复创建 readview 。 可以使用上次缓存，从而提高 replica 上性能； 透明压缩 polar 提供了 1mb 的 数据文件 idb 的原子写操作； 消除了 double write （为了消除 partial write 的问题），同时，支持透明压缩； 2.4 倍压缩率；压缩在存储节点内实现，无需消耗计算节点的 cpu 。不影响 db 性能；利用 qat 卡进行加速，在 io 路径上使用 fpga 进行加速； 存储节点，支持快照去重，数据库相邻快照之间，如果页面没有发生修改，会链接到同一个物理页面上，物理上只存储一份 ；

29 .PolarDB . 底层共享同一份数据文件和日志文件 传统的文件系统，由于嵌入在操作系统内核中，每次系统文件读写操作都需要先陷入内核态，完成后再返回用户态，造成效率低下。 PolarFS 以函数库形式编译在 MySQL 中，因此都运行在用户态，从而减少了操作系统切换的 开销； 计算 节点和存储节点之间通过 25G RDMA 网络连接，保证数据的传输瓶颈不会出现在网络 上； 物理 复制中的 DDL 。 Primary 节点删除一个表之后， Replica 可能还会有对此表的请求。因此，我们约定，如果主库对一个表进行了表结构变更操作，在操作返回成功前，必须通知到所有的 Replica( 有一个最大的超时时间 ) ，告诉他们，这个表已经被删除了，后续的请求都失败吧，具体实现上可以使用 MDL 锁来控制。当然这种强同步操作会给性能带来极大的影响，后续我们会对 DDL 做进一步的 优化； 物理复制能带来性能上的巨大提升，但是逻辑日志由于其良好的兼容性也并不是一无是处，所以 PolarDB 依然保留了 Binlog 的逻辑，方便用户开启。