生而不凡：PolarDB将云原生进行到底
杨辛军（Jimmy Yang）
阿里巴巴集团研究员
PolarDB for MySQL产品部负责人
今年是PolarDB诞生5周年，经过5年的快速发展，PolarDB线上运行核数突破500,000核，服务上万家商户，逐步成为了一个成功的商业数据库。
与 AWS Aurora 和Google AlloyDB 类似，PolarDB是阿里云基于 MySQL与PG开发的升级版云原生数据库，实现了对MySQL与PG的完全兼容，支持MySQL/PG的无缝迁入和迁出。另一方面，PolarDB一直注重于云原生数据库的演进，在架构层面进行了大量的改进。PolarDB拥有业界最为高效和稳定的物理复制能力，保证集群内各节点间数据高效同步，以及大压力场景下全球部署的全球数据库数据的秒级复制。同时，PolarDB充分利用新硬件的新特性，赋能高效的计算存储分离架构，是业内首批大规模使用Intel Optane和RDMA的云数据库。近年来PolarDB仍不断在云原生方面发力，例如在业界首次提出三层分离架构，在计算存储分离的基础上，进一步开发了分布式内存池，做到计算，内存，存储三层分离。将共享资源数据库的弹性能力和资源利用能力发挥到极致。PolarDB有相当多的一部分的能力和研究是领先于业界的，我们每年都会在数据库顶会上发表论文，与学术届/工业界同行们分享我们研究和商业化成果。
上图为PolarDB最新的架构图，PolarDB 后续将坚持一体化和模块化建设。
PolarDB在计算存储分离以及物理复制方面已经非常成熟，因此逐渐开始往另一层次发展。之前我们支持读写节点和只读节点两种计算节点。通过过去几年的不断努力，今年我们发布了多个新的计算节点，包括HTAP节点、X-engine节点、多写节点、AI节点等等。这些计算节点可以进行自由搭配和转换，节点也可自动升配和降配，以适配客户需要的应用场景。通过这些能力，PolarDB真正实现了水平与垂直两个方向的弹性伸缩（Scale out & Scale up）。同时，PolarDB不但可以实现计算节点自由搭配，我们还通过三层分离架构支持了分布式内存池和分布式存储池，提供资源的极致共享和弹性。同时，这些节点可以如同“乐高积木”般自由搭配，可以搭建出简单的小屋或者豪华大宅，满足各种客户的不同需求。
PolarDB是共享资源的云原生数据库，对资源硬件的能力和先进性非常关注。我们充分利用新硬件实现软硬一体化，将硬件的红利分享给用户。
今年，PolarDB实现了两种硬件层面的升级。其一为SmartSSD，它在SSD存储设备上搭载了FPGA芯片，并通过这些专用芯片实现了数据的透明压缩，以及数据在SSD上的精细化调度和资源回收，实现了全栈2.0-3.0的压缩比。同时，如上图左下角所示，依赖于强悍的硬件压缩能力，Smart-SSD压缩操作对整体读写延迟的影响非常小，相比于普通/高性能云盘继续保持着相当大的性能优势。此外，PolarDB通过数据压缩能力可以将存储售价降低50%，让利给用户。在后续的演进中，新一代的SmartSSD还可以实现对数据的高效加解密操作，PolarDB 将利用该能力提供ON-SSD数据的全加密保证。
另一个硬件升级是PolarDB引进了100G RDMA 网络。对于PolarDB而言，RDMA 网络是把各个节点耦合起来的重要部件，是“乐高”上节点耦合的“触点”。我们之前一直使用25G RDMA，升级到更大带宽的100G RDMA后，我们能够把更多的信息直接通过高速网络更快地传输到其他节点。具体的一个例子是PolarDB的“高性能全局强一致”功能。 大部分云数据库，比如AWS Aurora只支持跨节点查询的最终一致性，而不支持read-after-write 的强一致性。 也就是说，当用户使用这些数据库，数据写入到读写主节点（RW）后，如果马上从从节点（RO） 读，由于写复制的延迟问题，读节点不一定能够读到最新的数据。 要做到全局一致性， 我们首先需要要保证数据的快速复制， 其次要保证主从节点同步更多的事务和时间戳信息。
PolarDB之前通过PolarStore共享存储进行日志的同步， 现在因为有了更大带宽的网络，可以直接通过RDMA网络同步日志信息，大大减少了数据复制延迟。 另一方面，PolarDB通过细粒度的事务跟踪系统，通过RDMA在节点间进行了大量事务和时间戳信息的快速同步，在最小信息量同步的情况下保证了从节点上的read-after-write一致性读能力，这大大提高了RO节点的利用率，大幅提升全局一致性读的性能，也提供给用户更丰富更可靠的使用场景。
PolarDB今年一个最重要的发布是推出了HTAP功能。 通过In-Memory Column Index（IMCI），PolarDB 开始支持列存数据格式以及轻量的分析能力。 PolarDB在产生行存日志的同时，对选中的列产生定量的列存日志，并通过高效的物理复制能力，在HTAP 节点恢复出列存数据， 便于HTAP节点内置的高效列存执行引擎进行复杂的分析查询。和其他产品（例如MySQL Heatwave）不同， PolarDB具有非常高效的物理复制能力，并且保留了大量事务信息，节点间的延迟非常低，做到了真正的实时查询。另外，其他竞对产品同步往往需要打开binlog，这个直接影响了主节点性能（达20-40%），而PolarDB 的物理复制对主节点性能没有直接影响。同时，PolarDB列存数据还自带事务信息，能够支持行列存的一致性查询。用户只需要像使用普通MySQL一样，就能享受到快速列存数据查询带来的性能提升。这个系统真正一站式地满足了客户的OLTP及OLAP需求。
值得注意的是，PolarDB IMCI 的性能也相当优秀，TPCH 100G 性能和友商A（Aurora）相比提升了近100倍， 和友商B（OB） 相比提升了近25倍， 和友商C （TiDB/TiFlash） 的列存查询相比提升了近3倍。
在分析查询方面，PolarDB 不但在列存上面发力，在行存的查询加速方面也有长足的进步。PolarDB的单节点并行查询已经远远领先于一些竞对，包括AWS Aurora。 今年PolarDB 更上一层楼，发布了跨节点弹性并行查询功能（elastic PQ）。 ePQ的发布进一步提升了性能的水平扩展性，拉开和其他MySQL系列产品在分析能力方面的差距。
上面左图显示了ePQ 通过4个32核节点的并行查询结果，结果显示整体执行性能较MySQL提升了60多倍，单条执行性能最大提升150倍。右图显示了ePQ针对TPCH 1TB多节点查询的性能达到了线形提升的效果。 同时另外一个例子是针对60亿+大表的分组聚集，ePQ将执行时间从单线程的8小时缩短到小于60s （16节点 16 X 16 = 256 并行）。
PolarDB for MySQL今年的另一个重磅商业化发布是“库表级多写”。
PolarDB之前一直是一写多读架构：一个集群只有一个读写主节点（RW）， 但可以有1到15个读节点，所以在读能力上有足够的水平扩展能力。但是在一些场景下，用户希望PolarDB对写能力也有水平扩展能力，同时多个写节点之间可以提供一定的资源隔离能力。在这个需求下，我们支持了库表级多写，一个PolarDB可以有多个读写主节点。每个主节点管理多个库、表，但是每个表会“绑定”到一个主节点。 所有关于这个表的写操作都会被PolarDB Proxy 引导到它的读写主节点。相比share-nothing的分布式数据库，库表级多写的优势在于共享存储架构，每个节点都可以看见所有数据，因此，增加节点或减少节点时无需对数据进行跨节点迁移，拥有极佳的弹性能力。即使节点增减，数据也可以快速流动到不同节点，无需进行数据的重复迁移，实现秒级的横向扩展。
另外，它实现了主主互备的能力，每个节点都是其他节点的备节点，既是备节点也是主节点，这极大地提高了节点的利用率。普通的主备架构升级到“库表级多写”后，可以极大地降低数据库成本。
大家可能都比较熟悉Oracle RAC 架构下的行级多写能力，相比于RAC，库表级多写还是一个粗粒度的多写解决方案。因为要处理大量的数据多节点一致性问题，如何实现这类的行级多写能力并保证水平扩展性一直是工程上的巨大挑战。PolarDB 通过三层分离架构，借助全局内存池以及Polar Fusion 等组件成功地实现了行存多写下的事务、锁、缓存信息的全局协调，实现多个写节点的行级并发写入，突破了单点写入瓶颈。
上图为阿里云PolarDB 行级多写与AWSAurora Multi-Master 功能的性能对比。我们可以看到，Aurora MM在4个节点就开始频繁crash，无法完成多节点冲突写的测试。而PolarDB 在4节点冲突写下依然具有非常不错的扩展性。在无冲突写的场景，PolarDB行级多写可以scaling 到16个节点，而Aurora MM最多只支持4个节点，水平扩展性较差。上面右图是8节点的性能表现，PolarDB的性能遥遥领先于Aurora MM。
PolarDB的全球数据库上线2年以来，已经成为许多业务跨域灾备的首选方案。同时，PolarDB全球数据库利用独有的并行物理复制技术，其复制稳定性和速度都是全球领先的。在大压力场景下，PolarDB在任何机房写入的数据都可以保证在2秒内被全球部署的其它PolarDB读取。所以PolarDB也经常被用户用来满足全球数据复制和就近读的业务需求。PolarDB现在仅支持少量的全球写，写入的SQL会被Proxy转发到主region的主节点执行，存在一定的跨域延迟。 但是，很多用户希望PolarDB支持更强的全球就近写能力，数据可以进行多向同步，做到真正的跨域多读多写。基于物理复制技术的PolarDB表级多写技术的研发也接近尾声，在未来几个月内我们将上线这一就近写功能，满足更多客户的全球业务部署需求。
PolarDB 在今年1月上线了一个LSM tree（Log Structure Merge tree）架构的引擎：X-Engine。相比于传统基于B-tree架构的引擎（例如MySQL InnoDB）， LSM tree将压缩的块数据更高效地pack到SSTable file中，具备更高的压缩率。所以，PolarDB 的X-engine 作为一个高压缩引擎，可以帮助用户存储相对更“冷”的数据，从而节约存储成本。
上图显示了在集团业务场景（淘宝），用户使用X-Engine进行压缩后，实现了近3.5-7倍的压缩率。另外在写入性能方面，相较于PolarDB原生引擎，X-Engine性能略有降低但是比较相近。X-engine 是PolarDB 提供给用户降本增效的一个利器，PolarDB 支持“双”引擎同时在线，用户在使用高效的PolarDB default 引擎的同时，可以将相对“冷”的，不常用的数据迁移到X-engine上。
云数据库另一个重要特性是资源池化，用户希望PolarDB提供资源的弹性分配和按量付费功能。在PolarDB Serverless功能发布前，PolarDB 的存储PolarStore已经具备存储按需分配和按量付费能力。但是每个计算节点的CPU核数和内存容量是固定的。用户在业务压力增大时可以进行升配，但是需要用户手动触发。PolarDB Serverless提供了自动智能探测，以及更为迅速的CPU和memory变配能力，做到了单机秒级探测和无中断秒级弹升/降。另外，如果单机资源被占或者资源不足，PolarDB还可以通过链接保持、Hot BP等技术支持横向、跨节点弹升，近乎无感地增/减节点来适配用户需求。
上图可以看出，PolarDB Serverless能够根据压力（QPS）增加而自动提升PCU数量。压力停止后，PCU逐渐降低。左下角的图显示单节点规格达到上限后，可通过自动增加只读接节点来应对突发压力，提升集群性能。
自从诞生起，PolarDB一直在性能方面进行持续优化。过去一年以来，PolarDB通过针对云原生架构的全路径深度优化、高性能存储引擎优化以及高性能索引PolarIndex，单机性能实现了大幅提升，持续拉开和其他竞争对手的距离。
PolarDB在一些基础功能上也在持续演进。例如并行DDL通过一年的灰度，线上全面开启。在高并发场景下，并行DDL使得创建索引的速度提升了15-20倍，解决了多个客户在大表场景下的燃眉之急。例如某跨境金融客户，3TB近5亿行的大表因为业务压力一直加不上索引，使用了并行DDL后只花了不到20分钟时间。同时，我们正在实现Multi-VersionDictionary，可实现各种InstantDDL（例如修改字段类型/增删字段），无需通过全表的重建，通过Dictionary的改变秒级即可生效。
今年是降本增效的一年，大量用户希望PolarDB 能够协助他们降低成本。在这个场景下，PolarDB开始支持OSS 存储。为了更好的把数据转移到OSS，以及管理这些数据，PolarDB在分区表方面做了大量的工作。比如说interval range 分区表，可以按时间自动生成新的partition。一些老的分区可以自动老化到OSS等更廉价的存储。
今年是PolarDB的5周年，也是PolarDB的一个丰收年。PolarDB许多重磅功能经过过去几年的努力陆续得以实现和落地。我们希望这些能力能够给PolarDB的用户带来更多的选择，适配各种用户场景。 PolarDB 将继续坚持对MySQL/PG的全兼容，持续进行功能模块化，一个数据库多种形态的一体化，做精场景，服务各个行业的客户。我们将持续保证PolarDB的高性能和高稳定性，坚持降本增效，和客户一起迎接更多的挑战，成为客户云原生关系型数据库的首选！
