GaussDB关键技术原理|高弹性：hashbucket介绍

从GaussDB数据库DCF、双集群容灾、逻辑复制及两地三中心跨Region容灾方面对GaussDB高可用能力进行了解读。本篇将分享GaussDB高弹性方面的相关知识，从CBI索引方面对hashbucket展开介绍。

1 前言  

GaussDB支持hash分布表，hash分布表的数据行根据hash分布列进行hash计算，计算出的hash值被打散到各个DN。随着业务增长数据规模变大，DN的承载能力会逐渐不够，这样就需要对DN节点数量进行扩充。节点数量扩充后，存储于原DN节点的数据就需要进行数据重新分布。目前GaussDB采用的是share-nothing的本地盘架构，各个DN节点独立维护各自的数据，这种架构下数据重分布的难度很大。

如下图x所示，在线扩容从时间轴上看主要由两部分组成：

图x  在线扩容示意图

• 集群加节点阶段：对新加入的DN节点进行元信息的同步，然后更新集群拓扑，启动新节点。设置包含新节点的Installation NodeGroup信息，将老集群的NodeGroup设置为待重分布的状态。

• 数据重分布阶段：对分布在老集群的用户表通过数据重分布搬迁至新集群，在新加节点完成业务上线。数据重分布主要有两种方式，一种逻辑搬迁方式，主要通过SQL接口进行，另一种是物理搬迁的方式，直接通过文件拷贝和日志多流追增进行。本节主要介绍逻辑数据重分布的过程。    

由此可见，在线数据重分布是在线扩容的关键步骤。目前已经支持了以表为粒度的逻辑数据重分布，其核心思想是采用SQL接口将原表的数据导入到一个按照新分布方式存储的新表上，然后进行两个表的元数据切换。处理在线业务的核心思想是：将DML操作的UPDATE拆分成INSERT和DELETE，所有INSERT都采用追增写入的模式，写入原表的尾部，通过CTID确定每轮处理数据的范围，使用“{节点ID}+{元组ID}”表示删除的元组位置，原表的数据直接删除，新表的数据追增删除，直至原表和新表数据收敛追平，详细步骤如下图x。

图x  重分布过程中在线业务处理过程

P1：将原表设置为追增模式，创建新表（新增两列表示元组ID和节点ID）、delete_delta表记录删除原组的位置信息，并将新表索引失效，提升基线数据批量插入的效率。

P2_1：采用“insert into 新表select * from 原表”的方式完成基线数据的插入。此时用户业务采用追加写的方式写在原表的后面，删除的数据直接进行删除并且将原组ID和节点ID记录在delete_delta表中。

P2_2：重建新表的索引，此阶段引入了并行建索引来提升重建索引的效率。

P3：采用多轮追增（推进CTID、DELETE、INSERT）的方式完成新表和元数据的数据追平。    

P4：拿原表的8级锁，完成元数据切换，保留原表的元信息和新表的数据文件信息。

逻辑数据重分布的方式比较类似于VACUUM FULL的运行机制，存在很多约束和限制。首先新老表同时存在，会占用双份磁盘空间影响磁盘的利用率。其次，如果要支持在线的数据重分布，采用SQL接口的方式挑战会比较大，例如表锁冲突，shared-buffer资源争抢等问题。如果两个具有相同分布规则的表需要进行JOIN操作，重分布期间可能存在一个表完成数据重分布，另一个表没有完成，这个阶段两个表就可能存在跨节点的分布式JOIN，与原有的本地JOIN相比性能会下降十分严重。

为了解决逻辑扩容在有复杂业务查询场景在线业务的性能劣化问题，我们引入了基于hashbucket表的物理在线扩容方案，不仅可以很好地解决带有JOIN关系业务性能下