GaussDB架构（中）

2年前 (2022) 程序员胖胖胖虎阿

450 0 0

在GaussDB架构（上）中我们介绍了GaussDB的发展历史和架构概览，本篇主要介绍GaussDB OLTP数据库架构和GaussDB OLAP数据库架构。

GaussDB OLTP数据库架构。

OLTP是传统的关系数据库的主要应用,包括基本的增加、删除、修改、查询事务处理,例如银行交易。

1. 设计思想与目标客户

OLTP业务场景主要分为两大类:一类是金融银行业务场景,一类是互联网业务场景。但应用OLTP业务要满足5个重要的需求:

故障业务中断时间,RTO(Recovery Time Objective,恢复时间目标,指业务停止服务的最长时间)尽可能短,最好是RTO=0。
任何故障,数据不错、不丢失,RPO(Recovery Point Objective,数据恢复点目标,指业务系统的数据丢失量)=0。
并发和性能满足业务诉求。
易于运维,最好是自动诊断、自动修复。
易于调优,最好是自调优。

GaussDB OLTP数据库基于这5个关键需求设计,分层解耦:

采用并行恢复和存储层异步回放机制优化RTO,目前支持AZ(AvailabilityZone,可用区域)内RTO<10s; AZ故障,RTO<60s。
采用多副本RAFT(一种分布式一致性协议)复制机制保证数据的可靠性,即RPO=0。
支持线程池和采用高精度时钟去中心化,支持高并发和线性扩展性,满足高并发和性能的诉求。
运维能力上基于统计数据分析、推理,实现自运维能力,降低运维门槛。
采用基于AI的自调优参数和ABO(AI Based Optimization,基于人工智能的查询优化)优化器提供自调优能力,降低调优门槛。

2. 分布式强一致的架构

分布式强一致必须有一个全局的时间戳信息,否则很难保证数据的一致性。GaussDB 实现了基于GTM 的分布式ACID[原子性(Atomicity)、一致性(Consistency)、隔离性(Isolation)、持久性(Durability)]设计。

GTM 仅处理全局时间戳请求,CSN(Commit Sequence Number,待提交事务的序列号)是一个64位递增无符号数,它的递增,几乎都是CPU++ 和消息收发操作。

不是每次都写ETCD(Editable Text Configuration Daemon,分布式键值存储系统,用于共享配置、服务注册和查找),而是采用定期持久化到ETCD。每次写ETCD的CSN 要加上一个backup_step(100万),一旦GTM 出现故障,CSN 从ETCD 读取出来的值保证单调递增。当前GTM 只完成CSN++ ,可以支持200MB/s请求。GTM处理获取CSN消息和CSN++的消息,TCP协议栈消耗CPU 会非常严重,采用用户态协议栈提高GTM 单节点的处理能力。GTM 关键数据结构和线程,如下图所示。

GaussDB架构（中）

图 GTM 关键数据结构和线程

单节点的事务

单节点事务设计,如下图所示。

GaussDB架构（中）

图单节点事务设计关键设计如下:

GTM 只维护一个CSN++ ,快照(snapshot)只包含CSN。
DN(Data Node,数据节点)本地维护事务ID(唯一标识符),维护ID 到CSN的映射(CSN_LOG)。
DN本地垃圾回收的过程中回填CSN。
单分片读事务使用本地快照: ① 获取本地最新的CSN 和准备阶段事务号; ② 如果CSN 状态为“提交中”则进行等待; ③ 如果row.CSN< localsnapshot.csn || xid in prepared_xid list可见,否则不可见。

跨节点事务

跨节点事务设计,如下图所示。

GaussDB架构（中）

图跨节点事务设计

关键设计如下:

第二阶段事务提交改为异步方式,只同步做两阶段提交的准备阶段。
DN 上行级别可见性判断: ① DN 处于准备状态的事务依赖对应CN 上的事务是否提交,如果已经提交,且CSN 比snapshot.CSN 小,就可见。 ② 对DN 上处于准备状态(prepared)的事务,CN 上的事务不处于提交状态,则必须判断是否是残留状态,如果是则进行回滚。

TRY_AGAIN

IF row xact_status is prepared

{

notify clean_pending_prepared_xact

IF CN xact_status is committed && CN xact CSN snapshot CSN

return visible

goto try_again

}

Else

{

if row xact is committed and row CSN snapshot CSN

return visible

Else

return not_visible

}

3.可插拔存储引擎架构

面向OLTP不同的时延要求,需要的存储引擎技术是不同的。例如在银行的风控场景里,对时延的要求是非常苛刻,传统的行存储引擎的时延很难满足业务要求。因此GaussDB设计支持了可插拔存储引擎架构,可以同时支持传统行存储引擎和内存引擎。内存引擎采用记录(record)的组织方式,Masstree无锁化索引设计,提高系统并发能力和降低了事务的时延。行存储引擎可以支持不同的MVCC(多版本)实现机制,包括append-only形式的MVCC实现机制和in-place update的MVCC实现机制。整个数据库中存储引擎、SQL引擎都是解耦的,可以快速添加(演进)新的存储引擎和SQL引擎。

GaussDB OLAP数据库架构

OLAP是数据仓库系统的主要应用,支持复杂的分析操作,侧重决策支持,并且提供直观易懂的查询结果。

1. 设计思想与目标客户

OLAP数据分析场景有5个关键的需求:

数据量大,从几百万亿字节(TB)到千万亿字节(PB)是很正常的,容量可扩展。
复杂查询多,计算复杂度高,必须分布式并行计算。
SQL自动优化能力要强,自动调优诉求强烈。
数据入库速度要快,入库几百兆字节、万亿字节的数据很常见。
故障恢复RTO 尽可能短,数据不丢失,即RPO=0。

银行数据仓库、安全行业的同行同住分析、证券行业的数据挖掘分析都对集群的规模和并行计算能力有很高的要求。GaussDB OLAP针对这几个关键需求设计,支持了列存储引擎、自适应压缩,大大降低了存储空间,基于share nothing架构,线性扩展,解决了千万亿字节(PB)级数据存储问题。

通过分布式优化器和分布式执行器,构筑了分布式并行技术能力。数据入库采用并行加载技术,大大提高入库效率。

2. 面向数据分析的高效存储和计算架构

GaussDB OLAP数据库采用列存储引擎提高存储的压缩比和面向列的计算能力,而向量化执行相对于传统的执行模式改变是对于一次一元组的模型修改为一次一批元组,且按照列运算,这种看似简单的修改却带来巨大的性能提升。

一次一元组模型函数调用次数较大,每一条元组都会根据执行树的形态遍历执行树,面对OLAP场景,一次一元组模型巨量的函数调用次数使开销较大,而一次一批元组的执行模式则大大减小遍历执行节点的开销。
一次一批元组的数据运载方式为某些表达式计算的SIMD(Single-Instruction,Multiple-Data stream processing,单指令流多数据流)化提供了机会,SIMD 化能带来性能的提升。
一次一批元组的数据运载方式天然对接列存储,列存储引擎能够很方便地在底层扫描节点装填向量化的列数据。CPU 的指令缓存(cache)和数据缓存的命中率大大提高。

GaussDB OLAP高效存储和计算架构,如下图所示。

GaussDB架构（中）

图 GaussDB OLAP高效存储和计算架构

3. 分布式并行计算架构

分布式并行计算架构核心实现如下:

通过分布式优化器,根据代价估算、AI数据分析,产生最优的分布式执行计划。好的执行计划和差的执行计划在运行性能上可能会有很大的差距。优化器生成执行计划的过程如下图所示。

图优化器生成执行计划的过程

GaussDB OLAP数据库优化器支持CBO(Cost Based Optimization,基于代价的查询优化)和ABO(基于机器学习的查询优化),根据代价和AI学习,会自动选择SMP(Symmetric Multi-Processing,对称多处理结构)、Join order、group算法、index等,GaussDB OLAP优化器整体架构如下图所示。

GaussDB架构（中）

图 GaussDB OLAP优化器架构