带领国产数据库走向世界，POLARDB底层逻辑是什么？

POLARDB 是阿里云自主研发的下一代云原生分布式数据库，100%兼容MySQL、PostgreSQL等开源数据库，高度兼容Oracle语法，使用RDS服务的客户不须要修改应用代码，能够一键迁移到POLARDB，体验更大的容量，更高的性能，更低的成本，和更灵活的弹性。

目前，POLARDB是阿里云增速最快的数据库产品，普遍应用于互联网金融、政府便民工程、新零售、教育、游戏、社交直播等行业。

做为基于计算与存储分离架构的新一代云原生数据库，POLARDB的计算节点里主要实现了 SQL 解析和优化、以及查询并行执行与无锁高性能事务处理，计算节点之间经过高吞吐的物理复制协议同步内存状态。

而存储层基于分布式文件系统PolarFS，经过Parallel Raft共识算法实现多数据副本间的强一致性，在存储层进行存储引擎的多版本页管理来支持全集群跨计算节点的Snapshot Isolation隔离级别。

0一、基于计算与存储分离的先进架构

计算节点与存储节点之间经过理解数据库语义的智能互联协议将filter和projection等算子从计算层下推到存储层执行。为了保证事务和查询语句的低延迟，同时下降计算节点之间状态同步的延迟，计算节点和存储节点之间使用25Gb高速RDMA网络互联，采用Bypass kernel的用户态网络协议层进行通信。

基于计算与存储分离的先进架构，POLARDB能够从1个计算节点（2个CPU核）弹性伸缩到16个计算节点（最高达到1000核）的事务扩展能力，单实例存储容量从10GB按使用量弹性扩展到100TB。

计算节点与存储节点分离的架构设计给POLARDB带来了实时的水平扩展能力。因为单个数据库实例的计算能力有限，传统的作法是经过搭建多个数据库副原本分担压力，从而提供数据库Scale out 的扩展能力。

然而，这种作法须要存储多份全量数据，而且频繁同步日志数据形成了太高的网络开销。此外，在传统数据库集群上，增长副本须要同步全部增量数据，这带来了同步延迟上涨的问题。

POLARDB将数据库文件以及Redo log 等日志文件存放在共享存储设备上，确保主实例和全部副本共享同一份全量数据和增量日志数据。节点间只须要同步内存里的元数据信息，经过MVCC机制的保证，就能支持跨节点读取数据的一致性，很是巧妙地解决了主实例和副本之间的数据同步问题，大大节约了跨节点的网络开销，下降副本间的同步延迟。

0二、提高事务性能 POLARDB内核层面优化揭秘

为了提升事务性能，POLARDB 在内核层面进行了大量优化。把一系列性能瓶颈用无锁（lockless）算法以及各类并行优化算法进行改造，减小甚至消除各类锁之间的相互冲突，大大增长了系统的scalability 能力。

同时，咱们依托处理双十一这种大规模高并发场景下的经验, 在 POLARDB 上实现了对库存等热点数据进行优化的功能。对于简单重复的查询，POLARDB支持直接从存储引擎获取结果，从而减小了优化器及执行器的开销。

此外，进一步优化已经高效的物理复制。好比，咱们在重作日志加了一些元数据，以减小日志解析CPU开销. 这个简单优化减小了60%日志解析时间。咱们也重用 一些数据结构，以减小内存分配器的开销。

POLARDB运用了一系列算法来优化日志应用，好比只有在buffer pool中的数据页面 才须要日志应用。同时咱们也优化了page cleaner and double write buffer，大大减小这些工做的成本. 这一系列优化使得在性能上 POLARDB 远超 MySQL ，在sysbencholtp_insert等大量并发写入的基准评测中达到最高6倍于MySQL 的性能。

0三、支持并行查询（Parallel Query）

为了提升子查询和join等复杂查询（例如TPC-H基准评测）的能力，POLARDB的查询处理器支持并行查询（parallel query），能够将一个查询同时在多个或全部可用CPU核上进行执行。并行查询可以将一个查询任务（当前只支持SELECT语句）划分为多个子任务，多个子任务能够并行进行处理，总体采用Leader-Worker的并发模型。

Leader线程负责生成并行查询计划，协调并行执行过程的其余组件，并行执行计划会包括并行扫描、多表并行链接、并行排序、并行分组、并行汇集等子动做。

Message queue是leader线程和worker线程的通信层，worker线程经过message queue向leader线程发送数据，而leader线程也会经过message queue向worker线程发送控制信息。

Worker线程负责真正的执行任务。Leader线程解析查询语句生成并行计划，而后同时启动多个worker线程进行并行任务处理，为了高效的执行查询，Worker上的执行不须要进行再次优化，而是直接从Leader上来拷贝生成好的计划分片。这须要实现执行计划树上全部节点的拷贝。

worker线程在进行扫描，汇集，排序等操做后将中间结果集返回给leader，leader负责收集来自worker的全部数据集，而后进行适当的二次处理（好比merge sort，二次group by 等操做），最后将最终结果返回给客户端。

Parallel Scan层会结合存储引擎的数据结构特征来实现工做负载的均衡。如何将扫描数据划分红多个分区，使得全部的工做线程尽量的均匀的工做是数据分区划分的目标。在以B+树做为存储结构的存储引擎里，划分分区的时候，是先从根上来划分，若是根上不能划分出足够多的分区（>= 并行度），将会继续从下一层进行划分。

而若是咱们须要6个分区的话，根节点最多分出4个分区，因此就须要继续搜索下一层来进行分区，以此类推。在实际实现并行查询的过程当中，为了能让多个工做线程更加均匀的分配扫描段，会在B+树里尽量的多划分分区，这样若是某个工做线程因为过滤性比较高会优先完成当前分区，那么它会自动attach下一个分区继续执行，经过自动attach的方式来实现全部线程的负载均衡。

0四、新一代基于代价的优化器

云上客户的业务是多样化的，若是执行计划选错会致使慢查询。为了系统性地解决这些问题，POLARDB推出了新一代的基于代价的优化器。POLARDB里实现新的直方图Compressed Histogram对高频率数据进行自动探测并构建精确描述，在选择率计算时考虑数据频率和取值空间，解决实际应用中广泛存在的数据倾斜场景。

POLARDB大量基于改良的直方图进行代价估算，好比估算表和表join的结果大小，是join代价和join order优化的决定性因素，MySQL只能根据经验公式粗略的估算，不管是有索引时的rows_per_key,仍是无索引时的默认参数值，估算的偏差都较大，这些偏差会在多表链接的过程当中不断放大，致使生成效率低下的执行计划。

在POLARDB中使用直方图对重合部分进行合并计算，并根据不一样的直方图类型适配不一样的estimation算法，大大提升了估算精度，帮助优化器作出更优的join order选择。在随机生成的正态分布数据测试中，多表联合查询优化后可提速2.4-12倍，TPC-H测试中多个查询的join order发生变化，性能提高77%-332%。

POLARDB也使用直方图优化了record_in_range的逻辑，MySQL对于有索引的过滤条件采用index dive来估算区间的记录数，这个操做在OLTP短查询中CPU占比较高。在使用基于直方图估算替换index dive后，在淘宝电商核心业务中，绝大多数的查询查询响应时间减小一半。

0五、自研分布式文件系统PolarFS：高可靠、高可用、与数据库协同设计

POLARDB的存储层采用的是阿里云自主研制的分布式文件系统PolarFS。PolarFS是国内首款面向DB应用设计的采用了全用户空间I/O栈的低延迟高性能分布式存储系统（参见VLDB 2018 上的文章 PolarFS: An Ultra-low Latency and Failure Resilient Distributed FileSystem for Shared Storage Cloud Database），其具有与本地SSD硬盘架构至关的低延迟高性能I/O能力，同时也以分布式集群的方式提供了优异的存储容量与存储性能的扩展能力。

而PolarFS做为一款与POLARDB深度协同的存储基础设施，其最核心的竞争力不只体如今性能和扩展性方面，更深层次的则是在面临有许多挑战性的POLARDB客户业务需求和规模化的公有云研发运维过程当中而长期积累造成的一系列高可靠、高可用、与数据库协同设计的存储技术。

为了支持POLARDB在多个计算节点之间分发查询且保持全局的Snapshot Isolation语义，PolarFS支持存储POLARDB存储引擎B+树动态生成的多版本（Multi-version page）。

为了减小读写冲突，现代数据库通常都经过以MVCC并发控制为框架来提供RC、SI、SSI等不一样的事务隔离级别，在MVCC机制下，B+树的每一个页面会动态维护一系列的版本，并发执行中的多个事务容许各自访问一个页面的不一样版本。

在POLARDB集群里，因为跨节点复制同步延迟的存在，每一个计算节点B+树的页面多是不一样版本的，这时多版本存储能够为各节点提供其所对应版本。在POLARDB中，计算节点向PolarFS写入一个页面的同时要提供该数据页的版本信息（LSN），PolarFS不只存储数据页的同时还要存储数据版本元信息；计算节点读取数据页时，也会提供版本信息从存储获取相应的数据页（历史）版本。

POLARDB数据库层按期会将集群全部计算节点版本号的低水位线发送给PolarFS，PolarFS会基于此版本号清理再也不使用的历史版本。

保证数据可靠性是POLARDB全部设计的底线。在实际的分布式系统中，硬盘、网络与内存等硬件、固件或软件的bug等问题可能会形成数据错误，从而给数据可靠性保障带来各类挑战。存储端的可靠性问题来自静默错误（lost write、misdirected write，block corruption等），网络和内存主要来自于比特反转和软件bug。

为了确保各类异常状况（包括：硬件故障，软件故障，人工操做故障）发生时的数据可靠性，POLARDB和PolarFS提供了端到端全链路数据校验保障。

在数据写入时，POLARDB 从计算节点的存储引擎开始，一直到PolarFS存储节点的数据落盘，通过的中间链路，都会对数据的正确性作校验，防止异常数据写入。

在数据读取时，PolarFS和POLARDB存储引擎都会对读取到的数据作checksum校验，准确地识别磁盘静默错误的发生，防止静默错误扩散。

在业务流量低峰时，还会在后台持续性的作数据一致性扫描，用于检查单副本数据的checksum是否正确以及各个副本间的数据是否一致。数据迁移过程当中的正确校验性也很是重要：POLARDB在执行任何形式的数据迁移动做时，除了副本自身数据的 checksum 校验，还会对多个副本数据的一致性作校验；当这两个校验都经过，才会将数据迁移到目标端；最大限度的防止因为迁移动做，致使单副本上的数据错误扩散，避免数据损坏问题。

PolarFS还支持对POLARDB作快速的物理快照备份与还原。快照是一种流行的基于存储系统的备份方案。其本质是采用Redirect-On-Write 的机制，经过记录块设备的元数据变化，对于发生写操做的存储卷进行写时复制，将写操做内容改动到新复制出的存储卷上，来实现恢复到快照时间点的数据的目的。

快照是一个典型的基于时间以及写负载模型的后置处理机制。也就是说建立快照时，并无备份数据，而是把备份数据的负载均分到建立 快照以后的实际数据写发生的时间窗口，以此实现备份、恢复的快速响应。

POLARDB经过底层存储系统的快照机制以及Redo log增量备份，在按时间点恢复用户数据的功能上，比传统的全量数据结合逻辑日志增量数据的恢复方式更加高效。

0六、高度兼容Oracle语法 成本是商业数据库的1/10

除了100%兼容MySQL和PostgreSQL这两个最流行的开源数据库生态， POLARDB还高度兼容Oracle语法，为传统企业上云提供成本是商业数据库1/10的方案。

经过用DMS替换Oracle的GUI管理工具OEM，以及用POLARDBPlus替换命令行工具SQL Plus，沿袭了OracleDBA的使用习惯；客户端SDK能够从OCI和O-JDBC Driver替换成libpq和JDBC Driver，只须要作so和jar包的替换，程序主体代码不须要修改；

对Oracle的SQL普通DML语法都能支持，对几乎全部高级语法如connect by、pivot、listagg等也都全面支持；对PL/SQL存储过程、以及存储过程用到的内置函数库也能作到全面覆盖支持；

对一些高级功能（如安全管理、AWR等）提供彻底相同的格式布局和操做语法，因此综合看来，POLARDB对Oracle的操做方法、使用习惯、生态工具、SQL语法、格式布局等都作到了全面的兼容和替换，结合迁移评估工具ADAM，应用能够作到少许改动甚至无改动。

0七、提早看：更多新技术和企业级特性即将上线

除了上面介绍的技术，POLARDB还有大量新技术和企业级特性在2019下半年陆续发布，这些技术会全面提高POLARDB的可用性、性能，下降POLARDB的使用成本：

1）从弹性存储到弹性内存，热缓冲池（warm buffer pool）技术

POLARDB即将支持和计算节点进程解构的“热”缓冲池，这将大大减小用户业务在计算节点重启时受到的影响。在进行机型替换规格升降级的时候（serverless），对业务的影响更小。同时，一个独立的内存也使得其动态按需扩展或收缩成为可能。

2） 性能数倍增加，更好的DDL支持（FAST DDL）

POLARDB即将支持并行DDL，这将大大缩短表级别的DDL延迟。这个功能把并行化作到极致，能够把建索引等DDL的时间减小近10倍。同时，POLARDB还进行了大量的DDL复制层面的优化，这使得DDL能够进行跨区域的大批量复制，速度更加迅速，资源的消耗更少。

3） 支持跨地域的全球数据库（Global Database）

POLARDB 支持跨地域、长距离的物理复制，帮助用户创建其全球数据库的部署。经过物理复制，数据能够实时复制到全球各个机房，使得全球用户的查询在当地机房就获得响应，反应更迅速。

4）分区表的支持

POLARDB支持100T的存储容量。可是随着表的大小的增加，单表索引的层次也增长，致使数据的查找定位也变得更慢，一些单表上的物理锁也致使并行DML碰到天花板。

因此进行合理的分区变得更加紧迫。以前很多用户依赖数据库外部中间件的分库分表的来减小单表的压力。

可是，随着POLARDB在各方面好比并行查询的发展，咱们能够把这些分库分表的功能经过分区表的形式在数据库内更有效的实现。

有效的分区不但使咱们可以支持更大的表，并且它减小了一些数据库索引的全局物理锁的冲突，从而提升总体DML的性能。

同时，这种形态以后能够更好的支持冷热数据分离，把不一样“温度“的数据存放在不一样的存储介质中，在保证数据access的性能的同时，减小数据存放的成本。

POLARDB在加强分区表的一系列功能，包括全局索引（Global Index），分区表的外键（Foreign Key Constraint），自增分区表（Interval Partition）等，使得POLARDB更好的应对特大表

5） 行级压缩

POLARDB即将推出行级压缩功能。业界一般的作法是在数据页级别经过通用压缩算法（好比LZ7七、Snappy）进行压缩，但页级压缩会带来CPU开销过大的问题，由于改动一行数据，也要把整个数据页解压，改动，再压缩。

此外，有些场景下数据页压缩后反而变大（bloat），还会致使多重索引页分裂 （multiple splits）。POLARDB采用细粒度（fine-grain）行级压缩技术，对不一样的数据类型采用特定的压缩方式。

数据以压缩的方式同时存在于外存及内存中，只有在要查询的时候才进行行级数据的解压，而不用解压整个数据页。因为数据除查询外都是以压缩方式存储，因此日志也记录了压缩的数据，这个进一步减小了日志的大小，以及在网络传输的数据/日志的压力。同时其相对应的索引也只存储压缩的数据。

总体数据量的减小足以抵消解压所引发的额外开销，使得这种压缩在大大减小数据存储的同时并不会引发性能衰退。

6）In-Memory的列存（HTAP）

在传统的数据库领域，分析数据库和在线事务处理是分隔开来的。所以一般须要在一天的经营结束后将在线事务处理的数据与往期分析处理的数据一块儿导入至数据仓库后运行分析，以生成相应的报表。

在HTAP数据库中，则省去了大规模数据搬移的时间与运营成本，一站式解决大部分企业级应用的需求，并在交易结束当天同步出具T+0的分析报告。

在这种需求下，POLARDB在实现in-memory的列存数据表。经过物理逻辑日志直接和POLARDB行存数据同步。这样经过特定适合分析的算子能够对这些列存数据进行实时的大数据分析。使得用户能够一站式的获得分析结果。

7）冷热分离存储引擎X-Engine

存储数据的规模愈来愈庞大，但不是全部的数据访问频率都相同，实际上数据访问老是呈现比较明显的冷热分布特征，基于这一特征，X-Engine设计了冷热分层的存储架构，根据数据访问频度(冷热)的不一样将数据划分为多个层次，针对每一个层次数据的访问特色，设计对应的存储结构，写入合适的存储设备。

不一样于传统的B+树技术，X-Engine使用了LSM-Tree做为分层存储的架构基础，使用多事务处理队列和流水线处理技术，减小线程上下文切换代价，并计算每一个阶段任务量配比，使整个流水线充分流转，极大提高事务处理性能。数据复用技术减小数据合并代价，而且由于数据复用减小缓存淘汰带来的性能抖动。进一步利用FPGA硬件加速compaction过程，使得系统上限进一步提高。

相对于其余相似架构的存储引擎好比RocksDB，X-Engine的事务处理性能有10倍以上提高。

X-Engine的详细技术参考SIGMOD 2019的论文X-Engine: An Optimized StorageEngine for Large-scale E-Commerce Transaction Processing。

目前，POLARDB不只支撑阿里巴巴集团淘宝、天猫、菜鸟等业务场景，还普遍应用于政务、零售、金融、电信、制造等领域，目前已经有40万个数据库迁上阿里云。

基于POLARDB分布式数据库，北京的公交系统快捷、流畅地安排着全市2万多辆公交车，方便天天800万人次出行；

众安保险使用该数据库处理保单数据，效率提高25%。

解锁18篇POLARDB深度文章：https://developer.aliyun.com/article/721566?spm=a1z389.11499242.0.0.65452413DHyqZn&utm_content=g_1000083118

阿里云双11亿元补贴提早领，进入抽取iPhone 11 Pro：https://www.aliyun.com/1111/2...

---

本文做者：Roin123

阅读原文

本文为云栖社区原创内容，未经容许不得转载。