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 负载下，分布式存储还会出现网络中 Inflight IO 较多的情况，导致 IO 任务数组中请求的添加与移除成本显著增加。为此，PolarDB 针对 IO 系统进行了全新设计，重点包括：合理选择 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 主要承载区域间数据同步任务，通过订阅二进制日志并分发到不同区域，再进行高速应用，从而实现区域间数据状态一致。今年，PolarDB 集成了全新的全球数据库技术，用于解决跨地域访问和容灾问题。PolarDB 全球数据库（PolarDB Global Database Network，PolarDB-GDN）采用数据库物理日志异步复制方案。但要实现这些目标，必须解决两个关键难点：高网络延迟下的数据同步问题，以及跨 Region 的数据读写问题。针对这两个挑战，PolarDB-GDN 借助高并发流水线技术，将同步速度提升 7 倍，并将跨大洲数据同步延迟控制在 2 秒以内。与此同时，全局读写分离技术结合多级别一致性能力，让业务无需做任何改造，就能有效降低整体访问延迟，提升全球业务访问体验。

热缓存技术

双十一对数据库高可用的要求极高。核心应用在大促期间长期处于高负载运行状态，单个节点发生故障几乎不可避免，因此如何实现快速恢复成为关键课题。过去，节点故障恢复通常需要较长时间，系统重启后还需要经过缓存预热，才能恢复到最佳访问性能。

今年，PolarDB 在存储计算分离架构基础上进一步升级，实现了计算与内存的分离。通过将内存缓冲池从计算节点中剥离，计算节点的状态被最小化。这样在计算节点重启后，系统可以快速恢复到重启前状态，避免耗时较长的缓存预热过程。传统数据库在错误恢复时，需要从检查点开始扫描全部 redo 日志，并进行日志回放、事务恢复等操作，这一过程涉及大量磁盘 IO 和 CPU 计算，恢复时间通常较长。而采用热缓存技术的 PolarDB，在计算节点崩溃后，需要修复的只是可能处于不一致状态的缓存，例如尚未修改完成的缓存页面以及部分内存结构。在计算与缓存分离的架构下，只需由新的计算节点根据控制信息和 redo 日志，将这些受污染的内存恢复到一致状态即可。由于无需重新构建缓存池，整体修复工作量大幅降低。在常规读写负载下，传统方式重启后的数据库最大吞吐可能下降到原来的 5% 以下，并在约 200 秒后逐步恢复正常；而采用热缓存技术的 PolarDB 实例几乎不会出现明显性能下降。

跨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 数据业务，也持续在云上为更广泛的企业客户提供高性能数据库服务。我们的目标，是让云原生数据库技术普惠更多企业客户，帮助客户更高效地释放数据价值、实现业务增长。

原文链接
本文为阿里云原创内容，未经允许不得转载。