介绍GBase 8C核心技术

介绍GBase 8C核心技术

一. Gbase 8c核心技术
1.1  自适应事务处理机制

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

1.2  数据分布策略

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

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

表类型

*** 作类型

性能表现

适用场景

复制表

插入

较慢

字典表

小表

查询（JOIN）

快/高并发/线性提升

分布表

插入

快/高并发/线性提升

事实表

超大表

易分片的表

查询（多表单片）

快/高并发/线性提升

查询（单表多片）

较快

查询（多表多片）

慢

避免出现

复制表-分布表混合

复制表对单一分布表

JOIN 查询

较快

主题表-事实表

字典表-事实表

小表-超大表

1.3  并行技术

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

1．分布式并行计划器，结合集群特征，对算子进行分布式处理，生成合适的分布式执行计划；

2．通过基于规则和基于代价的优化，保证执行计划的高效；

3．调度器采用异步 I/O 等技术，确保调度的高效、可靠；

1.4  分布式查询

对于分布式查询，根据关联表类型的不同分为：复制表+复制表、复制表+分布表、分布表+分布表，数据落在相同HG上、分布表+分布表，数据落在不同HG上四种情况。

1.4.1     复制表+复制表

1.   应用发出查询SQL；

2.   CN解析SQL，计算出SQL涉及的表均为复制表；

3.   向本HG发送SQL；

4.   获得结果返回应用。

5.   这类查询不涉及数据移动，无临时计算结果，查询性能高，支持高并发，性能线性提升。

1.4.2     复制表+分布表

1.   应用发出查询数据SQL；

2.   CN根据查询条件判断包含复制表和分布表，则分别向HG-1、HG-2、HG-3查询数据，并获得每个节点上的结果；

3.   合并结果并返回。

这类查询性能较高，高并发的支持不如只涉及单组情况，适于大表的存储。

1.4.3     分布表+分布表

分布表+分布表的查询，分为数据落在相同HG上和不同HG上两种类型。

数据落在相同HG上时原理如下：

TD1和TD2皆为分布表，以uid为分片列：

1.   CN接收到SQL后，根据集群元数据存储的分片规则，确认此次查询仅涉及HG-1；

2.   把SQL语句直接发送给HG-1，获得执行结果；

3.   CN将结果返回给用户。

这类查询性能高，无冗余 *** 作，支持高并发，性能线性提升。

数据落在相同HG上时原理如下：

TD1和TD2皆为分布表，以uid为分片列：

1.   CN接收到SQL后，根据集群元数据存储的分片规则，根据TD1表的分片规则，生成分布SQL语句；

2.   把SQL语句发送给HG-1数据引擎执行；

3.   HG-1拉取其他HG上TD2表uid<60的数据；

4.   进行JOIN查询计算；

5.   HG-1将结果返回给CN；

6.   CN返回给用户。

这类查询性能较差，涉及数据移动，跨节点拉数据，网络传输是瓶颈。

1.5  全局死锁解除

Gbase 8c具备全局死锁解除的能力。当发现死锁情况时，会将全局事务号最大的事务退出，从而解决死锁问题。

Gbase 8c通过在CN和DN上部署global deadlock process并与GTM建立通讯通道，周期性的对事务等待关系进行检测，并将检测结果发送给GTM用来构建全局等待图。当检测到死锁环时，立即将执行事务号最大的事务执行退出流程，从而解决全局死锁问题。

1.6  事务状态保持

Gbase 8c具备事务状态保持能力，任意协调器节点（CN）宕机后，都不影响该节点正在进行的事务状态，事务可以在另一接管CN节点上继续顺利运行，从而保证数据库处理能力。

如上图所示两阶段提交事务处理过程中：

1、CN2节点正常下发事务Prepare状态；

2、三个DN节点正常返回事务Prepare OK状态；

3、CN2节点正常下发事务Commit状态；

4、DN1节点返回Commit OK状态且DN2、DN3还未完成Commit OK状态提交时，CN2节点宕机；

5、此时CN3节点检测到CN2节点宕机，会自动接管CN2未完成的事务和状态；

6、DN2、DN3节点重新提交Commit OK状态至CN3节点，并完成该两阶段提交过程。

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

1.7  备份恢复

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

Gbase 8c提供全面的基于集群级、库级、表级的备份和恢复功能，包括：

1．全量备份和恢复；

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