一、背景
近期，公司在继续推进信创改造，其中数据库部分涉及到了GaussDB，因此，本文借此对GaussDB进行部分知识调研。、
二、GaussDB概览
2.1、产品概述
GaussDB 是华为自主研发的分布式关系型数据库 ，采用share-nothing架构，数据自动分片，通过GTM-Lite技术实现事务强一致，且无中心节点性能瓶颈；通过分布式全局事务一致性优化，打破传统分布式性能瓶颈，实现计算与存储的自由水平扩展能力，同时支持新增分片的数据在线重分布能力。它支持x86和鲲鹏处理器，提供高并发事务实时处理能力、两地三中心金融级高可用能力和分布式高扩展能力；具备企业级复杂事务混合负载能力，同时支持分布式事务，同城跨AZ部署，数据0丢失，支持1000+的扩展能力，PB级海量存储。。对应的开源版本是openGauss，旨在打造一个高性能、可伸缩、安全的开源数据库。GaussDB是华为基于openGauss开源社区的基础上开发的闭源数据库产品。两者共享相同的开源根源，但GaussDB作为闭源产品，提供商业级别的支持和担保。GaussDB基于鲲鹏生态，是当前国内唯一能够做到全栈自主可控的国产品牌且支持开源社区。
GaussDB数据库适用于金融、政府、电信、大企业等行业核心关键系统。其中，GaussDB T数据库专注于事务处理；GaussDB A数据库则具备分析及混合负载能力，适合数据仓库、数据集市、实时分析等场景。
- GaussDB T数据库：特别适合于需要处理大量事务的系统，例如电信计费、银行交易等。它支持ACID事务、MVCC多版本并发控制，确保数据的一致性和完整性。GaussDB T数据库在基于鲲鹏处理器的16节点TPC-C标准测试中，性能达到千万级tpmC，显示出其在高并发场景下的优秀性能。
- GaussDB A数据库：支持行存储与列存储，提供PB级数据分析能力、多模分析处理能力。它适用于数据仓库、数据集市、实时分析、实时决策和混合负载等场景，广泛应用于金融、政府、电信、大企业等行业核心系统。GaussDB A数据库基于鲲鹏920处理器，相对通用同期芯片，TPC-H/TPC-DS性能提升30%。
GaussDB性能方面，32节点规模下提供高达1500万tpmC（每分钟处理的新订单数，是衡量数据库联机交易处理（OLTP）性能的核心指标）的事务处理能力。3节点TPC-H标准性能压测，1TB<280s，单集群最大数据量超过4PB。
2.2、架构
GaussDB在架构设计上，采用组件化 原则，分为GaussDB Kernel内核 和GaussDB Kernel OM两部分；GaussDB Kernel面向云服务提供GaussDB产品，主要客户包含金融（银行、证券、保险）行业、政府（政务云、财政等）和大企业客户；在产品形态上，提供面向云数据库服务GaussDB的分布式安装包和集中式安装包，提供面向本地化安装的小型化安装包。
GaussDB Kernel在云服务场景中的架构目标按照一下几个维度来展开：
- 高性能 ：建立基于x86平台与鲲鹏平台的绝对性能领先，鲲鹏平台 相对x86平台保证50%性能优势 ，达到单机170万tpmC，分布式全局强一致32节点1500万tpmC，承载用户关键业务负载；具备性能韧性能力，5倍压力下性能不抖动、十倍压力下系统不崩溃，同时具备抗过载逃生能力；具备大并发、低时延能力，单节点支持1万并发、单集群支持10万级并发访问请求，ms至秒级事务处理时延，支撑政企客户核心业务负载。
- 云原生 ：通过GTM-Lite 技术轻量化处理 全局读一致性点与写一致性点，集群扩展性达到256节点 ，未来通过全球时钟技术演进，在跨Region 全局一致性下去除单点瓶颈 ；面向业务陡增等业务场景，构建基于哈希聚簇 的存储结构和弹性扩容方案，实现秒级存储节点扩缩容和业务无感的计算节点弹性伸缩；构建分布式备机只读技术，只读性能提升100%以上。其中，GTM-Lite保证分布式事务强一致的前提下，消除传统单GTM的性能瓶颈；它介于标准GTM和GTM-Free之间：标准GTM由中心节点统一分配全局事务ID，高并发下容易成为单点瓶颈；GTM-Free则完全不与GTM交互，一致性较弱。GTM-Lite采用"本地事务ID + 全局CSN"的方式，把GTM的压力降到最低。
高可用：AZ内主备高可用，1主多备，RPO=0、RTO<10s；同城跨AZ高可用，RPO=0、RTO<60s；跨Region容灾，RPO<10s、RTO<5min；提供备份恢复、PITR、闪回、ALT等企业级高可用特性；构建基于Paxos协议的多副本高可用和并行逻辑复制技术，实现RPO=0的同城双集群高可用容灾和基于流式复制的多地多中心容灾，保证机房级、区域级、城市级故障下的数据库高可用。
高安全：继承可信实施策略中安全可信需求，从安全，韧性，隐私等维度构筑安全可信能力，结合业界安全技术前沿发展，设计全密态数据库和防篡改数据库，保证用户敏感数据免于泄露和篡改；构建数据库安全自治管控方法，识别和拦截攻击者的异常行为；构建从接入、访问控制、加密到审计全方位纵深防御的安全防护体系。
高智能：面向云化场景故障运维诉求，基于AI技术，提供端到端自治运维管理能力，全面提升数据库产品服务可靠性和可用性；构筑自学习数据库内核，尤其是智能优化器，解决数据库内优化执行过程中计划不准、无法自适应等难题；结合业界前沿技术，构建库内AI引擎，基于SQL-like简易语法，提供数据库内置的机器学习训练和推理能力，为用户提供普惠AI；提供向量数据库能力，支撑盘古大模型、NAIE-NetGPT和GTS领域知识库等场景，提高大模型的预测效率。
1）GaussDB分布式版形态整体架构
- Coordinator Node ：协调/调度节点CN，负责接收 来自应用的访问请求，并向客户端返回执行结果；负责分解任务，并调度任务在各分片上并行执行。
- GTM ：全局事务管理器（Global Transaction Manager），负责生成和维护全局事务ID、事务快照、时间戳、Sequence信息等全局唯一的信息。
- Data Node ：数据节点DN，负责存储 业务数据、执行数据查询任务以及向CN返回执行结果。
关键技术方案：
- 分布式执行框架会根据业务SQL生成最优执行计划，通过算子下推、并行执行等技术，提升分布式执行效率。
- 算子下推 ：完美sharding的单节点执行、点查等不需要DN间数据交互的场景下，CN将SQL直接下发至DN执行；跨节点分布式执行、关联查询等需要DN间数据交互的场景下，CN将执行计划下发给DN，DN间通过Streaming算子完成数据聚合。
- 并行执行：节点间支持DDL、DML等SQL语句并行执行；节点内支持基于数据页的并行查询。
- CSN 提交序列号 代替活跃事务列表 进行可见性判断 ，其中，CSN 是GTM 在事务提交时下发的全局唯一递增序号（uint64） ，作为事务提交的版本号 ；事务只在提交时 连接 GTM，且节点间仅需一个 CSN，比元组提交时的 CSN 与快照 CSN 的大小，事务结束的 CSN 小于快照 CSN 则元组可见，否则不可见。过程中无需遍历事务列表，提升了事务可见性判断效率。事务管理节点GTM ，通过无锁原子操作 提供CSN序号 ，不存全局单点瓶颈。节点间事务交互仅需要一个CSN ，大大降低各节点间事务状态同步 的网络开销。事务开始时按隔离级别从 GTM-Lite 获取一个 CSN 值作为查询快照点；可重复读只在事务开始时取一次，读已提交每次 SELECT 都重新取。
- 基于NUMA-Aware实现高性能事务处理：全局数据结构NUMA（非统一内存访问（Non-Uniform Memory Access），避免争抢内存总线）化改造。通过工作进程NUMA绑核、全局数据结构NUMA分区化改造，减少跨核、跨处理器竞争冲突。多核原生指令级优化。将多个指令汇聚成1个指令，提升指令效率。
- Scale-out在线横向扩展：通过hashbucket聚集存储和多轮追增等技术，减少锁表时间，实现应用无感知的在线扩容。通过增加服务器，实现系容量和性能的线性Scale Out。支持1000+超大分布式集群的能力，可以轻松应对海量高并发数据处理和复杂查询场景的考验。
2）GaussDB 集中式形态整体架构
- ETCD ：分布式键值存储系统（The unix "/etc" folder and distributed systems），用于共享配置 和服务发现（服务注册和查找）。
- CMS：集群管理组件（Cluster Management Server），是用于管理集群状态的部件。
- Data Node：数据节点DN，负责存储业务数据、执行数据查询任务以及返回执行结果。
2.3、主要概念解析
1）GTM-Lite
GTM-Lite是华为云GaussDB数据库中的一种轻量级全局事务管理模式，核心思路是在保证分布式事务强一致的前提下，消除传统单GTM的性能瓶颈。它介于标准GTM和GTM-Free之间：标准GTM由中心节点统一分配全局事务ID，高并发下容易成为单点瓶颈；GTM-Free则完全不与GTM交互，一致性较弱。GTM-Lite采用"本地事务ID + 全局CSN"的方式，把GTM的压力降到最低。
传统的GTM模式下，每个事务都需要从GTM获取一个全局唯一的事务ID。当并发量大时，GTM需要频繁地分配和管理全局事务ID ，成为性能瓶颈。GTM-Lite引入本地事务机制，每个节点（CN/DN）都使用本地来产生的事务ID，只要保证节点内事务ID不会重复。只有当触发跨节点 的事务，才需要GID保写+CSN保读 ，通过全局唯一的GID 标识符前缀来保证写一致性，由全局唯一的CSN号来保证事务读的一致性。这样，大多数情况下，事务只需要在本地节点上完成事务ID的分配和管理，无需与GTM进行交互，从而减少了网络通信和锁等待的开销。
| 模式 | GTM压力 | 一致性 | 适用场景 |
|---|---|---|---|
| GTM | 最大，易成瓶颈 | 分布式事务强一致 | 默认模式，兼容性最好 |
| GTM-Lite | 明显减轻 | 分布式事务强一致 | 高并发、短查询TP场景 |
| GTM-Free | 无中心节点 | 仅读外部一致性 | 追求极致性能，可接受最终一致 |
- 本地事务ID 取代全局事务ID：各CN/DN节点本地生成事务ID ，跨节点时用全局gid 保证写一致性 、用全局csn 保证读一致性 ，不再需要每个事务都在GTM注册槽位。
- GTM只在下发CSN时介入 ：事务提交时才向GTM申请一个递增 的uint64序列号，消除了BEGIN和获取事务ID时的GTM交互；提交失败还可以重试获取新CSN。
>* 脏元组回收与快照判断优化 ：本地维护过期元组回收，引入Snapshot Invalid 机制保证一致性；单节点读事务直接用本地快照+prepared array判断可见性，不再向GTM申请快照。
注： GTM-Lite技术通过引入本地事务ID和CSN序列号等机制来减少与GTM的交互次数，这在一定程度上降低了系统的一致性保障能力。在极端情况下，可能会出现数据不一致的问题。因此，在使用GTM-Lite技术时，需要谨慎考虑系统的一致性需求和容错能力。而引入多版本过期脏元组的回收和Prepared Array链表等机制来优化事务可见性判断，这在一定程度上增加了故障恢复的复杂性。在节点故障或网络中断等情况下，系统需要采取额外的措施来保证数据的完整性和一致性。如果系统需要与其他分布式数据库系统进行交互或集成，使用GTM-Lite技术时，需要考虑系统的兼容性和迁移成本，可能需要额外的开发工作来支持GTM-Lite技术的使用。
2）GTM(Global Transaction Manager，即全局事务管理器)
GTM是分布式数据库系统中负责事务管理的重要组件。在事务开始和提交时，系统会与GTM进行交互，获取必要的全局事务信息，包括事务ID、全局时间戳、全局快照等。GTM确保事务的唯一性和全局一致性，通过管理全局事务ID和全局快照，为分布式事务提供必要的支持。为保证事务的唯一性和全局一致性，集群中通常只有一个主GTM参与事务管理。这导致所有需要获取事务唯一标识和全局快照的事务都需要与GTM进行交互，在大并发的情况下，频繁的交互会带来大量的网络通信和锁等待，从而限制了集群的性能，且存在GTM单一瓶颈和故障；
因此，为解决GTM的单点瓶颈问题，业界提出了GTM-Lite技术，它是其中一种较为成熟和有效的解决方案。GTM-Lite技术的核心目标是在消除GTM瓶颈影响的同时，通过更少的信息交互，协调好事务的并发，从而保证事务一致性的同时提升系统性能。
3）槽位
槽位表就是哈希表里预先划分好的存储格子（也叫桶/bucket），数量在创建时固定。存数据时先算哈希值，再对槽位数取模得到槽位号，比如 hash("abc") % 100 = 67 就落到第 67 号槽位。不同哈希值可能落到同一槽位，这就是哈希冲突，一般用链表解决。
传统的GTM模式下，GTM需要维护一个槽位表来记录当前活跃事务的信息。每个事务在开始时需要在GTM注册一个槽位，在结束时需要释放该槽位。这导致在并发量大的情况下，GTM需要频繁地更新和管理槽位表，成为性能瓶颈。GTM-Lite技术通过引入CSN（Commit Sequence Number）序列号，解决了这个问题。在GTM-Lite模式下，GTM不再维护槽位信息 ，仅在事务提交时 下发一个全局唯一的CSN序列号。这个CSN序列号是一个 递增的uint64值** ，用于标识事务的 提交顺序 。事务在提交时，将CSN序列号与本地事务ID一起提交给GTM进行持久化 。这样，GTM只需要在事务提交时进行一次写操作，无需维护复杂的槽位表，从而减少了网络通信和锁等待的开销。
4）脏元组表：已经删除但尚未被回收的元组 --替代---全局快照视图
传统的GTM模式下，为了保证事务的一致性，系统需要维护一个全局的快照视图来记录当前活跃事务的状态。这导致在事务提交时，系统需要遍历全局快照视图来检查是否存在与当前事务冲突的未提交事务。这个过程不仅耗时费力，还可能导致大量的网络通信和锁等待。GTM-Lite技术通过引入Snapshot Invalid 机制，解决了这个问题。在GTM-Lite模式下，系统不再维护全局的快照视图，而是通过本地维护多版本过期脏元组 的回收来保证事务的一致性。每个节点在本地维护一个脏元组表 ，记录已经删除但尚未被回收 的元组信息。当事务提交时，系统根据CSN序列号 来判断哪些脏元组需要被回收。这样，系统无需遍历全局快照视图，只需在本地进行脏元组的回收操作，从而减少了网络通信和锁等待的开销。
5）Prepared Array链表：记录已经提交但尚未被回收的事务ID
传统的GTM模式下，对于单节点的读事务，系统需要向GTM申请快照来进行可见性判断。这个过程不仅耗时费力，也会有大量的网络通信和锁等待。GTM-Lite技术通过引入Prepared Array链表 对单节点事务可见性 判断进行优化。在GTM-Lite模式下，对于单节点的读事务 ，系统不再向GTM申请快照，而是使用本地的快照 +Prepared Array链表 来进行可见性判断。Prepared Array链表是一个本地的数据结构，用于记录 已经提交但尚未被回收的事务ID 。当读事务开始时，系统根据本地快照和Prepared Array链表来判断哪些事务是可见的。这样，系统无需向GTM申请快照，只需在本地进行可见性判断操作，从而减少了网络通信和锁等待的开销。