AnalyticDB PostgreSQL版Multi-Master通过水平扩展Master节点突破了原架构单Master的限制,配合Segment节点(计算节点)的弹性,系统整体能力尤其是连接数及读写性能得到进一步提升,更好地满足实时数仓及HTAP等业务场景的需求。

背景信息

Hybrid Transaction Analytical Processing(HTAP)是著名信息技术咨询与分析公司Gartner在2014年提出的一个新的数据库系统定义,特指兼具OLTP(事务能力)和OLAP(分析能力)的数据库系统。在传统场景中,承担OLTP任务和OLAP任务的数据库通常是两个不同的系统。其中业务原始数据通常存储在OLTP系统中,然后通过离线导入、ETL、DTS等方式以一定延迟同步到OLAP系统中,再进行后续的数据分析工作。

AnalyticDB PostgreSQL版早期版本主打OLAP场景、具备OLTP能力。随着HTAP的流行,AnalyticDB PostgreSQL版自6.0版本开始对OLTP性能多个方面进行了优化,其中一个项目就是Multi-Master架构,通过Scale Out(节点扩展)打破了原有架构的仅支持单个Master节点带来的性能瓶颈,让OLTP事务性能具备Scale Out能力,更好地满足实时数仓和HTAP需求。

Multi-Master架构设计

Multi-Master架构图

相比早期的Single-Master架构,Multi-Master架构在Main Master和Standby Master的基础之上新增了Secondary Master的角色,Secondary Master功能与Main Master类似,支持承接DDL、DML等请求,同时您可以按需扩展来提升系统整体能力。

下表为各个Master角色及对应主要能力的简单介绍。

角色 说明
GTM 全局事务管理(Global Transaction Manager),用于维护全局的事务ID及快照信息,是实现分布式事务的核心组件。
FTS 容错服务(Fault-Tolerance Service),用于检测Segment节点及辅助协调节点的健康状态,并在Segment节点发生故障时进行Segment节点的Primary与Mirror角色的切换。
Catalog 以系统表Catalog等信息为代表的全局元信息存储。
Main Master 用于承接业务请求,并把任务分发到各个Segment节点进行分布式处理。除此之外,Main Master还承担了GTM,FTS和全局元信息服务的角色。
Standby Master 与Main Master组成典型的主备关系,在原Main Master故障的时候可以接替成为新的Main Master。
Secondary Master 功能类似Main Master,和Main Master一样可以承接业务请求并将任务分发到各个Segment节点进行处理。Secondary Master会通过GTM Proxy与Main Master上的GTM以及Segment节点交互来实现分布式事务。
说明 Main Master与Secondary Master通过上层的SLB来做基于权重的负载均衡管理。如果是在Main Master和Secondary Master相同的规格配置下,Main Master会通过权重设置来承担相对少的业务请求负载,从而为GTM,FTS等预留足够的处理能力。

Single-Master架构与Multi-Master架构对比

在数仓系统中,系统中的节点分为Master节点和Segment节点,Master节点和Segment节点承担不同类型的任务:

  • Master节点:主要负责接收业务请求、查询优化、任务分发、元信息管理和事务管理等任务。
  • Segment节点:负责计算任务和存储管理任务。

对于查询请求,Master节点需要对提交的SQL进行解析和优化,然后将优化后的执行计划分发到Segment节点。Segment节点需要对本地存储的数据进行读取,然后再完成计算和数据Shuffle等任务,最后Segment节点把计算结果返回到Master节点进行汇总。对于建表、写入等请求,Master节点需要对元信息、事务等进行管理,并协调Segment节点之间的工作。

图 1. Single-Master架构
Single-Master架构

AnalyticDB PostgreSQL版是由Greenplum演化而来,早期AnalyticDB PostgreSQL版与Greenplum一样,使用了Single-Master架构。通常情况下,数据库实例中只有Main Master在工作,Standby Master节点作为高可用备份,当Main Master节点出现故障时,Standby Master才会切换成Main Master进行工作。

随着业务的发展,例如实时数仓和HTAP场景需求的增加, Single-Master的系统瓶颈问题也逐渐显现。对于查询场景,部分查询的最后阶段会在Master节点上进行最终的数据处理,需要消耗一定的CPU以及内存资源。对于写入场景,大量的实时插入、更新、删除的需要高性能保证。同时并发连接数很大的情况Single-Master结构也较难处理。虽然以上问题可以通过提高Master节点的配置(Scale Up)来缓解,但是无法从根本上解决。

图 2. Multi-Master架构
Multi-Master架构

Multi-Master架构可以通过节点扩展(Scale out)的方式来解决Master层的资源瓶颈问题,满足了实时数仓及HTAP等业务场景需求。上图为Multi-Master架构示意图,通过增加多个Secondary Master节点来实现性能的Scale Out,同时保留原有的Standby Master来保障高可用。

为了保障OLTP能力,AnalyticDB PostgreSQL版还对Multi-Master架构进行了如下优化:

  • 扩展分布式事务能力,支持多Master的场景。
  • 对全局死锁处理、DDL支持以及分布式表锁支持等方面的算法进行创新和修改。
  • 重新设计了AnalyticDB PostgreSQL版的集群容错和高可用能力。