2020 年是云原生数据库 PolarDB 全面撑持天猫双十一的第二年，天猫交易、买家、卖家以及物流等零碎在双十一期间基于 PolarDB 为亿万客户提供了顺滑的体验。同时，PolarDB 还刷新了去年由本人发明的数据库解决峰值（TPS）纪录，往年 TPS 峰值高达 1.4 亿次 / 秒，较去年晋升了 60%。
PolarDB 是阿里自研的云原生数据库品牌，通过独有的存储计算拆散、分布式共享存储技术，解决了传统 RDBMS 容量无限、扩缩容工夫长等问题，在性能、容量、弹性、以及可用性上都有很大的冲破：
存储容量可达 100TB，单库可扩大到 16 个节点，满足企业级大数据存储需要。
高性能、高弹性、低成本，一写多读，分钟级扩缩容
多 AZ 高可用，数据高可靠性。跨 AZ 六正本，故障疾速容灾转移
PolarDB 往年下半年公布了 MySQL 5.7 的兼容版。至此 PolarDB 成为寰球惟一一家兼容 MySQL 所有在役版本的云数据库，能够笼罩更多的业务场景
性能优化
性能对于双十一大促来说是永恒的主题。在天猫的外围交易链路的数据库，在零点峰值场景中，会有大量的数据读写。而每一年随着峰值的增长，数据库会遇到更严厉的挑战。在过来的几年中，随着数据库硬件的一直进化，咱们为 PolarDB 重点优化了索引构造、I/ O 子系统、锁零碎以及事务零碎来实现并发性能的晋升。
首先是索引构造。家喻户晓传统的 InnoDB 索引在这样的场景下会遇到频繁的页面决裂导致的并发瓶颈。所有的对索引构造的批改都要排队串行执行。为了解决这个问题，PolarDB 引入了新的索引构造来代替传统索引，细化索引构造变更时的并发粒度，晋升了靠近 20% 的读写性能。新的索引构造使得本来须要将所有波及索引决裂的页面加锁直到整个决裂动作实现后才开释的逻辑变成逐层加锁。这样本来被索引页面决裂阻塞的读操作会有机会在整个决裂动作两头进来：通过对每个节点减少一个后继链接的形式，使得在决裂的中间状态也能够实现对数据页面的平安的拜访，从而进步读取性能。
其次是 IO 子系统。因为 PolarDB 是采纳的用户态文件系统，因而须要有一套对应的 IO 零碎来确保对底层分布式存储的高效拜访，InnoDB 原有的 AIO 策略，是将所有异步 IO 申请依照指标地址进行组织寄存在同一个 IO 数组中，不便将指标地址间断的小 IO 合并成大 IO 以晋升 IO 的吞吐，然而在分布式存储的场景下间断的大 IO 操作，会使得同一时刻，只有一个或大量存储节点处在服务状态，其余的存储节点处于闲暇状态，此外，分布式存储在高 IO 负载的场景中会呈现网络中的 Inflight IO 较多的状况，IO 工作数组中增加 I 和移除申请的开销都很大。为此 PolarDB 专门对 IO 零碎进行了从新的设计，次要包含：正当的抉择 IO 合并和拆解，充沛利分布式存储的多节点劣势；建设状态有序的 IO 服务队列，缩小高负载下的 IO 服务开销。新的子系统让 PolarDB 在写入和读写混合的场景下性能和稳定性都失去了显著的性能晋升。
再接下来是锁零碎的优化。PolarDB 和 MySQL 一样都是采纳 MVCC 的形式看来做事务之间的并发管制，然而在解决写申请和写申请之间的并发时是通过两阶段的锁来做爱护的。大量且频繁的插入更新删除带来了锁零碎的累赘和并发的瓶颈。因而 PolarDB 采取了 Partition Lock System 的形式，将锁零碎革新成由多个分片组成，每个分片中都有本人部分的并发管制，从而将这个瓶颈打散。尤其是在这种大压力的写入场景下显著的晋升写入性能。
最初是事务零碎。PolarDB 中反对 Snapshot Isolation 的隔离级别，通过保留应用的 Undo 版本信息来反对对不同版本的记录的拜访，即 MVCC。而实现 MVCC 须要事务零碎有能力跟踪以后沉闷及曾经提交的事务信息。在之前的实现中每当有写事务开始时，须要调配一个事务 ID，并将这个 ID 增加到事务零碎中的一个沉闷事务列表中。当有读申请须要拜访数据时，会首先调配一个 ReadView，其中包含以后已调配最大的事务 ID，以及以后这个沉闷事务列表的一个备份。每当读申请拜访数据时，会通过从索引开始的指针拜访到这个记录所有的历史版本，通过比照某个历史版本的事务 ID 和本人 ReadView 中的沉闷事务列表，能够判断是不是须要的版本。然而，这就导致每当有读事务开始时，都须要在整个拷贝过程对这个沉闷事务列表加锁，从而阻塞了新的写事务将本人的 ID 退出。同样写事务和写事务之间也有拜访沉闷事务列表的抵触。从而沉闷事务列表在这里变成一个显著的性能瓶颈，在双十一这种大压力的读写场景下尤为显著。对此，咱们将事务零碎中的这个沉闷事务列表革新成无锁 Hash 实现，写事务增加 ID 以及读事务拷贝到 ReadView 都能够并发进行。大大晋升了性能。
寰球数据库技术
诸如 AliExpress 这一类针对海内消费者的购物大促，业务遍布各个大洲和国家等等。因而数据库的异地可读，数据同步有十分高的要求。在过来 DTS 承载了区域间数据同步工作，DTS 订阅了二进制日志而后散发到不同的区域并进行高速利用以实现区域间数据状态一致性。往年 PolarDB 集成了全新的寰球数据库技术来解决跨域拜访以及容灾的问题，PolarDB 寰球数据库（PolarDB Global Database Network，PolarDB-GDN）采纳了数据库物理日志异步复制的计划。然而达成以上指标须要解决几个要害难点：高网络提早下的数据同步问题和跨 Region 的数据读写问题。针对这两点问题，PolarDB-GDN 通过高并发流水线技术将同步速度晋升 7 倍，将数据跨大洲同步提早管制在 2 秒内。全局读写拆散技术联合多级别的一致性能力，让业务不必做任何的革新的前提下升高整体的拜访提早。
热缓存技术
双十一对数据库的可用性要求十分高，外围利用在大促期间处于高负载的状态，长时间高负荷的运行不可避免会存在繁多节点的故障，如何能疾速复原成为了一个重要的课题。过来的节点故障复原须要经验相当长的工夫的复原工夫，而重启拉起后的零碎还须要缓存预热后能力达到最佳拜访性能。
PolarDB 往年在存储计算拆散架构上持续往前迈进一大步，实现了计算和内存的拆散。通过将内存缓冲池从计算节点剥离，让计算节点状态最小化。计算节点重启后能够疾速复原到重启前的状态，防止大量耗时的缓存预热。传统数据库的谬误复原须要检查点开始扫描所有的 redo 日志、回放日志、事务复原等步骤，该过程波及大量磁盘 IO、CPU 计算等工作量，其工夫往往很长。应用了热缓存技术的 PolarDB 在计算节点解体后，须要复原的是缓存可能处于不统一的状态，如局部尚未批改实现的缓存页面以及内存构造等。而在 CPU 缓存拆散的架构下只须要新的计算节点来依据各种管制信息和 redo 日志将这些被净化的内存复原到统一的状态。因为无需从新构建缓存池，修复工作量小。在惯例读写负载下，重启后的数据库最大吞吐降落到原来的 5% 以下，并在 200 秒后逐步恢复正常程度，而利用了热缓存技术的实例简直无任何性能降落。
跨 AZ 容灾能力
双十一的外围业务必须要可能跨 AZ 的容灾，PolarDB 提供了跨 AZ 容灾 RPO 为 0 的计划。PolarDB 在存储层（PolarStore）提供 3 正本的同时，还能够通过自研的 X-Paxos 库提供跨节点、跨机房、跨 AZ 级别的数据同步能力，提供 RPO = 0 的容灾解决方案。这个计划利用 PolarDB 通过多年验证的物理复制技术和 X-Paxos 一致性协定库，提供高牢靠、低提早的数据复制技术。相比于 RDS/MySQL 的逻辑日志复制，PolarDB 在节点切换时，受大事务 /DDL 的影响更小，RTO 小于 1 分钟。同时，这个计划在保证数据冗余的同时，尽量减少部署老本。PolarDB 跨 AZ 版能够部署 Leader，Follower 和 Log 节点。其中 Log 节点只记录日志，不参加选主，不存储数据，部署老本相比于现有架构只减少了 active redo log，显著升高了部署老本。
并行查问加强
双十一不仅是消费者的盛筵，也是泛滥卖家的狂欢。卖家常常须要实时的查问本人的销售数据以及做一些疾速的剖析。PolarDB 领有查问引擎，在泛滥场景下能满足一些即时查问的需要，它充分利用硬件多核优势，并基于 COST 主动抉择并行查问引擎，显著晋升了查问性能。往年 PolarDB 在该方向并没有进行脚步，利用并行查问引擎了优化更多的利用场景。在大规格的实例中，并行的晋升成果尤为显著。
在往年，PolarDB 的并行查问新减少了泛滥场景的笼罩，有联结 (Union) 子查问的并行优化，扩大并行查问引擎对联结 (Union) 子查问的反对；派生表 (Derived Table) 的并行优化；用户自定义长期表的并行优化；Count 的并行优化；Limit 的并行优化；条件下推优化，缩小数据汇总代价；HASH JOIN 的并行优化，同时优化算子和执行的并行度。
除此之外，POLARDB 对 GROUP BY / Distinct / SEMI-JOIN / 常量表以及蕴含 Window 函数的子查问也做了并行优化，通过利用更多的 CPU 资源，无效升高了这些场景下的查问耗时。在规范的 TPC- H 场景下，POLARDB 的并行查问框架获得了十分好的体现。
并行 schema 变更
在阿里的业务中大量的 POLARDB 承载了超大规模的数据，然而业务的需要是实时变动的。过来对这些大表做 DDL 会继续数小时甚至数天，如此之高的提早是难以容忍的。以创立二级索引为例，过高提早的 DDL 操作会阻塞后续依赖新索引查问的 DML 操作。DDL 操作会耗费 CPU/Memory/IO 资源，对业务 DML 带来肯定的影响，因而用户往往在业务低峰期进行 schema 变更，然而如果不能确保变更在业务低峰期之内实现会对业务的稳定性产生重大的影响。
咱们认为大表 DDL 运行迟缓的根本原因在于传统的 DDL 操作是针对单核和传统硬盘设计的。随着多核处理器的日益倒退和高速存储的遍及，DDL 的并行化是能够获得十分好的成果的。
Online DDL 分为创立长期表扫描拷贝全量数据加上增量利用期间的变更等几个次要阶段。以减少索引为例须要扫描主键所有记录，生成新的二级索引记录，写入磁盘文件中；对所有二级索引记录进行排序，写入磁盘文件；将有序的二级索引记录插入到新的二级索引中。
POLARDB 能够对索引树进行并行扫描、并行多路归并的 Merge Sort、并行的 Bulk Load 索引。在 8core32G 规格的实例中针对 CPU Bound 和 IO Bound 的场景别离进行了测试，都能够达到 6 -13 倍的速度晋升。
总结
往年的双十一对 PolarDB 在性能和性能上提出了更高的要求。PolarDB 在并发性能、跨域、弹性以及可用性上都更进了一步，POLARDB 不仅承载着整个阿里团体的实时 OLTP 数据业务，而且在云上为更为宽广的客户提供服务。咱们的指标是将云原生的数据库技术普惠所有的企业客户，帮忙客户更好的实现业务价值。
原文链接
本文为阿里云原创内容，未经容许不得转载。