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

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

Issues Amazon S3: Amazon Simple Storage Service

In progress. 网络技术技术的发展. 新的系统软件和协议的发展 新理念, LOG IS DATABASE. 存储和计算分离； 更高速的网卡，交换机，光纤技术的使用； 新的系统软件和协议的发展 例如：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； 存储和计算分离； 分布式文件系统； 分布式计算； 更加强劲的网络基础设施； 新的需求的提出，例如：低成本，低延时，高吞吐量，低备份/修复时间等等.

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

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

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

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掉的时间；即：在很短的时间内可以修复；

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的虚拟主机来完成；

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

AWS Aurora.

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

AWS Aurora. Storage Service 目的：最小化写请求的延时时间-将所有的写操作后台处理； 存储节点所涉及到的IO操作

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）涉及到与前端交互，其他均是异步处理；

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之间的差值）； 数据库中有多个未完成的独立的事务，他们将独自完成； 数据库在恢复或者重启后，由他们各自决定是否进行回滚操作；

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。

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记录

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

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相类似； Protection Group min read point lsn , PGMRPL(跨节点间的), 代表最小的read view point，任何小于这个值的page将不会被读出（in PG）。

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

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

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

AWS Aurora.

PolarDB. Polar DB 优化介绍

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%+，而且数据安全性也是类似甚至更高的。

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

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上的开销；

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

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

PolarDB.

PolarDB.

PolarDB. 参考资料： 1.http://mysql.taobao.org/monthly/2017/09/01/ 2.http://www.infoq.com/cn/news/2017/08/ali-polardb 3.https://www.zhihu.com/question/63987114 4.《Amazon Aurora: Design Considerations for High Throughput Cloud-Native Relational Databases 》 …