POLARDB 是阿里云数据库团队研发的基于第三代云计算架构下的商用关系型云数据库产品，实现 100% 向下兼容 MySQL 5.6 的同时，支持单库容量扩展至上百 TB 以及计算引擎能力及存储能力的秒级扩展能力，对比 MySQL 有 6 倍性能提升及相对于商业数据库实现大幅度降低成本。（数据是2017年的，现在的性能肯定提升的更多）

首先，受益于第三代分布式共享存储架构，使 POLARDB 实现了计算节点（主要做 SQL 解析以及存储引擎计算的服务器）与存储节点（主要做数据块存储，数据库快照的服务器）的分离，提供了即时生效的可扩展能力和运维能力。

其次，与传统云数据库一个实例一份数据拷贝不同，POLARDB 同一个实例的所有节点（包括读写节点和只读节点）都实现访问存储节点上的同一份数据，使得 POLARDB 的数据备份耗时实现秒级响应。（备份时间与底层数据量无关）

最后，借助优秀的 RDMA 网络以及最新的块存储技术，实现服务器宕机后无需搬运数据重启进程即可服务，满足了互联网环境下企业对数据库服务器高可用的需求。

POLARDB 架构

引用 PolarDB 和 PolarStore 的设计师的话：

首先要向 AWS Aurora 的创新性致敬！Aurora 通过计算节点和存储节点分离，计算节点Scale up，存储节点 Scale out 的理念将公有云的关系数据库产品推向了一个新的高度。

在设计方法上，阿里云的 PolarDB 和 Aurora 走了不一样的路，归根结底是我们的出发点不同。AWS 的 RDS 一开始就是架设在它的虚拟机产品 EC2 之上的，使用的存储是云盘 EBS。 EC2 和 EBS 之间 通过网络通讯 ，因此 AWS 的团队认为 "网络成为数据库的瓶颈"，在 Aurora 的论文中，他们开篇就提出 "Instead, the bottleneck moves to the network between the database tier requesting I/Os and the storage tier that performs these I/Os." Aurora 设计于 12 到 13 年之际，当时网络主流是万兆网络，确实容易成为瓶颈。

而 PolarDB 是从 2015 年开始研发的，我们见证了 IDC 从万兆到 25Gb RDMA 网络的飞跃。因此我们非常大胆的判断，未来几年主机通过高速网络互联，其传输速率会和本地 PCIe 总线存储设备带宽打平，网络无论在延迟还是带宽上都会接近总线，因此不再成为高性能服务器的瓶颈。而恰恰是软件，过去基于内核提供的 syscall 开发的软件代码，才是拖慢系统的一环。Bottleneck resides in the software。

在架构上 Aurora 和 PolarDB 各有特色。我认为 PolarDB 的架构和技术更胜一筹。

(1) 现代云计算机型的演进和分化，计算机型向高主频，多 CPU，大内存的方向演进；存储机型向高密度，低功耗方向发展。机型的分化可以大大提高机器资源的使用率，降低 TCO。因此 PolarStore 中大量采用 OS-bypass 和 zero-copy 的技术来节约 CPU，降低处理单位 I/O 吞吐需要消耗的 CPU 资源，确保存储节点处理 I/O 请求的效率。而 Aurora 的存储节点需要大量 CPU 做 redolog 到 innodb page 的转换，存储节点的效率远不如 PolarStore。

(2) Aurora 架构的最大亮点是存储节点具有将 redolog 转换为 innodb page 的能力，这个改进看着很吸引眼球，事实上这个优化对关系数据库的性能提升很有限，性能瓶颈真的不在这里，反而会拖慢关键路径 redolog 落地的性能。在PolarDB 架构下，redolog 离线转换为 innodb page 的能力不难实现，但我们目前不认为这是高优先级要做的。

(3) Aurora 的存储多副本是通过 quorum 机制来实现的，Aurora 是六副本，也就是说，需要计算节点向六个存储节点分别写六次，这里使计算节点的网络开销又上去了，而且是发生在写 redolog 这种关键路径上。而 PolarDB 是采用基于 RDMA 实现的 ParallelRaft 技术来复制数据，计算节点只要写一次 I/O 请求到 PolarStore 的 Leader 节点，由 Leader 节点保证 quorum 写入其他节点，相当于多副本 replication 被 offload 到存储节点上。此外，在最终一致性上 Aurora 是用 Gossip 协议来兜底的，在完备程度上没有 PolarDB 使用的 ParallelRaft 算法有保证。

(4) Aurora 的改动手术切口太大，使得它很难后面持续跟进社区的新版本。这也是 AWS 几个数据库产品线的通病，例如 Redshift，如何吸收 PostgrelSQL 10 的变更是他们的开发团队很头疼的问题。对新版本做到与时俱进是云数据库的一个朴素需求。怎么设计这个刀口，达到 effect 和 cost 之间的平衡，是对架构师的考验。

补充：

亚马逊弹性计算云（EC2，Elastic Compute Cloud）是一个让使用者可以租用云端电脑运行所需应用的系统。EC2 借由提供 Web 服务的方式让使用者可以弹性地运行自己的 Amazon 机器映像档，使用者将可以在这个虚拟机器上运行任何自己想要的软件或应用程序。提供可调整的云计算能力。它旨在使开发者的网络规模计算变得更为容易。

Amazon Elastic Block Store (EBS) 是一种易于使用的高性能数据块存储服务，旨在与 Amazon Elastic Compute Cloud (EC2) 一起使用，适用于任何规模的吞吐量和事务密集型工作负载。Amazon EBS 上部署着各种各样的工作负载，例如关系数据库和非关系数据库、企业应用程序、容器化应用程序、大数据分析引擎、文件系统和媒体工作流。

POLARDB 的存储引擎性能优化

持续释放硬件红利

众所周知，关系型数据库是 IO 密集型 的应用，IO 性能的提高对数据库的性能提升至关重要。过去十年我们看到在数据库领域， SSD 替换 HDD 的过程给数据库数据处理的吞吐能力带来了数量级的提升。

POLARDB 采用了领先的硬件技术：包括使用 3DXpoint 存储介质的 Optane 存储卡、NVMe SSD 和 ROCE RDMA 网络。同时面向新硬件架构实现软硬一体优化：从数据库、文件系统到网络通讯协议、分布式存储系统和设备驱动，POLARDB 实现纵贯软件栈各层次的整个 IO 链条的深度优化。

为了将 3DXpoint 颗粒的高性能和 3D NAND 颗粒的低成本结合起来，POLARDB 创新的在软件层实现对高速的 Optane 卡和大容量高吞吐的 NVMe SSD 进行组合，实现一个名为混合存储层。既保证数据写入的低延迟、高吞吐、高 QoS，又使整体方案兼具较高的性价比。

旁路内核，榨干硬件能力

在 POLARDB 里，为了追求更高的性能、更低的延迟，阿里云数据库团队大胆的抛弃了Linux内核提供的各种机制（比如块设备、各种文件系统例如 ext4，以及 TCP/IP 协议栈和 socket 编程接口），而选择了另起炉灶。最终，POLARDB 实现了一整套在用户态运行的 IO 和网络协议栈。

POLARDB 用户态协议栈解决了内核 IO 协议栈慢的问题。用户程序在用户态直接通过 DMA 操作硬件设备，通过轮询的方式监听硬件设备完成 IO 事件，消除了上下文切换和中断的开销。用户程序还可以将 IO 处理线程和 CPU 进行一一映射，每个 IO 处理线程独占 CPU，相互之间处理不同的 IO 请求，绑定不同的 IO 设备硬件队列，一个 IO 请求生命周期从头到尾都在一个线程一颗 CPU 上处理，不需要锁进行互斥。这种技术实现最大化的和高速设备进行性能交互，实现一颗 CPU 达每秒约 20 万次 IO 处理的能力，并且保持线性的扩展能力，也就意味着 4 颗 CPU 可以达到每秒 80 万次 IO 处理的能力，在性能和经济型上远高于内核。

网络也是类似的情况。过去传统的以太网，网卡发一个报文到另一台机器，中间通过一跳交换机，大概需要一百到两百微秒。POLARDB 支持 ROCE 以太网，应用程序通过 RDMA 网络，直接将本机的内存写入另一台机器的内存地址，或者从另一台机器的内存读一块数据到本机，中间的通讯协议编解码、重传机制都由 RDMA 网卡来完成，不需要 CPU 参与。使性能获得极大提升，传输一个 4k 大小报文只需要 6、7 微秒的时间。如同内核的 IO 协议栈跟不上高速存储设备能力，再一次的，内核的 TCP/IP 协议栈跟不上高速网络设备能力，被 POLARDB 的用户态网络协议栈代替。

硬件 DMA 和物理复制实现的数据库多副本

大家都知道关系型数据库的重要特性归纳起来是 "ACID"，其中 A 是原子性，C 是一致性，I 是隔离性，D 是持久性。

POLARDB 将从两个维度出发，从根本上改进多副本复制。一个是保证数据库 ACID 中的 D（Durable），把网络、存储硬件提供的 DMA 能力串起，用硬件通道高性能的把主库的日志数据持久化到三个存储节点的磁盘中；另一个是实现了高效的只读节点，在主库和只读节点之间通过物理复制同步数据，直接更新到只读节点的内存里。

POLARDB 实现日志数据持久化到三个存储节点的磁盘中。主库通过 RDMA 将日志数据发送到存储节点的内存中，存储节点之间再通过 RDMA 互相复制，每个存储节点用 SPDK 将数据写入 NVMe 接口的存储介质里，整个过程 CPU 不用访问被同步的数据块（Payload），实现数据零拷贝。

同时由 RDMA 网卡和 NVMe 控制器完成数据传输和持久化，CPU 仅做状态机的维护，在一致性协议的协调下，把网卡和存储卡两块硬件串起来，存储节点之间数据同步采用 ParallelRaft 协议，和 Raft 协议一样，决议在 leader 节点上是串行生成和提交的，但 ParallelRaft 协议可以允许主从之间乱序同步，简单的说，允许 follower 节点在漏掉若干条日志的情况先 commit 并 apply 后面过来的日志，并异步的去补之前漏掉的日志，数据同步的性能和稳定性都显著优于 Raft 协议。

POLARDB 在主库和只读实例之间的数据流上，放弃了基于 binlog 的逻辑复制，而是基于 innodb 的 redolog 实现了物理复制，从逻辑复制到物理复制对主库和从库性能带来的提升都非常明显。

在主库上，原本引擎需要和 binlog 做 XA 事务，事务要等到 binlog 和 redolog 同时写盘后才能返回，去掉 binlog 后，XA 事务可以去掉，事务的执行路径更短，IO 开销也更小。在从库上，redolog 由于是物理复制，仅需比对页面的 LSN 就可以决定是否回放，天然可以多线程执行，数据的正确性也更有保证，此外，POLARDB 的从库收到 redolog 后只需要更新缓存里的页面，并不需要写盘和 IO 操作，开销远低于传统多副本复制里的从库。

针对数据库加速的 Smart Storage

POLARDB 的存储节点针对数据库的 IO workload 进行了一些针对性的优化。

IO 优先级优化：POLARDB 在文件系统和存储节点两层都开了绿色通道，对 redolog 文件的更新进行优待处理，减少排队，提高 IO 的优先级。redolog 也从 512 对齐调整为 4k 对齐，对 SSD 性能更加友好。

double write 优化：POLARDB 存储节点原生支持 1MB 的原子写，因此可以安全关闭 double write ，从而节省了近一倍的 IO 开销。

group commit 优化：POLARDB 里一次 group commit 可以产生写入几百 KB 的单个大 IO。对于单个 SSD，延迟和 IO 的大小是呈线性的，而 POLARDB 从文件系统到存储节点都进行一系列优化来保证这种类型的 IO 能尽快刷下去，针对 redolog 文件进行条带化，将一个上百 KB 的大 IO 切割为一批 16KB 的较小 IO，分发到多个存储节点和不同的磁盘上去执行，进一步的降低关键 IO 路径的延迟。

POLARDB 的计算引擎性能优化

使用共享存储物理复制

由于 POLARDB 使用共享存储和物理复制，实例的备份恢复也做到完全依赖 redolog，因此去掉了 binlog。使得单个事务对 IO 的消耗减少，有效减少语句响应时间，提升吞吐量。同时避免了引擎需要与 binlog 做的 XA 事务逻辑，事务语句的执行路径更短。

锁优化

POLARDB 针对高并发场景，对引擎内部锁做了大量优化，比如把 latch 分解成粒度更小的锁，或者把 latch 改成引用计数的方式从而避免锁竞争，例如 Undo segment mutex， log system mutex 等等。PolarDB 还把部分热点的数据结构改成了 Lock Free 的结构，例如 Server 层的 MDL 锁。

日志提交优化

Redolog 的顺序写性能对数据库性能的影响很大，为了减少 Redolog 切换时对性能的影响，我们后台采用类似 fallocate 的方式预先分配日志文件，此外，现代的 SSD 硬盘很多都是 4K 对齐，而 MySQL 代码还是按照早期磁盘 512 字节对齐的方式刷日志的，这样会导致磁盘做很多不必要的读操作，不能发挥出 SSD 盘的性能，我们在这方面也做了优化。我们对日志提交时 Group Commit 进行优化，同时采用 Double RedoLog Buffer 提升并行度。

复制性能

POLARDB 中物理复制的性能至关重要，我们不仅通过基于数据页维度的并行提高了性能，还对复制中的必要流程进行了优化，例如在 MTR 日志中增加了一个长度字段，从而减少了日志 Parse 阶段的 CPU 开销，这个简单的优化就能减少 60% 的日志解析时间。我们还通过复用 Dummy Index 的内存数据结构，减少了其在 malloc / free 上的开销，进一步提高复制性能。

读节点性能

POLARDB 的 Replica 节点，日志目前是一批一批应用的，因此当新的一批日志被应用之前，Replica 上的读请求不需要重复创建新的 ReadView，可以使用上次缓存下来的。这个优化也能提高 Replica 上的读性能。

如何降低成本

存储资源池化

POLARDB 采用了一种计算和存储分离的架构，DB 运行在计算节点，计算节点组成了一个计算资源池，数据都放在存储节点上，存储节点组成了一个存储资源池。如果 CPU 和内存不够了，就扩充计算资源池，如果容量或者 IOPS 不够了，就扩充存储资源池，两个池子都是按需扩容。而且存储节点和计算节点可以分别向两个方向优化，存储节点会选择低配的 CPU 和内存，提高存储密度，而计算节点可以选择小容量、低配的 SSD 作为操作系统和日志盘，上多路服务器增加 CPU 的核数。

而传统的数据库部署模型则是一种烟囱模型，一台主机既跑数据库又存数据，这带来两个问题。一个是机型难以选择，CPU 和磁盘的配比主要取决于实际业务的需求，很难提前找到最优比例。第二是磁盘碎片问题，一个生产集群里，总有部分机器磁盘使用率是很低的，有的还不到 10%，但出于业务稳定性要求，会要求独占主机的 CPU，这些机器上的 SSD 其实是被浪费的。通过存储资源池化，这两个问题都能得到解决，SSD 的利用率得到提高，成本自然也降低下来。

透明压缩

POLARDB 的存储节点除了对 ibd 文件提供 1MB 的原子写，消除 double write 的开销，还支持对 ibd 文件的数据块进行透明压缩，压缩率可以达到 2.4 倍，进一步降低了存储成本。

而传统数据库在 DB 内进行压缩的方案相比，存储节点实现透明压缩不消耗计算节点的 CPU，不影响 DB 的性能，利用 QAT 卡进行加速，以及在 IO 路径上用 FPGA 进行加速。POLARDB 的存储节点还支持快照去重（dedup）功能，数据库的相邻快照之间，如果页面没有发生修改，会链接到同一份只读页面上，物理上只会存储一份。

0 存储成本的只读实例

传统数据库做只读实例，实施一写多读方案，是通过搭建只读副本的方案，先拷贝一个最近的全量备份恢复一个临时实例，再让这个临时实例连接主库或者其他 binlog 源同步增量数据，增量追上后，把这个临时实例加到线上升级为一个只读副本。这种方法一个是耗时，搭建一个只读实例需要的时间与数据量成正比；另一方面也很昂贵，需要增加一份存储成本，比如用户购买一个主实例加上五个只读实例，需要付 7~8 份存储的钱（ 7 份还是 8 份取决于主实例是两副本还是三副本）。

而在 PolarDB 架构中，这两个问题都得到解决，一方面新增只读实例不需要拷贝数据，不管数据量有多大都可以在 2 分钟内创建出来；另一方面，主实例和只读实例共享同一份存储资源，通过这种架构去增加只读副本，可以做到零新增存储成本，用户只需要支付只读实例消耗的 CPU 和内存的费用。

参考：Cloud-Native Database Systems at Alibaba: Opportunities and Challenges https://www.zhihu.com/question/63987114/answer/244520478
https://yq.aliyun.com/articles/214367