阿里云有15款数据库，为什么又造了POLARDB？

云计算

2014 年，AWS 发布了关系型数据库 Aurora，当时，数据库的演化正向内存和分布式发展，甚至RDBMS本身都受到了NoSQL的挑战。Aurora没有采用分布式的思路，而是用共享存储和读写分离的方式，在提高性能的同时解决了可扩展性问题，实现了对MySQL 100%的兼容，让传统互联网公司可以无痛迁移到云上，这让它成为云计算时代数据库的一个代表。

前天，阿里云宣布其自研的关系型数据库POLARDB开始公测，它采用了Aurora相同的思路，同时性能更强，达到单机100W QPS，成为阿里云已提供的15种数据库之外的另一款产品。

阿里为何要重新造轮子，这个新的POLARDB又有何不同？带着这些疑问， InfoQ 采访了阿里云研究员余锋（花名：褚霸）。

为何要自研POLARDB

褚霸表示，自研数据库的出发点来自刚需。自从棱镜门事件曝光后，国家开始注重信息产业的安全性，要求关键软件实现可控，数据库就在其中。作为云计算厂商，要想为更多的客户提供服务，必须要有自研数据库。

至于为什么选择Aurora这条路线，褚霸说：“ AWS 作为第一个吃螃蟹的人，是值得尊重的，阿里云作为追随者，有前人开路，会走的更踏实稳健。”

褚霸将阿里云的这些数据库产品比喻成自己的孩子们，这群孩子各有所长，无可替代。不过从采访过程中，可以看出他对POLARDB这个孩子是格外偏爱，寄予厚望。

POLARDB有哪些优异之处

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

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

众所周知，在传统数据库上做扩容、备份和迁移等操作，花费的时间和数据库的容量成正比，往往上TB的数据库容量加个只读副本就需要一到两天时间。POLARDB 的存储容量可以实现无缝扩展，不管数据量有多大，2分钟内即可实现只读副本扩容，1分钟内即可实现全量备份，为企业的快速业务发展提供了弹性扩展能力。

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

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

为什么 POLARDB 能做到 6 倍于 MySQL 的性能？

这里分别以存储性能、计算性能来进行解读诠释。

POLARDB 的存储引擎性能优化

1.持续释放硬件红利

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

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

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

2.旁路内核，榨干硬件能力

在 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 的用户态网络协议栈代替。

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

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

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

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

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

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

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

4.针对数据库加速的 Smart Storage

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

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

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

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

POLARDB 的计算引擎性能优化

1.使用共享存储物理复制

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

2.锁优化

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

3.日志提交优化

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

4.复制性能

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

5.读节点性能

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

POLARDB 的成本优化

1.存储资源池化

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

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

2.透明压缩

POLARDB 的存储节点除了对ibd文件提供1MB的原子写，消除 double write 的开销，还支持对 ibd 文件的数据块进行透明压缩，压缩率可以达到 2.4 倍，进一步降低了存储成本。
而传统数据库在 DB 内进行压缩的方案相比，存储节点实现透明压缩不消耗计算节点的CPU，不影响 DB 的性能，利用 QAT 卡进行加速，以及在 IO 路径上用 FPGA 进行加速。 POLARDB 的存储节点还支持快照去重（dedup）功能，数据库的相邻快照之间，如果页面没有发生修改，会链接到同一份只读页面上，物理上只会存储一份。

3.存储成本的只读实例

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

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

阿里巴巴集团整个数据库体系可以说是一直被业务追着跑步前进，一刻也没有停歇。无论是 IOE 架构的 Oracle 时代，还是 AliSQL 的分布式时代，以及轰轰烈烈充满各种争议的去 IOE 行为，阿里巴巴数据库团队一次又一次引领并推动了中国数据库产业的变革和发展。

数据库未来要怎么走？时间会给出答案

数据库领域目前出现了百花齐放的局面，很多大厂都推出了自己的数据库产品，甚至有不少都开源了出来。其中，完全兼容MySQL的POLARDB则是其中稳健派的代表。这些数据库，未来谁会独占鳌头？

风起于青萍之末，浪成于微澜之间。平稳的向前发展，是成就一切伟大的前提。今天，阿里云数据库既要适用于上百万中小企业对成本的要求，又要满足大型企业或金融机构乃至独角兽对数据量暴涨的需求，当谈及POLARDB的未来时，褚霸表示，阿里云的POLARDB团队也是在不断尝试，不断试错总结经验，未来无法预测，但阿里云数据库团队一定会脚踏实地的走好每一步，积跬步方能至千里。时间会给出答案。