我，PolarDB云原生数据库，5年来实现这些重磅技术创新

78 阅读 0 评论 52 点赞

我是靠谱客的博主长情草丛，最近开发中收集的这篇文章主要介绍我，PolarDB云原生数据库，5年来实现这些重磅技术创新，觉得挺不错的，现在分享给大家，希望可以做个参考。

概述

数据库与芯片、操作系统并列为全球信息技术三大件，也是企业IT系统必不可少的核心技术，同时也是一切数字处理、计算力和智能化的基石。

上世纪70年代，E.F.Codd 发表了一篇划时代的论文“A Relational Model of Data for Large Shared Data Banks”。从这篇论文开始，关系型数据库软件革命的序幕被拉开了。80 年代初期支持 SQL 的商用关系型数据库Oracle和 DB2相继面市，以及 90 年代诞生的 SQL Server，开源的MySQL、PostgreSQL等都是关系型数据库成功的代表。

时至今日，随着全球不同类型数据的指数级增长，市场上涌现出越来越多的新型数据库，然而关系型数据库仍然占据主导地位。根据市场研究机构IDC的最新统计数据显示，关系型在全球数据库中占据约80%的份额。

关系型数据库经受住时间的考验，为全世界用户的钟爱，最主要的原因之一就是关系型数据库采用了 SQL 标准，这种高级的非过程化编程接口语言，将计算机科学和易于人类理解认知的数据管理方式完美的衔接在了一起。到今天，这种编程语言还没有更加完美的替代品。

数十年来，关系型数据库都应用在以IOE为代表的软硬件紧耦合的技术架构环境之下，但是今天，关系型数据库面对着云计算是承载工作流的主要环境的巨大改变。

这种使用环境的变革性迁移之下，客户对关系型数据库也提出了新的要求，比如可以支持更大的存储、弹性扩缩容上更灵活，甚至数据库可以实现“自动驾驶”。

阿里云的数据库团队认识到，如果基于传统关系型数据库的架构进行小修小补，很难解决这些客户提出的问题，必须从根本上演进云上的关系型数据库架构，做一个全新的云原生关系型数据库。

PolarDB云原生关系型数据库也就此诞生。

过去5年，阿里云针对PolarDB进行了诸多创新，通过采用存储计算分离、软硬一体化设计，PolarDB实现成本仅为传统商业数据库的十分之一。所实现的计算、内存与存储资源的“三层解耦”架构、多主多写、基于IMCI（内存列存索引）的HTAP、Serverless等功能已是全球首创或业内领先的技术。

从PolarDB发布以来，它在技术和商业化上都获得了迅猛发展，如今已经成为阿里云数据库产品家族中最闪耀的产品。

在本文中，我们将向大家详细介绍，PolarDB发布5年来所实现的技术创新。

“三层解耦”：资源解耦的极致

从40多年前数据库诞生开始，数据库的CPU和内存都是绑定在一起的，最多做到计算和存储解耦，没有数据库能做到CPU和内存的解耦，即使演进到目前的云原生数据库阶段，在PolarDB之前也没有任何数据库能够做到这一点。

然而在云计算时代，每一层的资源解耦都可以使得弹性能力带来数量级的提升。当前云原生数据库虽然实现了计算存储的解耦，相对于传统数据库，其弹性能力有了不小的提升，但是CPU和内存的强耦合极大地限制了弹性能力的进一步提升，难以实现秒级跨机迁移；同时也限制了内存的横向扩展，使得内存受到单机容量限制。

PolarDB历史性地提出并实现了基于CPU、内存和存储资源分离的“三层解耦”架构，构建了独立的CPU资源池、分布式内存资源池、分布式存储资源池，实现了资源的彻底解耦，CPU和内存分别独立计费。同时通过分布式内存和数据库秒级跨机迁移，使得弹性能力有了数量级的提升，大幅降本增效。

多主架构：云原生数据库不再是单写数据库

云原生数据库从诞生开始，就和一写多读绑定在了一起，似乎云原生数据库天生只能是单写。写扩展能力的缺失，给用户带来了很大的困扰，很多用户在写节点到达甚至接近最大规格一半的时候，就开始担忧后续业务快速增长会导致数据库出现瓶颈，因此不得不重新考虑其他数据库架构方案，而放弃云原生数据库；亦或是依赖传统数据库的横向扩展方案，例如中间件来实现横向扩展。虽然业内也有个别厂商开始尝试多主节点，单受限于节点数，并不能实现真正的横向写扩展。

作为应云而生的云原生数据库，有没有一个云原生的解决方案来实现写扩展呢？“PolarDB多主架构”由此而生。这是业内第一个支持大规模多主多写的云原生数据库，最大支持32个写节点。在PolarDB多主架构中，阿里云在整体架构从元数据、事务、锁、Undo/Redo、IO、代理等所有子系统均做了多主化改造；并采用了PolarFusion技术，实现了多个写节点的高效数据交互。

PolarDB多主架构从根本上解决了用户的单主焦虑，使得PolarDB第一次突破了单主限制，实现了横向写扩展；数据互通后的主主互备通过消除备节点在RTO不变的情况下节约一半的成本；跨主节点秒级流量切换也为SaaS、游戏等行业解决了多租户/游戏服的跨节点调度提供了强有力的手段。

Serverless的跨机突破

Serverless是最适合云数据库的一种交付模式，实现了On-demand Provision，使得用户不需要再为数据库规划容量，在高峰时自动升配提升稳定性，在低峰时自动降配降低成本。因此一时间云数据库厂商都纷纷推出了自己的Serverless形态。

然而，当前业内的数据库Serverless形态均为单机Serverless，其容量上限受到了很大的限制（8~32 core），并不能很好的实现其高峰时自动升配以保障稳定性的目标，也限制了企业级客户的使用，同时读写节点自身的升降配对本节点的吞吐同样存在影响。这些限制的本质是目前云数据库的无感跨机弹性和强一致跨机扩展能力都尚不成熟，导致当前的Serverless只能实现单节点下有限的Serverless。跨机弹性的限制是节点无法跨机调度，因此单节点弹性上限只能限制到一个远小于物理机限制的值；而跨机强一致读扩展的能力缺失，导致其无法通过增删强一致的只读节点来实现读流量的弹性。

为解决单机Serverless的局限性，阿里云在业内第一次突破了这两个技术难点：基于事务续传和秒级切换的无感秒切技术，解决跨机弹性问题；性能无损的强一致读技术，结合热节点池技术，解决跨机透明读扩展问题。

基于以上技术突破，PolarDB Serverless的上限规格突破了1000core，带来了数量级的Serverless能力提升，使得Serverless技术有了支撑企业级业务的能力。

HTAP：同时处理交易和分析性负载

传统面向OLTP场景设计的关系型数据库，一般优化目标是提升单核性能/多核扩展性/增强集群能力以提升可用性等，其分析性能往往不佳。然而真实业务的SQL又天然是TP/AP混合的，其需要事务处理和实时数据分析兼具的HTAP系统。面对此问题，传统方案是使用一套数据同步系统串联起上游的TP系统和下游的数仓系统，形成一套搭积木的方案，用多套系统的组合来完成任务。

在云数据库时代这种架构因为串联了OLTP数据库，消息中间件，OLAP数据库三套系统，上下游协议不兼容，运行维护复杂。在云上很难规模部署以满足各种客户的需求。

针对这些问题，在PolarDB云原生数据库领域的技术积累基础上，阿里云在PolarDB上推出了In-Memory Column Index功能，其为PolarDB带来列式存储以及内存计算能力，让用户可以在一套PolarDB数据库上同时运行OLTP和OLAP型混合负载，在保证现有PolarDB优异的OLTP性能的同时，大幅提升PolarDB在大数据量上运行复杂查询的性能，让PolarDB 真正成为一款HTAP数据库。

PolarDB HTAP包含如下几个关键技术创新：

PolarDB存储引擎新增对列式索引（Columnar Index）的支持，用户可以选择通过DDL将一张表的全部列或者部分列创建为列索引，同时列索引采用列压缩存储，其存储空间消耗会远小于行存格式。
在PolarDB的SQL执行器层，阿里云重写了一套面向列存的执行器引擎框架(Column-oriented), 该执行器框架充分利用列式存储的优势，使用向量化执行方法提升算子处理海量数据的效率。同时充分发挥现代CPU的SIMD指令能力，提升CPU单核心处理数据的吞吐，且所有关键算子均支持并行执行。在列式存储上，新的执行器对比MySQL原有的行存执行器性有几个数量级的性能提升。
支持行列混合执行的优化器框架，该优化器会根据兼容性及执行计划代价两方面的因素，以选中最优的执行路径。

同时阿里云还充分利用了PolarDB云原生数据库的技术优势，支持HTAP节点的规格异构及按需弹性（Serverless），为用户提供一体化HTAP体验的同时兼具极致的性价比。

并行查询：突破单节点的资源和性能瓶颈

传统的基于MySQL的关系型数据库在部署到云上后，依然采用了主备复制的数据同步模式来提供实例的高可靠和高可用，但基于逻辑复制导致实例延迟增大、多份存储等问题。PolarDB通过共享存储和物理复制实现了云上的计存分离和资源池化能力，为用户提供了最优的弹性能力和性价比。而从线上的长期运维可以发现，云上用户实例对CPU资源的平均利用率是较低的，同时MySQL对查询的单线程处理方式又无法满足业务上基于海量数据的实时分析需求，这造成了极大的资源浪费。

为此阿里云推出了节点内以及跨节点并行查询(Parallel Query)功能，针对性的利用多核CPU并行计算来提升查询响应速度。但随着共享存储层的数据量进一步增长，单机的扩展能力将遇到瓶颈，包括CPU、Memory和IO等，传统数据库通过share nothing的分片架构和MPP计算引擎来突破单机的资源瓶颈，但这破坏了云上计存分离带来的独立扩展性和极致弹性能力，有悖于现代云原生数据库的发展趋势。

PolarDB解决这个问题的方案是更为先进的计算、内存、存储"三层解耦"模式，通过将资源进一步拆解，在各个层面上各自独立扩展。而针对大数据量分析查询，我们在计算这一层层基于Parallel Query进一步演进，推出了基于共享存储的分布式弹性并行查询(Elastic Parallel Query)，通过节点间+节点内两层并行的结合以及基于分布式资源视图的智能调度策略，打通了集群内的多节点计算资源，与传统的固化的MPP架构相比，这带来了多方面的技术和成本优势：

通过多粒度的并行，更充分的利用集群级的计算资源，突破单节点的资源和性能瓶颈，PolarDB在利用并行查询提升CPU利用率的同时，也开发了并行DDL等能力，大大缩短了DDL的时间，解决了一些大表用户的一个重要痛点，实现和传统MPP系统相同甚至更优的极致查询性能。
基于分布式的全局资源视图，并结合数据的亲和性特征，对查询内的子计算任务进行智能调度，在尽可能避免IO的情况下实现各节点计算资源的均衡利用，避免局部热点带来的性能和维护问题。
与云上的自动弹性无缝结合，随着实例计算层的scale up/scale out自适应的调整并行计算策略，既满足了用户的成本和性能需求，又无需额外的配置维护动作。
灵活控制实例级别的计算资源拓扑，通过不同接入地址（子集群），实现不同业务的相互隔离和各自独立配置，满足具有不同特性的查询业务需求。

架构演进的示意图如下：

分布式：实现透明分布式体验

数据库经历过去40多年的发展，随着互联网、大数据的飞速发展，单台务器上的性能极限已经慢慢显露，在这种情况下，技术人员逐渐开始探索数据库的扩展能力，目前整体扩展架构又两种形态：基于共享存储的share-storage架构、以及基于share-nothing的分布式架构，这两种架构分别代表了两个不同的扩展思路，有各自的优缺点。

基于scale-up的单机扩展架构，在面向高并发场景下，容易遇到单机扩展性的天花板，因此在2019年开始，PolarDB基于share-nothing的分布式架构，正式推出了云原生分布式版(PolarDB-X)，支持多写多读、以及低成本的冷热分离分层架构。

PolarDB云原生分布式版（PolarDB-X）作为一款基于原生MySQL的云原生分布式数据库，高度兼容MySQL的协议和开源生态，引入Paxos多数派共识协议，聚焦国产化MySQL替代、分布式线性扩展、以及HTAP混合负载等场景。

PolarDB云原生分布式版（PolarDB-X）包含如下几个关键技术创新：

1.透明分布式体验，引入自动数据分区与数据自动亲和性聚集技术，自动识别数据的业务属性进行相关性绑定和统一调度，在提升数据库线性扩展能力的同时，避免因为跨分区的事务和复杂查询带来的性能开销，最大程度将事务涉及范围局限在单个物理节点，以及最大化下推计算算子减少数据交换。结合全局二级索引、在线数据变更，做到分布式数据库接近单机数据库体验，打破了分布式能力应用现实场景中的关键障碍。

2.冷热分离存储架构，引入数据分区的Time-to-Live(TTL)策略，随着时间推进，可以将历史不常访问的冷数据进行定期归档，PolarDB分布式结合云对象存储OSS作为冷存储介质，采用编码压缩、以及OSS本身的成本优势，冷数据仅有MySQL InnoDB在线数据1/20的存储成本，同时提供单个数据库实例的透明使用体验，统一SQL访问、备份操作等。

3.全面拥抱国产化，基于全内核开源的策略，坚持基于MySQL的敏捷可控路线，目前PolarDB已经顺利高分通过分布式数据库的金融行业标准认证、信通院的分布式数据库性能和高可用认证等。除了满足公有云的交付外，PolarDB可以面向传统金融、政府行业的私有云交付、以及基于开源内核的纯软部署能力，全面支持数据库的多场景、多形态的交付能力。

PolarDB云原生分布式版（PolarDB-X）的数据库形态，结合云原生+分布式+国产化的技术，未来也会进一步融合HTAP混合负载能力，引入行列混存架构，更好的满足数据实时性的要求。

性能演进：提出一系列优化方法

设计之初，PolarDB的理念就是为云上用户提供具备极致弹性、高性能、海量存储、安全可靠的数据库服务。PolarDB采用计算和存储分离的架构，通过物理复制技术和共享存储架构，在满足业务容量弹性扩展需求的同时极大的降低了用户的存储成本。在设计上，PolarDB既融合了商业数据库稳定可靠、高性能、可扩展的特征，又具有开源云数据库简单开放、自我迭代的优势。

依托于阿里云先进可靠的硬件平台，PolarDB采用RoCE RDMA网络、3DXpoint存储介质等先进技术，并面向新硬件架构实现软硬一体优化。从数据库内核、文件系统到网络通讯协议和分布式存储系统，PolarDB实现了纵贯软件栈各层次的深度优化。仅仅构建高性能硬件底座并不能完全解决云原生数据库的性能问题。例如即便拥有高吞吐的RDMA网络但聚合带宽难以充分利用；远端节点I/O访问、多副本持久化等要求使得云存储I/O延时远高于本地存储；又比如更长的数据链路中有更多的排队，导致I/O间的隔离性变低；共享存储架构cache concurrence代价等。针对云原生数据库面临的性能挑战，PolarDB的存储引擎提出了一系列优化方法：

并行化多任务：例如对集中Log buffer按Page Partition分片，实现并行写入并基于分片进行并行Recovery。
预取和读取裁剪：例如通过收集并聚合原分散meta至统一的superblock，将多个I/O合一实现fast validating；通过预读利用聚合读带宽、减少读任务延时等。
锁优化：针对系统瓶颈，实现无锁刷脏、基于blink-tree的无锁SMO等。
访问打散和优先级调度：例如将单个大I/O并发分散至不同存储节点分散访问，充分利用云存储聚合带宽；在DB层面对不同I/O进行打标、调度优先级，消除长链路、低隔离I/O任务的影响。
通过Bypassing Caches来避免分布式文件系统的cache coherence，并在DB层面优化I/O格式匹配存储最佳request格式。

上述例子也只是显露了冰山一角，PolarDB在性能演进之路上也将不断向前迈进。