阿里云原生数据库的架构与实践

阿里云原生数据库系统的机遇与挑战

1. 引言

随着越来越多的应用程序和系统向云端迁移，云原生数据库系统开始获得广泛的支持和认可。云服务提供商（如亚马逊云科技、微软Azure、阿里云和谷歌云）提供的云数据库服务推动了云原生数据库的发展。因此，近年来云数据库的市场份额快速增长。越来越多的企业和组织已将其业务从本地数据中心迁移到云端。云平台提供了高弹性、严格的服务等级协议（SLA）以确保可靠性，并通过降低运营成本实现简便的可管理性。云数据库在支撑云上业务中发挥着关键作用，成为连接底层资源（基础设施即服务）与各类应用程序（软件即服务）的核心枢纽，是云计算的关键系统。

在阿里巴巴集团，数据库系统需要支持一个涵盖娱乐和数字媒体、电子商务与电子支付以及各种新零售和线上到线下（O2O）业务运营的丰富而复杂的商业生态系统。在 2018年双11全球购物节（2018年11月11日）期间，阿里的数据库每秒处理高达49.1万笔销售交易，相当于每秒超过 7000万次事务。传统的本地部署数据库由于对弹性、可扩展性和可管理性的需求，难以跟上此类业务运营的复杂性。例如，如图1所示，在双11购物节的第一秒内，每秒事务数（TPS）突然上升，约为前一秒的122倍。当我们简单地在带有本地SSD和高I/O虚拟机的云实例存储上部署MySQL或 PostgreSQL时，所得到的数据库实例容量有限，这导致不适合提供可扩展的数据库服务。它无法抵御底层磁盘驱动器故障；并且数据库实例必须自行管理数据复制以确保可靠性。此外，该实例使用通用文件系统（如 ext4 或 XFS）。在使用低 I/O 延迟硬件（如 RDMA 或 PCIe SSD）时，内核空间与用户空间之间的消息传递开销可能会迅速使吞吐量达到饱和。相比之下，采用云原生设计的数据库（如计算与存储分离、自动扩展）更具吸引力，能够提供更多的计算和存储容量，并实现更快的恢复速度和更低的成本 [30, 7]。

云原生数据库还有其他一些至关重要的能力：multi-model 支持异构数据源和多样化的查询接口；autonomy and intelligence 能够自动管理和调优数据库实例，以降低手动操作的成本；software-hardware co-design 充分利用高性能硬件的优势；以及 high availability =0 满足严格的SLA需求（例如，极小RTO的RPO）。基于这些设计，云原生数据库在云环境部署中实现了快速增长。

本文报告了阿里云在构建云原生企业数据库方面的最新进展，这些数据库同时支持阿里巴巴集团各业务单元（从娱乐到电子商务再到物流）的全部业务运营。为满足广泛的应用需求，我们提供了如图3所示的多种数据库系统和工具。特别是，我们开发了POLARDB，一种共享存储OLTP数据库，每个处理节点可提供100TB的存储容量和每秒100万次查询的性能。为进一步扩展容量，我们开发了POLARDB‐X，这是一种融合了无共享和共享存储架构设计的分布式OLTP数据库。此外，我们还开发了分析型数据库AnalyticDB，作为一种下一代数据仓库，支持在PB级规模下进行高并发、低延迟和实时分析查询。为了管理在我们云平台上托管的大量数据库实例，我们构建了SDDP，一个自主的数据库运维平台，能够自动管理实例并在最少数据库管理员参与的情况下优化性能。目前，阿里云上运行着近五十万个数据库实例（来自我们的云客户以及阿里巴巴集团内部各个业务单元）。POLARDB和分析型数据库 AnalyticDB已在包括电子商务、金融、媒体与娱乐、教育、新零售等众多行业领域实现了快速的增长。这些云数据库系统和技术已成功服务于阿里巴巴集团内部复杂的业务生态系统以及众多外部企业客户。

2. 阿里巴巴数据库系统的架构

根据共享内容的不同，阿里巴巴在构建数据库系统时探索了三种流行的架构，如图2所示。第一类是 single instance，这是主流数据库最常使用的架构。在这种模式下，数据库中的所有进程共享处理器核心、主存空间和本地磁盘（即在同一台机器上）。这种架构促进了系统内部的通信与协调。

随着谷歌、亚马逊、微软和阿里巴巴等大型互联网企业所面临的数据量和峰值工作负载的快速增长，单实例架构已显现出其固有的局限性。单台机器的容量已无法满足日益增长的业务需求。因此，提出了 shared storage 架构，以AWS Aurora [30]和阿里巴巴POLARDB [5]为代表。在这种架构中，底层存储层（通常由多个节点组成）被解耦，存储中的每条数据记录均可被运行在任意节点上的上层数据库内核访问。

通过利用RDMA等高速网络，数据库可以像访问单个（共享）本地盘一样与共享分布式存储层进行交互。在此共享存储之上，可轻松启动多个计算节点，创建单个数据库的副本，并对相同数据保持一致视图。因此，请求可被分发至不同的（只读）节点进行并行处理。然而，为了避免写冲突以及避免处理分布式事务处理和分布式提交的复杂性，通常仅有一个节点负责处理数据库的所有写入请求（例如INSERT、UPDATE、 DELETE）。该架构可通过调整只读节点的数量，实现按需动态调整查询能力。此外，也可通过允许多个节点执行写入（即多主）来扩展写入能力，但这通常需要复杂的并发控制机制和共识协议[6, 12, 16, 17, 23, 34]。

共享存储架构也存在自身的局限性。首先，计算和存储节点之间的低延迟数据传输无法始终得到保证。对于跨交换机、跨数据中心甚至跨区域传输的消息，传输时间会显著增加，尤其是在使用本地RDMA网络的情况下。其次，单个数据库支持的只读节点数量有限。当节点数量达到一定规模时，大量请求将被阻塞，导致对远程存储的访问成本极高且难以承受。因此，实际限制是只读节点数量大约最多为十几个。为解决此问题，我们需要一种 shared nothing 架构。在此模型中，一个逻辑数据库被划分为多个分片，每个分片分配给一个节点。这些节点可以部署并复制到不同的数据中心和区域中。该架构的一个代表性实现是Google Spanner [7],，其利用GPS和原子钟实现跨区域的副本一致性和事务一致性。在阿里云上，我们构建了POLARDB‐X，它扩展了POLARDB，并探索在共享存储架构之上构建无共享系统的优点。

多个数据库，每个数据库共享分布式存储。

请注意，这种无共享与共享存储架构的混合带来了一些特殊优势。我们可以在顶层应用分片，但为每个分片分配多个节点（而不是每个分片一个节点）。在此分片之下，这些节点可以访问共享存储。这种混合架构的优势在于缓解了拥有过多小分片所带来的缺点。特别是有助于简化分片再平衡过程，并降低跨分片事务的概率（从而减少昂贵的分布式提交次数）。同时，它实现了出色的横向扩展性。这种结合了无共享和共享存储优势的混合架构，是POLARDB‐X数据库设计中探索的一个有前景的方向。

3. 阿里巴巴数据库系统的其他关键特性

除了探索不同的系统架构外，阿里巴巴数据库系统在设计时还考虑了由阿里巴巴复杂的业务应用所驱动的其他关键特性。

3.1 多模型分析

阿里巴巴的一个重要应用场景是支持多模型分析，这包括两个方面：南向和北向多模型访问。南向多模型访问指底层存储支持不同的数据格式和数据源，所存储的数据可以是结构化或非结构化的，例如图、向量和文档存储。数据库随后提供统一的查询接口（如SQL或类SQL接口），用于查询和访问各种类型的数据源和格式，从而形成数据湖服务。北向多模型访问指使用单个数据模型和格式（通常为键值模型）在单个数据库中存储所有结构化、半结构化和非结构化数据。在此单一存储模型之上，数据库根据应用需求支持多种查询接口，例如SQL、SPARQL和GQL。微软CosmosDB [9] 是此类系统的代表性系统。

除了满足内部业务运营需求外，支持多模型分析也是云数据库服务的基本要求。许多云应用程序需要从异构来源收集大量数据，并通过联邦分析关联不同数据源以揭示业务洞察（即南向多模型访问）。另一方面，云数据库（例如像HBase这样的大型KV存储）通常是被多个具有不同应用需求的应用程序访问的核心数据存储库。由于可用性和效率的考虑，这些应用程序可能倾向于使用不同的查询接口，这就需要北向多模型分析。

3.2 自治与智能

鉴于阿里巴巴的数据库系统需要管理大量的数据库实例，并面临复杂工作负载，使数据库运维平台更加自治和智能成为一项基本要求。在我们的平台上运行着数十万个在线数据库实例，依赖人工进行运维是不可行的基于传统的数据库管理员（DBA）手动操作、调优和维护，以单个实例为单位进行。从数据库内核和底层操作平台的角度来看，支持自主操作存在诸多机遇。为此，我们致力于构建一个具备自检测、自决策、自恢复和自优化能力的自动驾驶数据库平台（SDDP）。以自优化为例，通过采用机器学习技术，增强数据库内核中的各个模块（如索引、查询优化器和缓冲池管理），使这些模块能够针对动态工作负载进行自适应优化。

然而，由于机器学习模型的训练与推理成本较高，在数据库内核中实现高效且有效的机器学习集成是一项具有挑战性的任务。

另一方面，自检测、自决策和自恢复则旨在提升数据库操作平台的效率与有效性。其中的关键挑战包括：如何自动检查实例状态并检测异常行为；以及一旦发现问题，如何在较短的响应时间内做出正确决策以修复错误。

3.3 软硬件协同设计

阿里巴巴数据库系统的另一项关键创新方向是探索并利用硬件领域的快速发展与创新。与其他系统一样，我们的目标是设计和实现能够安全、高效地使用有限的系统硬件资源的数据库系统。这意味着系统必须密切关注硬件特性的持续变化与改进，以便充分利用创新性硬件功能的优势。作为性能关键型系统，数据库系统需要充分调动可用资源，以稳健且高效的方式执行查询与事务。随着硬件特性不断进步，若简单沿用现有的数据库设计，期望其在新硬件上仍能实现最佳性能，则是不明智的。例如，在相同CPU和内存配置下，复杂数据库（如 MySQL）直接运行在支持RDMA的分布式存储上的性能显著低于运行在本地PCIe SSD上的情况，这要求进行细致的重新设计[5]。因此，在设计阿里巴巴的数据库系统时，必须充分考虑新硬件所带来的机遇。例如，我们已广泛探索并整合了 RDMA、非易失性内存、图形处理器/现场可编程门阵列以及 NVMe SSD等新型硬件技术。

3.4 高可用性

高可用性是阿里巴巴数据库系统的基本要求之一，以确保我们的业务运营和云客户实现零停机，因为大多数企业客户无法容忍其业务中断。实现高可用性的一种典型解决方案是复制，复制可以在数据库实例、表或表分片的粒度上进行。广泛使用的主备复制和三副本复制在大多数场景下都能胜任。对于需要更高可用性的银行与金融行业，可能会强制使用四个或更多副本，这些副本通常部署在不同的数据中心（可用区）和区域中，以应对大面积故障（如网络故障和数据中心宕机）。

在采用复制技术时，必须谨慎处理副本之间的数据一致性。CAP定理指出，在一致性、可用性和分区容错性这三项特性中，最多只能同时满足其中两项。在阿里巴巴，我们在设计和实现数据库系统时优先考虑“C”（一致性）和“P”（分区容错性），并通过一种名为X‐Paxos的定制化并行Paxos协议来保障高可用性，确保系统仍能提供高达99.999%的可用性。X‐Paxos实现并优化了复杂的复制技术和共识协议，并通过日志机制保障数据一致性和可用性。

4. 阿里云原生数据库

在本节中，我们分享阿里巴巴在构建云原生数据库系统方面的最新进展。阿里巴巴及阿里云上的数据库系统与产品的完整概述见图3。我们重点讨论POLARDB（一种共享存储 OLTP数据库）及其分布式版本POLARDB‐X（一种基于 POLARDB构建的分片无共享OLTP数据库）、AnalyticDB （一种实时交互式OLAP数据库）以及SDDP（一个自治数据库运维平台）。

4.1 POLARDB：云原生OLTP数据库

POLARDB 是基于 AliSQL（MySQL/InnoDB 的一个分支）构建的关系型数据库系统[2],，可在阿里云上作为数据库服务使用。POLARDB 采用云原生架构，具有高弹性、大容量和高并发的特点。此外，POLARDB 完全兼容 MySQL 和 PostgreSQL，有助于客户实现业务应用的透明和平滑迁移。

4.1.1 系统设计

POLARDB 采用共享存储架构，如图4所示。它由三层组成：作为统一访问门户的 PolarProxy、多节点数据库集群以及分布式共享文件系统 PolarFS。 PolarProxy 是一个具有自适应能力的分布式无状态代理集群。

它集成了多个计算节点的资源，为应用程序提供统一的访问门户。其动态扩展能力支持节点的灵活增加和减少。

POLARDB中的数据库节点分为两种类型，即一个 primary 节点和多个 read-only（只读节点）。主节点可处理读取和写入查询，而只读节点仅处理读取查询。主节点和只读节点共享重做日志文件和数据文件，这些文件由 PolarFS（第4.1.2节）管理，这是一个具有超低延迟、高吞吐量和高可用性的分布式文件系统。

这种架构具有多个显著优势。首先，计算和存储资源解耦。计算和存储节点可以使用不同类型的服务器硬件，并且可以分别进行定制。例如，计算节点不再需要考虑内存大小与磁盘容量的比例，该比例高度依赖于应用场景且难以预测。其次，它突破了单节点数据库（如 MySQL、PostgreSQL）的限制。存储节点上的磁盘构成一个统一的存储池，从而降低了碎片化、使用不均衡和空间浪费的风险。存储集群的容量和吞吐量可以透明地横向扩展。POLARDB 能够提供 100TB 的存储容量，并实现每节点 100 万每秒查询数。第三，由于所有数据都存储在存储集群上，计算节点上没有本地持久状态，使得数据库迁移更加容易和快速。此外，由于 PolarFS 提供的数据复制和其他高可用性功能，数据可靠性也得以提升。

除了POLARDB之外，其他云数据库服务也可以从这种架构中受益。首先，数据库可以基于虚拟化技术（如Xen [3],、KVM [13]或Docker [20]）构建在一个更安全且易于扩展的环境中。其次，由于后端存储集群提供了快速I/O、数据共享和快照功能，数据库的一些关键特性（如多个只读实例和检查点）可以轻松实现。

4.1.2 PolarFS 和 PolarStore

数据存储技术正在快速变化，当前的云平台难以充分利用 RDMA和NVMe SSD等新兴硬件标准。例如，一些广泛使用的开源分布式文件系统（如HDFS[4]和Ceph[31],）被发现其延迟远高于本地磁盘。当使用最新的PCIe SSD时，性能差距甚至可能达到几个数量级。在相同CPU和内存配置下，像 MySQL这样的关系型数据库直接运行于这些分布式存储上的性能，明显低于运行于本地PCIe SSD上的情况。

为此，我们构建了PolarFS [5]作为POLARDB的共享存储层。它是一种基于PolarStore（一种基于RDMA网络的共享分布式存储）构建的分布式文件系统，通过以下机制提供超低延迟、高吞吐量和高可用性。首先，PolarFS充分利用 RDMA和NVMe SSD等新兴硬件，在用户空间实现轻量级网络栈和I/O栈，避免陷入内核并处理内核锁。其次，PolarFS 提供类POSIX文件系统API，旨在将其编译进数据库进程，以替代操作系统提供的文件系统接口，从而使整个I/O路径保持在用户空间。第三，PolarFS的数据平面I/O模型也经过设计，在关键数据路径上消除锁并避免上下文切换。所有不必要的内存拷贝均被消除，同时广泛利用RDMA在主存与RDMA网卡/ NVMe磁盘之间传输数据。凭借这些特性，PolarFS的端到端延迟已大幅降低，接近SSD上的本地文件系统的延迟水平。

由于在大型 POLARDB 集群中节点故障较为常见，因此需要一种共识协议来确保所有已提交的修改在极端情况下也不会丢失。副本应始终保持一致并达到比特级相同。在 PolarFS 中，我们最初使用了 Raft [23], ——Paxos 系列的一种变体 [17, 16],，它更容易实现且被广泛使用被许多分布式系统采用。然而，在应用 Raft 时，我们发现它严重阻碍了 PolarFS 的 I/O 可扩展性，而 PolarFS 使用的是低延迟的 NVMe SSD 和 RDMA（其延迟在几十微秒级别）。因此，我们开发了 ParallelRaft，一种基于 Raft 的增强型共识协议，该协议允许日志的乱序确认、提交和应用，同时使 PolarFS 保持传统的 I/O 语义。通过该协议，并行 I/O 并发性得到了显著提升。

总之，PolarFS 通过以下特性支持 POLARDB：（1）PolarFS 可以将文件元数据的修改（例如文件截断或扩展、文件创建或删除）从主节点同步到只读节点，使得所有更改对只读节点都可见。（2）PolarFS 确保对文件元数据的并发修改被串行化，从而保证文件系统本身在所有数据库节点上保持一致。（3）在网络分区的情况下，两个或多个节点可能同时作为主节点并发写入共享文件。PolarFS 可以确保仅真正的主节点能成功提供服务，防止数据损坏。更多技术细节请参见 [5]。

4.2 POLARDB‐X：分布式 OLTP 数据库

POLARDB最多可扩展至数十个节点（受限于底层 RDMA网络），但对于双十一购物节这类涉及海量数据和事务的高并发工作负载而言，仍显不足。因此，我们在 POLARDB基础上进行了扩展，构建了POLARDB‐X——一种基于无共享架构的分布式OLTP数据库，以实现水平扩展，并融合了共享存储与无共享架构。相较于在每个分片上使用单个节点实例的标准无共享架构，该设计的优势在于：每个分片现在都能借助共享存储架构带来的纵向扩展能力，存储和处理更多的数据与事务。因此，在相同的数据量和/或事务处理需求下，该混合架构所需的分片数量远少于标准无共享系统；这反过来降低了发生复杂且高成本的分布式事务处理和分布式提交的可能性。最终，该系统能够在海量数据上支持高并发事务，并确保跨可用区和跨区域的事务一致性。

通过并行paxos协议X‐Paxos。

4.2.1 系统设计

图5展示了POLARDB‐X的架构，其中关系数据被划分到多个POLARDB实例中，并由分布式关系型数据库服务（ DRDS）进行管理。DRDS接收SQL查询或事务，解析并优化其执行计划，最终将其路由到相应的POLARDB实例进行执行。如前所述，每个POLARDB实例包含一个主节点和多个只读节点。每个读取节点作为主节点的副本，共享位于PolarFS上的同一存储，而PolarFS则建立在阿里巴巴的块存储系统 PolarStore之上。在POLARDB节点内部，包含一个用于执行来自DRDS的查询计划的计划执行器、一个用于事务处理的事务服务，以及阿里巴巴基于LSM‐tree的OLTP存储引擎X‐引擎。

4.2.2 X-引擎

我们发现，在阿里巴巴及我们的大型企业客户处理此类事务时，必须应对三个关键挑战：（1） The tsunami problem-随着大型销售和促销活动的启动（例如，在阿里巴巴双11全球购物节期间事务量激增了122倍），事务量急剧增加，给底层数据库带来了巨大压力。（2） The flood discharge problem-大量热记录容易使系统缓冲区过载，如果缓冲区无法快速刷写，将阻塞后续事务。（3） The fast moving current problem-由于大量持续时间较短的促销活动，记录的“温度”（即热、温、冷）频繁快速变化，导致缓存命中率大幅下降。

我们构建了X‐引擎 [10] 来应对阿里巴巴电子商务平台所面临的上述挑战，因为事务处理性能的很大部分取决于数据在存储中的持久化和读取效率。X‐引擎通过利用多核处理器中的线程级并行（TLP），在主存中处理大多数请求，将写入与事务解耦以实现异步化，并将长写入路径分解为流水线中的多个阶段，从而提升整体吞吐量。为解决泄洪问题，X‐引擎采用分层存储方法，在不同层级之间移动记录，借助优化的LSM树结构 [22, 25] 和高效的合并算法。我们还在合并过程中应用了FPGA卸载技术。最后，为应对急流问题，我们引入了一种多版本元数据索引，采用写时复制方式更新，以加速分层存储中无论数据温度如何的点查询。

图6展示了X‐引擎的架构。X‐引擎将每个表划分为多个子表，并为每个子表维护一个LSM树、相关的元快照和索引。每个数据库实例包含一个重做日志。每个LSM树由驻留在主存中的 hot datatier和驻留在NVM/SSD/HDD中的 warm/cold data tier组成（这些存储介质进一步划分为不同层级），其中热、温、冷表示数据温度，代表应放置在相应层的数据的理想访问频率。热数据层包含一个 active memtable和多个 immutable memtables（存储最近插入记录的跳跃表） 和 caches用于缓存热记录。温/冷数据层以树状结构组织数据，树的每一层存储一个有序序列的 extents。扩展区将记录块及其关联的过滤器和索引打包在一起。

X‐引擎利用重做日志、元快照和索引来支持事务处理中的多版本并发控制（MVCC）。每个 metasnapshot都有一个 metadataindex，用于跟踪快照中所有内存表以及树各层级中的扩展区。树的一个或多个相邻层级构成一个存储层，分别存储在NVM、固态硬盘和机械硬盘上。X‐引擎中的每个子表都有其独立的热数据、温数据和冷数据层（即LSM树），以行式存储格式存储记录。我们设计了多版本内存表来存储不同版本的记录，以支持MVCC。在磁盘上，元数据索引跟踪存储在数据区段中所有记录版本的信息。更多技术细节可参见 [10]。

4.3 分析型数据库：实时OLAP数据仓库

分析型数据库是一款为高并发、低延迟和PB级实时分析查询而设计的实时OLAP数据库系统。它已从最少3个节点扩展到最多 2000+台物理机器，并在阿里云上作为数据库服务提供。该系统服务于来自电子商务、金融科技、物流、公共交通、气象分析、娱乐等多个行业的企业客户，以及阿里巴巴集团内部的业务运营。

近期的研究 [28, 14, 15, 32, 11] 已经将设计 OLAP 系统的主要挑战总结为实现低查询延迟、数据时效性、灵活性、低成本、高可扩展性和可用性。与这些研究相比，我们应用程序场景中的大规模分析型工作负载使分析型数据库达到了更大的规模：10PB + 数据、数十万张表和万亿行数据，这对分析型数据库的设计与实现带来了显著挑战：1）如今的用户面临比以往更加复杂的分析场景，但对低查询延迟仍有很高的期望。尽管来自不同应用程序的查询多种多样且复杂，但通常无法容忍耗时较长的查询。 2）新兴复杂分析往往需要结合多种类型的查询和数据。超过一半用户的数据显示为复杂数据类型，例如文本、JSON字符串或向量。一个实用的数据库应能够高效支持针对具有复杂数据类型的异构数据的查询。 3）在处理低延迟实时查询的同时，系统还需要每秒处理数千万个在线写入请求。传统的在同一处理路径中进行读取和写入的设计已不再适用于此场景。必须精心设计，以在查询延迟、写入吞吐量和数据可见性之间取得平衡。

为应对这些挑战，我们通过几项创新设计构建了分析型数据库。首先，分析型数据库嵌入了一个高效且有效的索引引擎。在此引擎中，索引被构建on all columns in each table以显著提升即席复杂查询的性能。我们进一步提出了一种基于运行时过滤率的索引路径选择机制，以避免因索引滥用导致的性能下降。由于在关键路径中更新大型索引的成本极高，索引会在非高峰时段异步构建。我们还维护了一个轻量级排序索引，以尽量减少异步索引构建对涉及增量数据（即在当前轮次索引构建开始后写入的数据）查询的影响。

其次，我们设计了底层存储布局，以支持结构化数据及其他复杂类型数据的混合行列存储。特别是，我们利用快速的顺序磁盘IO，使其在OLAP风格或点查工作负载下的开销均可接受。我们还在存储（包括索引）中引入了复杂数据类型，以提供对资源（如JSON、向量、文本）与结构化数据一同进行搜索的能力。

第三，为了同时支持高吞吐量写入和低延迟查询，我们的系统采用读写分离的架构，即由写入节点和读取节点分别处理写入和读取请求。这两类节点相互隔离，因而可以独立扩展。具体而言，写入节点将写入请求持久化到盘古（阿里云上的可靠分布式存储）。为了在服务查询时确保数据时效性，在读取节点上应用了版本验证机制，使得写入节点上已完成的写入操作对读取可见。

第四，为了进一步提高查询延迟和并发性，我们增强了 AnalyticDB中的优化器和执行引擎，以充分利用我们的存储和索引的优势。具体而言，我们提出了一种感知存储的SQL优化机制，能够根据存储特性生成最优执行计划，以及一种用于基于成本的优化器中基数估计的高效实时采样技术。此外，我们设计了一种高性能用于混合存储的向量化执行引擎，可提高计算密集型分析查询的效率。

图7展示了系统架构。分析型数据库主要包括三种类型的节点，即协调器、写入节点和读取节点。 coordinator通过客户端连接收集请求（包括写入和查询），并将其分发到相应的写入节点和读取节点。 writenodes负责处理写入操作（如插入、删除、更新），并将刷写SQL语句持久化到盘古。Read nodes负责处理查询操作（如选择）。通过这种方式，写入节点和读取节点相互解耦。伏羲（阿里云上的资源管理器和作业调度器）利用这些节点中的可用资源，为异步任务执行提供计算工作进程。此外，分析型数据库提供了一个运行在计算工作进程上的通用流水线模式执行引擎。数据以列块为单位从存储层流经系统到达客户端。所有数据处理均在内存中进行，并通过网络在不同阶段之间流水线化。该流水线工作流使分析型数据库能够以高吞吐量和低延迟响应用户的复杂查询。更多技术细节可参见[33]。

4.4 SDDP：自动驾驶数据库平台

为了管理阿里云上的大量数据库实例，我们构建了一个自治的数据库管理平台，称为SDDP（自动驾驶数据库平台）。该平台从所有运行中的数据库实例收集实时统计信息，并利用机器学习和统计方法对实例进行调优和资源配置。

4.4.1 系统设计

图8展示了SDDP架构。混合云数据库管理（HDM）层从数据库实例中收集SQL语句和指标，并将其存储在时序数据库（TSDB）中。同时，HDM检测数据库状态，并将这些信息同步给控制器。数据库状态通常由DDL操作更改。例如，我们可以使用ALTER TABLE t1 HOTCOLD= ‘SMART’将表设置为SMART模式，以自动分离冷热数据（第4.4.3节）。HDM还指派控制器来驱动机器学习任务，如参数调优（第4.4.2节）、资源调度和异常检测。控制器将这些任务调度至模型训练平台（MTP）。MTP 从时序数据库中获取数据，包括 SQL 和指标，并使用不同的模块完成相应的任务。结果将通过控制器传回 HDM 并应用于数据库实例。

4.4.2 缓冲区大小调优

缓冲池是OLTP数据库的关键资源，作为数据缓存空间以确保理想的系统性能。对拥有超过10,000个实例的阿里巴巴 OLTP数据库集群进行的实证研究表明，缓冲池平均消耗每个实例98%的内存空间。现有的缓冲池配置几乎完全基于数据库管理员（DBA）的经验，通常采用固定的推荐值。这种手动过程既不高效也不有效，对于大型云集群尤其不可行，特别是当各个数据库实例的工作负载可能动态变化时。

为此，我们构建了iBTune [27], individualized buffer tuning，可在不依赖数据库管理员设定预定义级别的情况下，自动减小任意单个数据库实例的缓冲区大小，同时仍保持其响应时间的服务质量。我们利用缺失率与缓冲池大小之间的关系来优化内存分配。我们的模型借助相似实例的信息，同时设计了一种新颖的成对深度神经网络，通过使用在实例对上测量得到的特征来预测响应时间的上界。截至目前， iBTune已部署于SDDP，并应用于超过10,000个数据库实例，成功将内存消耗减少了超过17%（≥ 27TB），同时仍满足各类业务应用所需的服务质量。

图9展示了iBTune的架构和工作流概览。系统包含四个关键组件：数据收集、数据处理、决策和执行。iBTune的工作流形成一个闭环，因为数据首先从DBMS内核中收集，经过处理并用于训练，然后将生成的模型再次应用于DBMS。在 data collection中，我们使用定制代理从DBMS收集各种数据库指标和日志，收集的指标超过1,000个。代理位于DBMS外部，以避免对DBMS内核造成不必要的性能开销。所有指标和日志均以每秒一粒度进行收集，并输入到消息队列中。在 data processing中，流处理系统从消息队列读取数据，并执行一定的数据处理/标准化操作例如归一化、聚合和日志转换。处理后的指标和日志被存储在分布式数据存储中，用于分析和模型训练。在decision making中，我们提出了一种预测RT并计算新的BP（缓冲池）大小的新方法。如果预测的RT满足要求，则将计算出的新BP大小发送到 execution组件，该组件包含一个规划器和一个调度器。为了处理大量数据库实例， action planner旨在为数以万计的动作生成全局高效且无冲突的执行计划。它包括不同动作类别之间的优先级设置、同一实例的动作合并、动作冲突检测与解决、金丝雀执行策略等。最终输出多个动作序列到 action scheduler 。更多技术细节可参见[27]。

4.4.3 其他自治的场景

除了缓冲区大小调优之外，我们还探索了其他自主式设计，例如慢SQL优化、空间缩减、冷热分离、机器学习优化器、故障检测与恢复。以冷热分离为例，X‐引擎中的层级（第 4.2.2节）通过数据温度（扩展区）进行区分。扩展区的温度由其在最近时间窗口内的访问频率计算得出。当执行合并操作时，X‐引擎根据阈值指定的数量（例如500个扩展区）选择最冷的扩展区，并将这些扩展区推送到更深层进行合并。通过这种方式，X‐引擎将温数据保留在上层，而冷数据保留在更深层。但该方法难以有效应对动态工作负载。例如，当某个扩展区当前的访问频率较低时，该算法会将其视为冷数据，但它可能在不久的将来变为热数据。为此，我们研究了基于机器学习的算法来识别扩展区的合适温度。其核心思路是：除了扩展区粒度外，我们还使用行级（记录）粒度来推断温度（冷/热）。如果一条记录在最近时间窗口内从未被访问过，则被识别为冷数据；否则被视为温数据。因此，温度识别被转化为一个二分类问题，可通过分类模型（如随机森林或基于神经网络的方法）来解决。

5. 应用与操作

在阿里云上运行的数据库实例已接近五十万个，支持阿里巴巴集团内部业务运营以及外部客户业务应用。通过利用我们的云原生数据库系统，我们已成功服务于大量复杂的应用场景。

POLARDB 。POLARDB在阿里云上实现了快速增长的用户规模，服务于金融科技、游戏和娱乐、教育以及多媒体等多个行业领域的众多领先企业。许多应用程序由于其自建数据库支持的事务处理速率有限，选择迁移到POLARDB。例如，某个应用程序在高峰期遇到MySQL实例的延迟增加以及频繁的事务失败问题。POLARDB帮助将所有事务延迟控制在1秒以内，并将峰值吞吐量提升 3×。此外，单个POLARDB实例能够实现与5节点复制的MySQL集群相当的查询性能，同时减少了对经验丰富的数据库管理员（DBA）的需求。在大多数情况下，它可使数据库的总拥有成本（TCO）降低50‐80%。

POLARDB-X 。POLARDB‐X 已被应用于支撑阿里巴巴众多对性能敏感且对成本敏感的业务。例如，在 2018 年双 11全球购物节开始时，我们处理了 122× 的事务增长，每秒最高处理 491,000 笔销售事务，相当于每秒超过 7,000 万次数据库事务。为此，已在线部署了超过 2,000 个 POLARDB‐X 节点。随着 GMV（商品交易总额）快速增长，OLTP数据库 的管理成本以及底层服务器的维护成本不断攀升，已成为阿里巴巴面临的主要挑战。为了降低此类成本，我们已将许多阿里巴巴业务中的 MySQL 替换为 POLARDB‐X，在使用降配硬件（例如更少的 CPU核心 和存储容量）的情况下，仍能维持相同的 QPS/TPS 水平。在许多情况下，我们成功将数据库的总体拥有成本降低了高达 50%。

分析型数据库 。分析型数据库已在阿里云上超过2,000个节点上运行。它为来自电子商务、金融科技、物流、公共交通和娱乐等多个业务领域的应用程序提供服务。基于分析型数据库，我们扩展了一套端到端解决方案，覆盖了从数据采集到数据可视化的整个分析流程。我们的客户能够无缝构建其在线分析服务，同时相比其他解决方案降低了总体成本。分析型数据库帮助应用程序更好地利用其数据：TB级数据的即时多维分析和商业探索可在毫秒内完成；用户可通过调用内置函数和模块定义并启动分析任务；在许多情况下，新采集数据的可视化端到端延迟已降低至一分钟以内；且客户无需进行任何手动操作来维护服务。

SDDP 。SDDP已在阿里巴巴用于管理数万个数据库实例。通过多个自治和智能模块的应用，我们成功节省了大量集群资源：SQL优化模块检测并优化了2740万条低效的SQL请求；空间优化模块释放了2.26PB的存储空间（例如，通过去碎片化以及删除无用的索引/表）；iBTune模块在保持服务质量的同时节省了27TB内存空间；全局工作负载调度模块将磁盘利用率从46%提升至63%。

6. 结论

云原生数据库系统是日益重要的研发课题。它为数据库学术界和产业界带来了诸多新的技术挑战，同时也开辟了许多新的机遇。本文分享了阿里巴巴在推进云原生数据库技术、构建支持阿里巴巴集团内外复杂且多样化业务运营的云原生数据库系统方面的经验与经验教训，这些系统基于阿里云构建。随着上云进程的快速发展，云原生数据库系统在未来将变得更加关键，并将为支持下一代云应用开辟崭新而令人振奋的研究方向和工程挑战。