分布式 HTAP 数据库 ADB PG 架构解析

阿里云AnalyticDB for PostgreSQL（简称 ADB PG），为基于PostgreSQL内核构建的分布式数据库，支持ANSI SQL , 兼容部分Oracle语法，支持存储过程、触发器、用户自定义函数UDF等丰富语法功能，同时其为水平扩展架构，即支持高吞吐的分布式事务处理，也支持高性能的复杂查询分析，是阿里云提供的高性能分布式HTAP数据库。ADB PG分别通过了信通院组织的分布式分析型数据库和分布式事务数据库功能和性能认证，是国内唯一一家同时通过这两项认证的数据库产品。同时 ADB PG通过了严格的世界标准TPC组织的TPC-H 30TB 认证，性能第一，为国内第一个通过国际 TPC-H 认证的产品。

本文将介绍ADB PG的关键架构，以及同开源分布式数据库TiDB比较了OLTP指标TPC-C，及同开源分析型数据库Greenplum比较了OLAP指标TPC-H。OLTP Benchmark TPC-C 为TiDB两倍，OLAP benchmark 为开源MPP数据库 Greenplum两倍，在一套架构上，实现了高性能的分布式HTAP能力。

ADB PG 技术架构

ADB PG基于PostgreSQL内核，分为Master协调节点和Segment数据节点。Master 负责SQL的解析和优化，并生成分布式执行计划，发送给segment节点并行执行。

• 协调节点Master：分为一个Main Master和多个Secondary Master，其接受客户端请求，并进行SQL的解析和优化。同时Main Master构建了GTM全局事务管理模块，维护全局统一的事务ID （Global XID）和当前活跃事务列表（Snapshot），从而实现严格的SERIALIZABLE、READ COMMITTED 隔离级别 ，保证各个节点间事务的强一致性。Master节点含有采用Cascade架构SQL优化器，将RBO和CBO统一结合，同时可以自动的优化改写关联子查询等复杂SQL语句，实现计算按最优的分布式计划执行，规避复杂SQL的手工调优改写。
• 计算节点 Segment：Segment节点可水平扩展，节点支持多副本存储，表支持按行或者按列进行数据存储。当面向交易场景时，行存储提供高吞吐的事务处理能力，面向分析场景时，列存储及多种索引机制等，提供高性能的聚合分析，以及数据高压缩比。同时ADB PG在既有PostgreSQL的计算引擎基础上，开发了全新的高性能向量化计算引擎Odyssey，实现TPC-H分析性能比原生PG引擎快两倍

分布式事务

PostgreSQL 单机内核，其数据存储采用多版本机制MVCC，支持高并发的读写操作，以及通过事务ID（XID）和维护活跃事务列表（snapshot），实现SI/RR/RC隔离级别，具备良好的事务吞吐能力。在分布式场景下，ADB PG引入了全局事务管理器 （GTM），其在 Main Master节点维护全局统一的事务ID （Global XID）和全局活跃事务列表（Global Snapshot），从而实现分布式下的节点间事务强一致性。
PostgreSQL内核中，在事务启动时，会得到一个全局事务ID。对于SI隔离级别，启动同时会得到当时的活跃事务列表（snapshot ）来实现事务过程中的数据可见性判断，并会对过程中访问的对象加锁（悲观锁模式）；对于RC隔离级别，事务过程中的每次SQL查询会先取得当时的活跃事务列表，但不会对访问对象加锁，来实现事务过程中的可见性判断，并具备更优的并发支持效果。ADB PG支持SI和RC隔离级别，在全局级别实现了上述的可见性控制，从而实现节点间的事务强一致性。

ADBPG在分布式场景下，采用两阶段提交 2PC，但针对单分区事务，会自动优化为一阶段提交 1PC，同时在 Master 节点实现 plan cache等机制，实现高吞吐的事务处理能力。

MPP全并行分析

对于分布式数据库，具备高性能分析的基础是支持全并行计算架构（Massive Parallel Processing），核心是可以依据数据在节点间的分布特征，提供节点间运行时数据 Shuffle 能力（motion 算子），从而实现关联JOIN操作在节点间并行执行。ADB PG支持数据在节点间按 HASH，RANDOM，REPLICATED三种模式分布。对于大表建议为HASH分布，数据可以均匀打散在节点间，对于维度表等小表，可以采用REPLICATED复制分布，每个节点都保存一份全量数据，从而规避关联时的数据重分布操作。

数据在节点间基于分布列的 HASH 值分布示意

针对OLAP中的复杂关联，ADB PG实现三种分布式关联计算，local join、redistributed join、broadcast join，实现复杂关联分析在节点间的全并行执行。

节点本地关联（Local Join）的实现

重分布关联（Redistributed Join）的实现

广播关联（Broadcast Join）的实现

向量化计算引擎

PostgreSQL采用传统数据库执行引擎实现方式，ADB PG 构筑了新一代的计算引擎Odyssey，其通过算法设计，消除了传统引擎火山模型、碎片化内存分配、冗余逻辑等带来的性能问题，将CPU资源用于核心计算；同时采用LLVM进行自动代码生成（CodeGen），提升表达式计算性能、精简计算逻辑，实现逻辑计算完美“瘦身”；同时充分利用新硬件特性，采用了CPU的SIMD等新技术，最大提升计算性能。Odyssey计算引擎与PostgreSQL原生引擎并置，对于偏向复杂分析计算的SQL执行任务，将采用Odyssey引擎，提升计算性能，对于简单事务处理，依然基于PG原生引擎。

多副本高可用

ADB PG的每个Master和Segment节点都保存一份全量元信息，节点间元信息保持强同步。Segment数据节点支持多副本存储，保证数据可靠性。在一主一备配置下，主备之间基于PostgreSQL的 xlog replication，主备间保持强同步。在一主多备模式下，支持异步的quorum commit复制，保持高性能和数据可靠性。

OLTP 分布式事务场景与TiDB的性能比较

ADB PG在保证分布式强一致，提供标准RC隔离级别下，通过Segment 和 Master 的水平扩展，提供高性能的分布式事务吞吐。ADB PG支持标准的TPC-C benchmark。如下分析对比ADBPG和TiDB的TPC-C Benchmark性能，两者的测试指标可以参见官方文档：

• ADBPG 6.0 的TPC-C 的评测：在总计 64 Core，512GB 内存上101231.3 tpmC，细节可以参见 https://help.aliyun.com/document_detail/155810.html
• TiDB 3.0 的TPC-C 的评测：在总计 120 Core，384GB 内存上44068 tpmC ，细节可以参见 https://pingcap.com/docs-cn/stable/benchmark/tpcc/

上述配置上，因为均为全内存计算，内存差异对性能影响可以忽略，同时在TiDB具备更多CPU资源下，ADB PG为TiDB的2倍以上。

OLAP 复杂分析场景与Greenplum的性能比较

ADB PG自研了向量化计算引擎 Odyssey，同时构筑具备优势的列存储格式，在2019年11月份的信通院分析型数据库大规模性能测试中，ADB PG 基于640个MPP节点，验证通过 TPC-DS 100TB 分析性能测试。640 个MPP节点集群也为该认证迄今最大的MPP节点认证规模。

ADB PG自研了 向量化计算引擎Odyssey，较开源MPP数据库Greenplum原生的PG计算引擎，性能快接近两倍。如下是同等规格下的1TB TPC-H性能比较。

综述

ADB PG采用水平扩展架构，具备完备的数据库SQL功能支持，同时基于GTM分布式事务管理框架，实现了分布式下的强一致性，支持SI/RC隔离级别。OLTP Benchmark TPC-C 为TiDB两倍，OLAP benchmark 为开源MPP数据库 Greenplum两倍，在一套架构上，实现了高性能的分布式HTAP能力。