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

本文涉及的产品
RDS PostgreSQL Serverless,0.5-4RCU 50GB 3个月
推荐场景:
对影评进行热评分析
阿里云百炼推荐规格 ADB PostgreSQL,4核16GB 100GB 1个月
简介: 阿里云ADB PG,为基于PostgreSQL内核构建的分布式数据库,兼容部分Oracle语法,其可以水平扩展,即支持高吞吐的分布式事务处理,也支持高性能的复杂查询分析,是业内最具竞争里的分布式HTAP数据库。

阿里云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节点并行执行。

arch01

  • 协调节点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隔离级别,在全局级别实现了上述的可见性控制,从而实现节点间的事务强一致性。

dtxn

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

MPP全并行分析

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

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


hash

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

节点本地关联(Local Join)的实现

localjoin

重分布关联(Redistributed Join)的实现

rjoin

广播关联(Broadcast Join)的实现

bjoin

向量化计算引擎

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

odyssey

多副本高可用

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

ha


DDL 元信息处理:每个节点(Master/Segment)为一个独立PG实例,完整的Catalog元信息。Master 发DDL stmt 语句 和 2PC提交 给各个Secondary Master/Segments。
DML 数据处理: Master 向 Segment 下发执行计划 Plan。当Segment采用一主一备时,主备采用xlog的强同步;采用一主两备的三副本,采用异步 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
  • TiDB 3.0 的TPC-C 的评测:在总计 120 Core,384GB 内存上44068 tpmC
项目 ADB PG TiDB
Cores/Mem 64 Core/512GB Mem 120 Core/384GB Mem
TPC-C Conf 1000 warehouse 1000 warehouse
Performance 101231 tpmC 44068 tpmC

上述配置上,因为均为全内存计算,内存差异对性能影响可以忽略,同时在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性能比较。

TPC-H ADB PG Greenplum
Q1 171.05 399.38
Q2 12.24 25.32
Q3 38.26 56.91
Q4 20.2 54.26
Q5 118.72 145.64
Q6 21.19 30.61
Q7 63.79 71.43
Q8 37.84 73.58
Q9 169.28 174.09
Q10 36.96 51.56
Q11 4.56 11.63
Q12 27.74 44.25
Q13 40 59.13
Q14 15.18 27.9
Q15 26.27 48.62
Q16 13.02 19.15
Q17 178.73 294.83
Q18 98.39 293.15
Q19 48.15 41.84
Q20 32.22 61.87
Q21 58.85 151.44
Q22 25.6 43.26
Total 1258.24 2179.85

综述

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

目录
相关文章
|
23天前
|
运维 持续交付 云计算
深入解析云计算中的微服务架构:原理、优势与实践
深入解析云计算中的微服务架构:原理、优势与实践
56 1
|
16天前
|
运维 监控 持续交付
微服务架构解析:跨越传统架构的技术革命
微服务架构(Microservices Architecture)是一种软件架构风格,它将一个大型的单体应用拆分为多个小而独立的服务,每个服务都可以独立开发、部署和扩展。
140 36
微服务架构解析:跨越传统架构的技术革命
|
3天前
|
设计模式 监控 Java
分布式系统架构4:容错设计模式
这是小卷对分布式系统架构学习的第4篇文章,重点介绍了三种常见的容错设计模式:断路器模式、舱壁隔离模式和重试模式。断路器模式防止服务故障蔓延,舱壁隔离模式通过资源隔离避免全局影响,重试模式提升短期故障下的调用成功率。文章还对比了这些模式的优缺点及适用场景,并解释了服务熔断与服务降级的区别。尽管技术文章阅读量不高,但小卷坚持每日更新以促进个人成长。
23 11
|
4天前
|
消息中间件 存储 安全
分布式系统架构3:服务容错
分布式系统因其复杂性,故障几乎是必然的。那么如何让系统在不可避免的故障中依然保持稳定?本文详细介绍了分布式架构中7种核心的服务容错策略,包括故障转移、快速失败、安全失败等,以及它们在实际业务场景中的应用。无论是支付场景的快速失败,还是日志采集的安全失败,每种策略都有自己的适用领域和优缺点。此外,文章还为技术面试提供了解题思路,助你在关键时刻脱颖而出。掌握这些策略,不仅能提升系统健壮性,还能让你的技术栈更上一层楼!快来深入学习,走向架构师之路吧!
33 11
|
13天前
|
Cloud Native 关系型数据库 分布式数据库
PolarDB 分布式版 V2.0,安全可靠的集中分布式一体化数据库管理软件
阿里云PolarDB数据库管理软件(分布式版)V2.0 ,安全可靠的集中分布式一体化数据库管理软件。
|
21天前
|
存储 Linux API
深入探索Android系统架构:从内核到应用层的全面解析
本文旨在为读者提供一份详尽的Android系统架构分析,从底层的Linux内核到顶层的应用程序框架。我们将探讨Android系统的模块化设计、各层之间的交互机制以及它们如何共同协作以支持丰富多样的应用生态。通过本篇文章,开发者和爱好者可以更深入理解Android平台的工作原理,从而优化开发流程和提升应用性能。
|
23天前
|
弹性计算 持续交付 API
构建高效后端服务:微服务架构的深度解析与实践
在当今快速发展的软件行业中,构建高效、可扩展且易于维护的后端服务是每个技术团队的追求。本文将深入探讨微服务架构的核心概念、设计原则及其在实际项目中的应用,通过具体案例分析,展示如何利用微服务架构解决传统单体应用面临的挑战,提升系统的灵活性和响应速度。我们将从微服务的拆分策略、通信机制、服务发现、配置管理、以及持续集成/持续部署(CI/CD)等方面进行全面剖析,旨在为读者提供一套实用的微服务实施指南。
|
14天前
|
存储 算法 安全
分布式系统架构1:共识算法Paxos
本文介绍了分布式系统中实现数据一致性的重要算法——Paxos及其改进版Multi Paxos。Paxos算法由Leslie Lamport提出,旨在解决分布式环境下的共识问题,通过提案节点、决策节点和记录节点的协作,确保数据在多台机器间的一致性和可用性。Multi Paxos通过引入主节点选举机制,优化了基本Paxos的效率,减少了网络通信次数,提高了系统的性能和可靠性。文中还简要讨论了数据复制的安全性和一致性保障措施。
32 1
|
22天前
|
NoSQL Java 数据处理
基于Redis海量数据场景分布式ID架构实践
【11月更文挑战第30天】在现代分布式系统中,生成全局唯一的ID是一个常见且重要的需求。在微服务架构中,各个服务可能需要生成唯一标识符,如用户ID、订单ID等。传统的自增ID已经无法满足在集群环境下保持唯一性的要求,而分布式ID解决方案能够确保即使在多个实例间也能生成全局唯一的标识符。本文将深入探讨如何利用Redis实现分布式ID生成,并通过Java语言展示多个示例,同时分析每个实践方案的优缺点。
39 8
|
23天前
|
SQL 数据可视化 数据库
多维度解析低代码:从技术架构到插件生态
本文深入解析低代码平台,涵盖技术架构、插件生态及应用价值。通过图形化界面和模块化设计,低代码平台降低开发门槛,提升效率,支持企业快速响应市场变化。重点分析开源低代码平台的优势,如透明架构、兼容性与扩展性、可定制化开发等,探讨其在数据处理、功能模块、插件生态等方面的技术特点,以及未来发展趋势。

相关产品

  • 云原生数据仓库 AnalyticDB PostgreSQL版