openGauss列存的页面组织结构

上面9.3.1讲到了CUDesc表以及其用来记录元信息的目的。CUDesc的典型结构如图9-28。

9-28 CUDesc的典型结构

其中：

_rowTupleHeader为传统行存记录的行头，其中包含了前面提到过的事务以及位置信息等，用来进行可见性判断等。

cu_mode实际为此CUDesc对应CU的infomask，记录了一些CU的特征信息（比如是否Full，是否有NULL等等）

magic是CUDesc与CU文件之间校验的关键信息。

min/max（最小值/最大值）为稀疏索引，后续会进一步展开。

而CU文件本身结构，则如图9-29所示。

图9-29 CU文件本身结构

列存储在CUDesc表的存储信息基础上设计了一套与上层交互的操作API。除了上面列存储的页面组织结构以及文件管理中天然可以展示出的结构机制之外，列存储还有一些关键的技术特征：

• 列存储的CU中数据的删除，实际上是标记删除。删除操作，相当于是更新了CUDesc表中CU对应CUDesc记录的delete bitmap（删除位图）结构，标记列中某行对应数据已被删除，而CU文件数据不会被更改。这样可以避免删除操作带来的IO放大以及解压、压缩的高额CPU开销。这样的设计，也可以使得对于同一个CU的select（查询）和delete（删除）互不阻塞，提升并发能力。
• 列存储CU中数据更新，则是遵循append-only（仅允许追加）原则的，即CU文件仅会向后进行延展扩充，亦或是启用新的CU文件，而不是在对应行在CU中的位置就地更新。
• 由于CU以及CUDesc的元数据管理模式，原有系统中的Vacuum机制实际上并不会非常有效的清除CU中已经失效的存储空间，因为Lazy Vacuum（清理数据时，只是标识无用行的状态可以录入新数据，不会影响对表数据的操作）仅能在CUDesc级别进行操作，在多数场景下无法对CU文件本身进行清理。列存储内部如果要对列存数据表进行清理，需要执行Vacuum Full（除了清理无用行，还会合并数据块，整个过程会锁定表）操作。