GBase 8c 核心技术介绍

核心技术

向量引擎能力

GBase 8c支持向量数据与标量数据混合存储能力，可以解决图像和文本混合查询的跨模态模型检索。GBase 8c能够为不同的类型的向量数据提供统一的存储和检索的支持能力，这种能力对于涉及多种输入数据类型的大模型至关重要，能够实现跨模态的检索与融合能力。

• 支持向量类型：不仅支持标准向量，还支持半向量、稀疏向量、位向量等多种向量类型，可以适应AI应用中的多样化需求。稀疏向量非常适合机器学习和深度学习模型中的特征表示，而位向量可以处理更加紧凑、高效的二进制特征数据，支持高效存储与查询。

• 向量快速检索和查询：GBase 8c向量引擎能够在数据库层面进行向量化的数据处理和查询优化，对于大模型应用，数据库能够根据查询的特点自动调整执行计划，提升查询效率。数据库通过自动化的查询检索优化、查询重写等方式能够减少AI模型训练过程中对数据的访问延迟，从而提升数据库查询效率，降低AI模型训练时间，提供更高效的大规模数据分析和模型优化能力。

• 向量索引优化：支持ivflat、HNSW等先进的向量索引算法，能够大幅提高向量数据检索的速度和精度。这对于AI中的相似度搜索、推荐系统、图像识别、自然语言处理等任务尤为关键。

自适应事务处理机制

GBase 8c采用自适应的事务处理机制来提升系统性能。对于只需要在本地节点进行处理的事务，协调器按本地事务处理流程进行处理，不需要进行两阶段提交，以提升事务处理的效率；对于需要跨节点处理的事务，协调器协调参与者进行两阶段提交，以保障全局事务的一致性。整个事务处理的流程对客户端透明。

数据分布策略

GBase 8c支持复制表和分布表，通过数据分布策略来避免并行计算期间的资源竞争，同时提升系统性能。复制表是指每个节点上都复制一份数据，数据关联时在节点本地完成。分布表是指一份数据根据某个键值水平拆分到不同的节点上，将单个大表拆分成若干小表，提升系统读写的性能。

复制表和分布表的适用场景如下：

高性能

并行技术

GBase 8c采用并行技术来提升系统的性能和吞吐量，主要特点有：

• Coordinator协调器制定分布式执行计划，将算子下推到数据节点，数据节点并行处理；

• 各数据节点采用多线程架构，多个线程并行处理；

• 采用MVCC（多版本并发控制）技术，实现读写不冲突，提升读写并行处理能力；

• 支持并行查询，可以解决在复杂查询场景中，单个查询的执行时间过长造成系统并发度降低，从而影响数据库对外服务性能的问题。

原位更新

PostgreSQL使用多版本并发控制MVCC机制：

• 当执行delete时，数据库将删除元组直接标记为dead，并不会真正从物理上删除；

• 当执行update时，数据库将会使用unused空间写入一个新的元组，然后将旧元组标记为dead，也不进行物理删除；

• 当表上频繁DML时，dead tuple会逐渐将空间耗尽，同时做全表扫描时产生很多额外I/O。

GBase 8c采用原位更新技术：

• 将new tuple放在原位，将dead tuple集中存放在undo；

• 去除vacuum，保证数据回收时IO稳定；

• 数据空间缩减。

PG 采用追加更新方式存储数据，也就是当修改数据时，不是在原位置修改，而是写入一个新记录，这会导致空间膨胀，也就需要定期回收过期的数据空间。这一直是 PostgreSQL 的一个弱项。

而GBase 8c实现了 Undo 机制，也就可以在原位置更新数据。这带来的好处包括：

• 高性能：对插入、更新、删除等不同负载的业务，性能以及资源使用表现相对均衡，相比Append Update引擎性能提升10%；

• 运行平稳：性能运行平稳，8小时性能滚降值从13.8%降低至2.5%；

• 高效存储：支持最大限度的原位更新, TPCC负载下平均节约空间15%~20%，UNDO空间统一分配，集中回收，复用效率更高，存储空间使用更加高效、平稳。

算子下推

算子下推是GBase 8c关键技术之一，可以把各种复杂的SQL进行下推执行，最小化数据移动，这是相对于基于分库分表的中间件方案的核心优势。

单表查询下推

单表查询，不管SQL的where条件是否带有分片键，优化器都可以生成下推的执行计划，包括sort/group by等复杂算子，都可以下推。

（1）分片键上的where条件，直接下推到对应DN执行：

EXPLAIN SELECT * FROM td1 WHERE a=18 ORDER BY b;

例如返回：

QUERY PLAN
------------------------------------------------------------
Remote Fast Query Execution  (cost=0.00..0.00 rows=0 width=0)
Node/s: dn2
->  Sort  (cost=38.44..38.47 rows=11 width=8)
Sort Key: b
     ->  Seq Scan on td1  (cost=0.00..38.25 rows=11 width=8)
           Filter: (a = 18)
(6 rows)

（2）非分片键where条件:DN先计算，CN做结果汇总，group by可以直接下推到DN：

EXPLAIN SELECT * FROM td1 WHERE b=18 ORDER BY b;

例如返回：

QUERY PLAN
------------------------------------------------------------
Remote Subquery Scan on all (dn1,dn2,dn3)  (cost=0.00..1.01 rows=1 width=8)
->  Seq Scan on td1  (cost=0.00..1.01 rows=1 width=8)
Filter: (b = 18)
(3 rows)

Join查询下推

（1）分片键上的join条件，直接下推到对应DN执行：

EXPLAIN SELECT * FROM td1,td2 WHERE td1.a=td2.c ORDER BY a;

例如返回：

QUERY PLAN
------------------------------------------------------------
Remote Subquery Scan on all (dn1,dn2,dn3)  (cost=2.04..2.05 rows=1 width=16)
->  Sort  (cost=2.04..2.05 rows=1 width=16)
Sort Key: td1.a
     ->  Nested Loop  (cost=0.00..2.03 rows=1 width=16)
           Join Filter: (td1.a = td2.c)
           ->  Seq Scan on td1  (cost=0.00..1.01 rows=1 width=8)
           ->  Seq Scan on td2  (cost=0.00..1.01 rows=1 width=8)
(7 rows)

（2）非分片键join条件，DN直接做数据交换，避免CN成为性能瓶颈：

EXPLAIN SELECT * FROM td1,td2 WHERE td1.b=td2.b ORDER BY a;

例如返回：

QUERY PLAN
------------------------------------------------------------
Remote Subquery Scan on all (dn1,dn2,dn3)  (cost=2.04..2.05 rows=1 width=16)
->  Sort  (cost=2.04..2.05 rows=1 width=16)
Sort Key: td1.a
     ->  Nested Loop  (cost=0.00..2.03 rows=1 width=16)
           Join Filter: (td1.b = td2.b)
           ->  Remote Subquery Scan on all (dn1,dn2,dn3)  (cost=100.00..101.02 rows=1 width=8)
                 Distribute results by H: b
                 ->  Seq Scan on td1  (cost=0.00..1.01 rows=1 width=8)
           ->  Materialize  (cost=100.00..101.03 rows=1 width=8)
                 ->  Remote Subquery Scan on all (dn1,dn2,dn3)  (cost=100.00..101.02 rows=1 width=8)
                       Distribute results by H: b
                       ->  Seq Scan on td2  (cost=0.00..1.01 rows=1 width=8)
(12 rows)

• Join下推到DN执行，DN之间直接进行数据重分布，交换数据，无需CN参与；CBO优化器选择小表t2做重分布；

• Sort下推到DN，CN只需做归并排序，避免CN成为性能瓶颈；

高可用

主备式高可用架构

GBase 8c主备式版本支持数据多副本冗余，主备副本之间通过日志进行数据交换，保证集群任意节点故障均不影响数据库对外提供服务，数据无丢失，满足ACID特性。

当主节点故障（包括但不限于服务器故障、数据库服务故障、断网、断电、硬盘故障等）时，备节点可以自动升级为主，并继续对外提供服务。该过程对应用透明，不受主备IP地址限制，即当备机被拉起后会自动被赋予当前应用正在连接的IP地址，整个主备切换过程应用无感知，不影响对外服务。

如图所示，GBase 8c提供VIP（Virtual IP）功能，应用直接连接VIP以访问数据库主节点。当数据库发生主节点异常导致的主备切换时，无需人工切换应用连接的IP地址，集群会自动将VIP绑定至新的主节点上，以完成集群自动切换并对上层应用无感知的目的。

GBase 8c主备式部署主备之间支持同步及异步的备份方式，一般异地灾备的节点会采用异步的备份方式，本地的备份节点会采用同步的备份方式。

分布式高可用架构

GBase 8c高可用架构是通过分布式全组件冗余实现的，即在软件层，针对分布式集群中的每个组件，均做了组件级冗余。

• 协调器CN：采用完全对等的部署方式；

• 数据节点​DN​：采用主备的高可用架构，主备之间可以配置同步或异步方式；

• 全局事务管理器​GTM​：采用主备的高可用架构，主备之间可以配置同步或异步方式；

• 集群状态管理器​HA Center​：采用Raft的复制协议；

• 集群管理器​GHA Server​：采用主备的高可用架构，主备之间可以配置同步或异步方式；

GBase 8c可以满足各种应用场景下对数据库不同的高可用需求。

1.同机房容灾：采用同机房主从互备方案，可以抵御硬件级别故障，不能抵御城市级别和机房级别灾难。故障自动切换，RPO=0，RTO秒级。

2. 同城容灾：采用同城主从互备方案，可以抵御硬件级别故障和机房级别灾难，不能抵御城市级别灾难。故障自动切换，RPO=0，RTO秒级。同城容灾需要其中两机房之间距离小于50千米。

3．异地灾备：GBase 8c集群不同节点采用各自对应的高可用部署方式，两地间采用异步复制的备份方式。可以抵御硬件级别故障和机房级别、城市级别灾难，两地之间距离可以大于1000千米。

4．异地多活：GBase 8c支持多集群部署，集群间数据双向同步，数据以某一维度进行分区调度。可以抵御硬件级别故障和机房级别、城市级别灾难，两地之间距离可以大于1000千米。

分布式事务

GBase 8c通过GTM全局事务管理器和本地两阶段提交技术，提供分布式强一致事务的能力，同时，对于追求性能的新兴数据库业务，也支持可选的最终一致性事务的能力。

分布式事务原子性和两阶段提交协议

为了保证分布式事务的原子性，防止出现部分DN提交、部分DN回滚的“中间态”事务，GBase 8c采用两阶段提交（2PC）过程，实现跨节点分布式事务。

1. 准备阶段（prepare phase）：在这个阶段，将所有提交操作所需要使用到的信息和资源全部写入磁盘，完成持久化；

2. 提交阶段（commit phase）：根据之前准备好的提交信息和资源，执行提交或回滚操作。

一旦准备阶段执行成功，那么提交需要的所有信息都完成持久化落盘，即使后续提交阶段某个DN发生执行错误，该DN可以再次从持久化的提交信息中尝试提交，直至提交成功。最终该分布式事务在所有DN上的状态一定是相同的，要么所有DN都提交，要么所有DN都回滚。因此，对外来说，该事务的状态变化是原子的。

分布式事务一致性和全局事务管理

GBase 8c采用了基于全局事务提交时间戳的TSO方案，保证分布式事务一致性。处理流程如下图所示：

1. GTM负责维护全局时间戳CSN；

2. 当开启事务时从GTM获取当前的时间戳

3. 当事务提交的时候重新获取一遍时间戳（CSN+1）

这种方式的优势在于：

• 使用全局逻辑时间戳CSN号替代传统的活跃事务列表作为全局快照，可以大幅降低所有节点到事务管理器GTM节点的网络开销，使得全局事务管理节点不再容易成为分布式事务处理的瓶颈节点；

• 使用逻辑时间戳CSN号本质上是为所有的写事务在全局进行内部排序，为处理数据库双相同步等方面提供了便捷。

示例：

begin; //Transaction Start

    select * from t1 where id = 1; //单节点查询

    select * from t1, t2 where t1.id = t2.id;//跨节点查询

    insert into t1 values(1, “aaa”); //单节点写入

    update t1 set name = ”bbb” where id = 1; // 单节点更新

    delete from t2 where id < 10; //跨节点删除

commit; //Transaction Commit

该分布式事务的交互关系：

全局死锁解除

信息

​全局死锁概念：在数据库集群内，多个CN、DN上的多个数据库进程间互相调用资源而出现循环等待的情况，称为全局死锁。

如下图示意：

在T1时刻，事务一Begin；

在T2时刻，事务一update id=1的t值，同时事务二Begin；

在T3时刻，事务二update id=4的t值；

在T4时刻，事务一要更新id=4的t值，同时事务二要更新id=1的t值，此时两事务出现循环等待，就发生了全局死锁的情况。

而在GBase 8c数据库中，节点间检测出死锁环之后，将首个发现死锁环节点的事务退出的操作，从而解决全局死锁的问题。

事务状态保持

GBase 8c具备事务状态保持能力，任意协调器节点（CN）宕机后，都不影响该节点正在进行的事务状态，事务会自动迁移到其它CN上，继续顺利运行，确保数据库处理能力不会中断。

上图中CN3节点接管事务后，无需重复前面已经成功提交的事务状态，而是继续完成宕机的CN2节点未完成的状态来完成本次事务。整个过程对上层业务无感知，数据库集群内任意节点宕机均不会造成死锁或异常等待情况。

全局CDC

GBase 8c支持全局CDC(Change Data Capture，变化数据捕获)特性，方便用户进行数据库的全局备份和数据抽取。CDC变化数据捕获的方式主要包括时间戳、快照、触发器和日志，其中GBase 8c 基于日志的CDC方式，对源数据库的性能不会产生影响。

备份恢复

海量的业务数据不仅仅给数据处理和分析查询的性能带来挑战，对数据备份和恢复的要求也更高。因为数据量巨大，如果没有高效的备份和恢复能力，在意外、故障或灾难发生时，无法及时使数据库得到恢复，系统和业务的可用性就无法得到保障。

GBase 8c集群具有全局备份和恢复的能力，支持全量备份、恢复，支持增量备份、恢复。在通用管理平台上，可以进行备份方式和备份时间频率的配置，并且能够查看全部的备份记录。提供全面的基于集群级、库级、表级的备份和恢复功能，包括：

• 全量备份和恢复，基于全量数据的备份恢复。

• 增量备份和恢复，允许基于任意一个备份点进行数据恢复。

支持并行恢复

主机日志传输到备机时，备机日志落盘的同时，发送给重做恢复分发线程，分发线程根据日志类型和日志操作的数据页发给多个并行恢复线程进行日志重做，保证备机的重做速度跟上主机日志的产生速度。这样备机实时处于ready状态，从而实现瞬间故障切换。

读写分离

GBase 8c支持语句级及连接级读写分离。其中，语句级读写分离，可以自动识别读、写请求，并分别分配至主、备节点；连接级读写分离支持通过配置连接的方式，将读写连接配置在主节点，将只读连接配置在备节点。