GaussDB(DWS)中vacuum为何对列存表无效？【这次高斯不是数学家】

GaussDB(DWS)中vacuum为何对列存表无效？

在OLAP分析型应用场景中，列式存储有十分明显的优势，相比行式存储，其高压缩比、高I/O效率及批量数据运算的特性极大提升了统计分析查询的效率。虽然存储模式不同，对列存表进行频繁的插入（insert）和更新（update）操作仍然会导致空间膨胀问题，实际上在很多时候，往往不建议对列存表进行数据更新和非批量方式的数据插入。

基于GaussDB(DWS)的mvcc机制，行存表在删除、更新数据时会保留原来的旧数据，这些数据我们称之为死元组（dead tuple）。频繁地对行存表执行删除和更新操作会导致数据页中产生大量的死元组，不但使存储空间膨胀，而且降低了对表的查询效率。针对这一现象，GaussDB(DWS)采用vacuum机制来清除不需要的死元组及索引，释放空间。但对于列存表来说，vacuum是无效的，必须使用vacuum full才能有效回收空间。

当然对行存表执行vacuum回收空间是有限的，在某些情况下vacuum后的表大小甚至不会有丝毫变化。这是因为如果删除的记录位于表的末端，其所占用的空间将会被物理释放并归还操作系统，而如果不是末端数据，会将表中或索引中dead tuple所占用的空间置为可用状态，从而复用这些空间。

对列存表执行vacuum为什么是无效的呢？其实这与列存表的存储结构以及数据写入方式有关。

从下图中可知，列存表的最小存储单元是CU（Compress Unit），每个CU的大小为8KB的整数倍（需要注意的是，CU并不是由页组成的，它是一个独立的存储单元），最多存储1列60000行数据。同一列的多个CU连续存放在一个数据文件中，当数据文件的大小超过1G，会自动切换到新的文件中。

除此之外，每个列存表还有一个记录CU的辅助和管理信息的行存表CUDesc表，该表中的每一行记录对应一个CU，包括最大值/最小值、数据条数，以及CU在文件中的偏移量及大小。其中，col_id=-10的行为VCU， cu_pointer记录这一组CU（cu_id相同）中哪些行被删除。另外，CU的可见性也是通过CUDesc的可见性来决定的。

当在列存表上导入数据时，首先数据会按列导入CU cache，如果设置了PCK（Partial Cluster Key），导入数据会按照指定列进行局部排序（默认420万条数据进行排序），最后再生成CU（生成CU时，会根据数据类型进行压缩），并写入文件。列存表推荐使用批量方式导入数据，如insert into select/copy、GDS、SQL on Hadoop/OBS等，这样可以充分利用CU空间，以及使用PCK索引。单行数据插入会产生较多的小CU文件，不但会造成空间浪费，还会导致访问效率降低。因此对于列存表的数据导入，强烈推荐使用批量方式。

下面我们看看列存表上的删除和更新操作是如何进行的。

在列存表上进行delete时，首先会根据删除条件找到需要删除的行ctid（cu_id,offset）,然后对需要删除的行ctid去重（每420万行排序去重），最后在行对应的VCU的delete map上打上删除标记。至于update操作，实际上是一个delete+insert（append）操作。首先根据更新条件找到更新的行，打上删除标记（ctid需去重），然后将原来整行更新相应数据后，插入到新CU中。

对行存表来说，数据页中的每个元组都占用了一块独立的空间，每个元组有一个行指针，记录了这个元组的状态。当执行update或者delete操作后，死元组的行指针lp_flags的状态会被标记为3: LP_DEAD，即死亡状态，等待vacuum清理。倘若执行了vacuum，指针状态会被标记为0: LP_UNUSED，即未使用状态，表示该元组占用的空间可以被复用。

虽然列存表可以像行存表那样对被删除或者更新前的数据进行标记，但由于CU中的数据是按列连续存放的，CU生成数据后固定不可更改。如果使用指针对每一个数据位的状态进行标记，其代价较大（行指针长度几乎等于数据长度，同时I/O开销巨大），而且数据写入CU采用的是追写（append）方式，即便死元组被标记为可复用状态，也无法再使用这些空间。

另外，列存表的读取是以CU为单位，真正影响列存表性能的是CU文件数量，而vacuum即便可以回收死元组占用的空间，却不能合并小CU文件。因此，对列存表来说，vacuum是无效的。此时，可以使用vacuum full整理CU碎片，合并小CU文件，提升性能。

【这次高斯不是数学家】有奖征文火热进行中：https://bbs.huaweicloud.com/blogs/345260