openGauss存储技术（二）——列存储引擎和内存引擎

上一篇内容我们介绍了openGauss存储技术（一）——行存储引擎，本文重点介绍openGauss列存储引擎和内存引擎。

openGauss列存储引擎

传统行存储数据压缩率低，必须按行读取，即使读取一列也必须读取整行。在分析性的作业以及业务负载的情况下，数据库往往会遇到针对大量表的复杂查询，而这种复杂查询中往往仅涉及一个较宽(表列数较多)的表中个别列。此类场景下，行存储以行作为操作单位，会引入与业务目标数据无关的数据列的读取与缓存，造成了大量IO 的浪费，性能较差。因此openGauss提供了列存储引擎的相关功能。创建表的时候，可以指定行存储还是列存储。

总体来说，列存储有以下优势:

• 列的数据特征比较相似，适合压缩，压缩比很高，在数据量较大(如数据仓库) 场景下会节省大量磁盘空间，同时也会提高单位作业下的IO 效率。
• 当表中列数比较多，但是访问的列数比较少时，列存储可以按需读取列数据，大大减少不必要的读IO，提高查询性能。
• 基于列批量数据向量运算，结合向量化执行引擎，CPU 的缓存命中率比较高，性能比较好，更适合 OLAP大数据统计分析的场景。
• 列存储表同样支持 DML操作和 MVCC，功能完备，且在使用角度上做了良好的兼容，基本是对用户透明的，方便使用。

（一）列存储引擎的总体架构

列存储引擎的存储基本单位是 CU(Compression Unit，压缩单元)，即表中一列的一部分数据组成的压缩数据块。行存储引擎中是以行作为单位来管理，而当使用列存储时，整个表整体按照不同列划分为若干个 CU，划分方式如图1所示。

图1 CU 划分方式

如图1所示，假设以6万行作为一个单位，则一个12万行、4列宽的表被划分为8个 CU，每个 CU 对应一个列上的6万个列数据。图中有列0、列1、列2、列3四列，数据按照行切分了两个行组(Row Group)，每个行组有固定的行数。针对每个行组按照列做数据压缩，形成 CU。每个行组内部各个列的 CU 的行边界是完全对齐的。当然，大部分时候，CU 在经过压缩后，因为数据特征与压缩率的不同，文件大小会完全不同，如图2所示。

图2 示意图

为了管理表对应的CU，与执行器层进行对接来提供各种功能，列存储引擎使用了CUDesc(压缩单元描述符)表来记录一个列存储表中CU 对应的元信息，如图3所示。

图3 列存储引擎整体架构图

注:Cmn表示第 m 列的、CUid是n(第n个)的压缩单元。每个 CU 对应一个 CUDesc的记录，在 CUDesc里记录了整个 CU 的事务时间戳信息、CU 的大小、存储位置、magic校验码、min/max等信息。

与此同时，每张列存储表还配有一张 Delta表，Delta表自身为行存储表。当有少量的数据插入到一张列存储表时，数据会被暂时放入 Delta表，等到到达阈值或满足一定条件或操作时再行整合为 CU 文件。Delta表可以帮助避免单点数据操作带来的加重的 CU 操作与开销。

设计采用级别的多版本并发控制，删除通过引入虚拟列映射 (Virtual Column Bitmap)来标记删除。映射(Bitmap)是多版本的。

（二）列存储的页面组织结构

上文讲到了CUDesc表及其用来记录元信息的目的。CUDesc的典型结构如图4所示。

图4 CUDesc的典型结构

其中:

• _rowTupleHeader为传统行存储记录的行头，其中包含了前面提到过的事务及位置信息等，用来进行可见性判断等。
• cu_mode实际为此 CUDesc对应 CU 的infomask，记录了一些 CU 的特征信息(比如是否为 Full，是否有 NULL等)。
• magic是 CUDesc与 CU 文件之间校验的关键信息。
• min/max(最小值/最大值)为稀疏索引，后续会进一步展开介绍。
  CU 文件结构如图5所示。

图5 文件结构

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

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

（三）列存储的 MVCC设计

理解了 CU、CUDesc的基本结构，以及 CUDesc的管理，或者说是其“代理”角色，列存储的 MVCC设计以及管理，实际上就非常好理解了。

由于列存储的操作基本单位 CU 是由 CUDesc表中的行进行管理的，因此列存储表的CU 可见性判断也是由CUDesc的行头信息，按照传统的行存储可见性进行判断的。

同样的，列存储可见性的单位也是CU 级别(CUDesc)，不同于行存储的 Tuple级别。

列存储表的并发控制是 CU 文件级别的，实际上也等同于其 CUDesc代理表的CUDesc行之间的并发控制。多个事务之间在一个 CU 上的并发管控，实际上取决于其在对应的 CUDesc记录上是否冲突。例如:

• 两个事务并发去读一个CU 是可行的，两个事务都可以拿到此CU 对应 CUDesc 行级别的共享锁(sharelock)。
• 两个事务并发去更新一个 CU，会因为在 CUDesc上的锁冲突而触发一个事务回滚[当然，如果是读已提交(read committed)隔离级别并打开允许并发更新的开关，这里会做的事情是拿到此 CUDesc最新版 本 的 ctid，然后重运行一部分查询树 (queryTree)来进行更新操作。此部分内容，后面文章将会介绍]。
• 两个事务并行执行，一个事务对一个 CU 执行了删除操作并先行提交，则另一个事务在可重读(repeatableread)的隔离级别下，其获取的快照只能看到这个CUDesc在操作发生前的版本，这个版本的 CUDesc中的删除位图(delete_bitmap)对应数据没有被标记删除，也由于 CU 的行删除是标记删除的机制，因此数据在原有 CU 的数据文件中依旧可用，此事务依旧可以在其对应的快照下读到对应行。

删除 CU 中部分数据所进行的实际操作如图6所示。

图6 删除 CU 中部分数据所进行的实际操作

从上面的几个例子可以看出，列存储对于更新的仅允许追加策略以及对于删除操作的标记删除方式，对于列存储事务 ACID的支持，是至关重要的。

（四）列存储的索引设计

列存储支持的索引设计有:

• B树索引;
• 稀疏索引;
• 聚簇索引。

1.列存储的B树索引

列存储引擎在 B树索引的支持角度，与传统的行存储引擎无本质差别。对于一般用于应对大数据批量分析性负载的列存储引擎来说，B树索引有助于帮助列存储大大提升自身的点查效率，更好地适应混合负载。

行存储相关 B树索引的索引页面上，存储的是key→ctid(键→行号)的映射，在列存储的场景下，这个映射依旧为key→ctid，但列存储的结构并不能像行存储一样，通过ctid中的块号(block number)和偏移量(offset)直接找到此行数据在数据文件页面中的位置。列存储ctid中记录的是(cu_id，offset)，要通过 CUDesc结构来进行查找。

在基于 B树索引的扫描中，从索引中拿到ctid后，需要在对应的 CUDesc表中，根据 CUDesc在cu_id列的索引找到对应的 CUDesc记录，并由此打开对应的 CU 文件，根据偏移量找到数据。

如果此操作设计大量的存储层性能开销，因此列存储的 B树索引，与列存储的其他操作一样，统一都为批量操作，会根据 B树索引找到ctid的集合，然后对此集合进行排序，再批量地对排序后的ctid进行 CU 文件级别的查找与操作。这样可以做到顺序单调地进行索引遍历，大大减少了反复操作文件带来的 CPU 以及IO 开销。

2.列存储的稀疏索引

列存储引擎每个列自带 min/max稀疏索引，每个CUDesc存储该CU 的最小值和最大值。

那么在查询的时候，可以根据查询条件做简单的 min/max判断，如果查询条件不在(min，max)范围内，肯定不需要读取这个 CU，可以大大地减少IO 读取的开销，稀疏索引如图7所示。

图7 稀疏索引

注:txn_info表示事务信息;CUPtr表示压缩单元的指针;CU-None表示肯定不命中;CU-Some表示可能有数据匹配;CU_Full表示压缩单元数据全命中。

3.列存储的聚簇索引

列存储表在建立时可以选择在列上建立聚簇索引(partial sort index)。

如果业务的初始数据模型较为离散，那么稀疏索引在不同 CU 之间的 min、max会有大量交集，这种情况下在给定谓词对列存储表进行检索的过程中，会出现大量的CU 误读取，甚至可能导致其查询效率与全表扫描近似。如图8所示，查询2基本命中了所有 CU，min/max索引没有能够有效筛选。

图8数据模型较为离散时的查询效果图

聚簇索引可以对部分区间内的数据做相应的排序(一般区间会包含多个CU所覆盖的行数)，可以保证 CU 之前交集尽量少，可以极大地提升在数据离散场景下稀疏索引的效率。

其示意图如图9和图10所示。

图9 聚簇索引生效前

图10 聚簇索引生效后

同时，聚簇索引会使得 CU 内部的数据临近有序，提升 CU 文件本身的压缩比以及压缩效率。

（五）列存储自适应压缩

每个列自适应选择压缩,支持差分编码(delta value encoding)、游 程 编 码 (Run length encoding)、字典编码(dictionary encoding)、LZ4、zlib等混合压缩。根据数据特性的不同,压缩比一般可以有3X~20X。

列存储引擎支持低、中、高三种压缩级别,用户在创建表的时候可以指定压缩级别。

导入1TB原始数据量,分别测试低、中、高三种压缩级别,入库后数据大小分别是100GB、73GB、61GB,如图11所示。

图11 压缩比示意图

每次数据导入，首先对每列的数据按照向量组装，对前几批数据做采样压缩，根据数值类型和字符串类型，选择尝试不同的压缩算法。一旦采样压缩完成后，接下来的数据就选择优选的压缩算法了。如图12所示，面向列的自适应压缩主要分为数值压缩和字符压缩。其中对 Numeric小数类型，会转换为整数后，再进行数值压缩。对数值型字符串，也会尝试转换为整数再进行数值压缩。

图12 面向列的自适应压缩

（六）列存储的持久化设计

在列存储的组织结构与 MVCC机制的介绍中提到，列存储的存储单位由 CUDesc和CU文件共同组成，其中 CUDesc记录了CU相关的元信息，控制其可见性，实际上充当了一个 “代 理”的角色。但是CUDesc和CU，实质上还是分离的文件状态。CUDesc表本质上还是行存储表，其持久化流程遵从行存储的共享缓冲区脏页与 Redo日志的持久化流程，在事务提交前，CUDesc的改动会被记录在 Redo日志中进行持久化。单个 CU 文件本身，由于含有大量的数据，使用正常的事务日志进行持久化需要消耗大量的事务日志，引入非常大的性能开销，并且恢复也十分缓慢。因此根据其应用场景，仅允许追加(append-only)的属性及与 CUDesc的对应关系，列存储的 CU 文件，为了确保 CUDesc和 CU 持久化状态的一致，在事务提交、CUDesc对应事务日志持久化前，会先行强制刷盘(Fsync)，来确保事务改动的持久化。

由于数据库主备实例的同步也依赖事务日志，而 CU 文件并不包含在事务日志内，因此在与列存储同步时，主备实例之间除去正常的日志通道外，还有连接的数据通道，用于传输列存储文件。CUDesc的改动会通过日志进行同步，而 CU 文件则会被直接通过数据通道传输到备机实例，并通过 BCM(bitchangemap)文件来记录主备实例之间文件的同步状态。

openGauss内存引擎

内存引擎作为在openGauss中与传统基于磁盘的行存储、列存储并存的一种高性能存储引擎，基于全内存态数据存储，为openGauss提供了高吞吐的实时数据处理分析能力及极低的事务处理时延，在不同业务负载场景下可以达到其他引擎事务处理能力的3~10倍。

内存引擎之所以有较强的事务处理能力，并不单是因为其基于内存而非磁盘所带来的性能提升，而更多是因为其全面地利用了内存中可以实现的无锁化的数据及索引结构、高效的数据管控、基于 NUMA 架构的内存管控、优化的数据处理算法及事务管理机制。

值得一提的是，虽然是全内存态存储，但是并不代表着内存引擎中的处理数据会因为系统故障而丢失。相反，内存引擎有着与openGauss的原有机制相兼容的并行持久化、检查点能力，使得内存引擎有着与其他存储引擎相同的容灾能力以及主备副本带来的高可靠能力。

内存引擎总体架构如图13所示。

图13 内存引擎总体架构图

可以看到，内存引擎通过原有的 FDW(Foreign Data Wrapper，外部数据封装器) 扩展能力与 openGauss 的优化执行流程相交互，通过事务机制的回调以及与 openGauss相兼容的 WAL机制，保证了与其他存储引擎在这一体系架构内的共存，保 证了整体对外的一致表现;同时通过维护内部的内存管理结构、无锁化索引、乐观事务 机制来为系统提供极致的事务吞吐能力。

以下将逐步展开讲解相关关键技术点与设计。

（一）内存引擎的兼容性设计

由于数据形态的不同以及底层事务机制的差别，此处如何与一个以段页式为基础的系统对接是内存引擎存在于openGauss中的重点问题之一。

此处openGauss原有的 FDW 机制为内存引擎提供了一个很好的对接接口，优化器可以通过 FDW 来获取内存引擎内部的元信息，内存引擎的内存计算处理机制可以直接通过 FDW 的执行器接口算子实现直接调起，并通过相同的结构将结果以符合执行器预期的方式[比如扫描(Scan)操作的流水线(pipelining)]将结果反馈回执行器进行进一步处理[如排序、分组(Groupby)]后返回给客户端应用。

与此同时内存引擎自身的错误处理机制(ErrorHandling)，也可以通过与FDW的交互，提交给上次的系统，以此同步触发上层逻辑的相应错误处理(如回滚事务、线程退出等)。

内存引擎借助 FDW 的方式接近无缝地工作在整个系统架构下，与以磁盘为基础的行、列存储引擎实现共存。

在内存引擎中创建表(CreateTable)的实际操作流程如图14所示。

图14 内存引擎创建表的操作流程图

从图中可以看到，FDW 充当了一个整体交互 API的作用。实现中同时扩展了FDW 的机制，使其具有更完备的交互功能，具体包括：

• 支持 DDL接口;
• 完整的事务生命周期对接;
• 支持检查点操作;
• 支持持久化 WAL;
• 支持故障恢复(Redo);
• 支持 Vacuum 操作。

借由 FDW 机制，内存引擎可以作为一个与原有openGauss代码框架异构的存储引擎存在于整个体系中。

（二）内存引擎索引

内存引擎的索引结构以及整体的数据组织都是基于 Masstree实现的。其主体结构如图15所示。

图15 内存引擎索引主体结构

图15很好地呈现了内存引擎索引的组织架构。主键索引(primary index)在内存引擎的一个表中是必须存在的要素，因此要求表在组织时尽量存在主键索引;如果不存在，内存引擎也会额外生成代理键(surrogatekey)用于生成主键索引。主键索引指向各个代表各个行记录的行指针(sentinel)，由行指针来对行记录数据进行内存地址的记录以及引用。二级索引(secondaryindex)索引后指向一对键值，键的值(value)部分为到对应数据行指针的指针。

Masstree作为并行 B+树(Concurrent B+tree)，集成了大量 B+树的优化策略，并在此基础上做了进一步的改良和优化，其大致实现方式如图16所示。

图16 Masstree实现方式

相比于传统的 B树，Masstree实际上是一个类似于诸多 B+树以前缀树(trie)的组织形式堆叠的基数树(radix tree)模式，以键(key)的前缀作为索引，每k 个字节形成一层 B+ 树结构，在每层中处理键中这k 个 字 节 对 应 所 需 的INSERT/LOOKUP/ UPDATE/DELETE流程。图17为k=8时情况。

图17 k等于8时的Masstree

Masstree中的读操作使用了类 OCC(OptimisticConcurrency Control，乐观并发控制)的实现，而所有的更新(update)锁仅为本地锁。在树的结构上，每层的内部节点(interior node)和叶子节点(leaf node)都会带有版本，因此可以借助版本检查(version validation)来避免细粒度锁(fine-grained lock)的使用。

Masstree除了无锁化(lockless)之外，最大的亮点是缓存块(cache line)的高效利用。无锁化本身在一定程度避免了 LOOKUP/INSERT/UPDATE 操作互相失效共享缓存块(invalidat ecacheline)的情况。而基于前缀(prefix)的分层，辅以合适的每层中 B+树扇出(fanout)的设置，可以最大限度地利用 CPU 预取(prefetch)的结果(尤其是在树的深度遍历过程中)，减少了与 DRAM 交互所带来的额外时延。

预取在 Masstree的 设 计 中 显 得 尤 为 关 键，尤 其 是 在 Masstree 从 根 节 点 (tree root)向叶子节点遍历，也就是树的下降过程中。此过程中的执行时延大部分由于内存

交互的时延组成，因此预取可以有效地提高遍历(masstreetraverse)操作的执行效率以及缓存块的使用效率(命中)。

（三）内存引擎的并发控制

内存引擎的并发控制机制采用 OCC，在操作数据冲突少的场景下，并发性能很好。

内存引擎的事务周期及并发管控组件结构，如图18所示。

图18 内存引擎的事务周期及并发管控组件结构

这里需要解释一下，内存引擎的数据组织为什么整体是一个接近无锁化的设计。

除去以上提到的 Masstree本身的无锁化机制外，内存引擎的流程机制也进一步最小化了并发冲突的存在。

每个工作线程会将事务处理过程中所有需要读取的记录，复制一份至本地内存，保存在读数据集(read set)中，并在事务的全程基于这些本地数据进行相应计算。相应的运算结果保存在工作线程本地的写数据集(writeset)中。直至事务运行完毕，工作线程会进入尝试提交流程，对读数据集和写数据集进行检查验证(validate)操作并在允许的情况下对写数据集中数据对应的全局版本进行更新。

这样的流程，是把事务流程中对于全局版本的影响缩小到检查验证的过程，而在事务进行其他任何操作的过程中都不会影响到其他的并发事务，并且在仅有的检查验证过程中，所需要的也并不是传统意义上的锁，而仅是记录头部信息中的代表锁的数位(lock bit)。相应的这些考虑，都是为了最小化并发中可能出现的资源争抢以及冲突，并更有效地使用 CPU 缓存。

同时读数据集和写数据集的存在可以良好地支持各个隔离级别，不同隔离级别可以通过在检查验证阶段对读数据集和写数据集进行不同的审查机制来获得。通过检查两个数据集(set)中行记录在全局版本中对应的锁定位(lock bit)以及行头中的TID结构，可以判断自己的读、写与其他事务的冲突情况，进而判断自己在不同隔离级别下是否可以提交(commit)或是终止(abort)。同时由于 Masstree的 Trie节点(node)中存在版本记录，Masstree的结构性改动(insert/delete，插入/删 除)操作会更改相关Trie节点上面的版本号。因此维护一个范围查询(Range query)涉及的节点集(node set)，并在检查验证(validation)阶段对其进行对比校验，可以比较容易地在事务提交阶段检查此范围查询所涉及的子集是否有过变化，从而能够检测到幻读(Phantom)的存在，这是一个时间复杂度很低的操作。

（四） 内存引擎的内存管控

由于内存引擎的数据是全内存态的，因此可以按照记录来组织数据，不需要遵从页面的数据组织形式，从而从数据操作的冲突粒度这一点上有着很大优势。摆脱了段页式的限制，不再需要共享缓存区进行缓存以及与磁盘间的交互淘汰，设计上不需要考虑IO 以及磁盘性能的优化[比如索引 B+树的高度以及 HDD(HardDiskDrive，磁盘)对应的随机读写问题]，数据读取和运算就可以进行大量的优化和并发改良。

由于是全内存的数据形态，内存资源的管控就显得尤为重要，内存分配机制及实现会在很大程度上影响内存引擎的计算吞吐能力。内存引擎的内存管理主要分为3 层，如图19所示。

图19 内存引擎的内存管理示意图

下面分别对3层设计进行介绍:

• 第一层为应用消费者层，为内存引擎自身，包含了临时的内存使用以及长期的内存使用(数据存储)。
• 第二层为应用对象资源池层，主要负责为第一层对象，如表、索引、行记录、键值以及行指针提供内存。该层从底层索取大块内存，再进行细粒度的分配。
• 第三层为内存管理层，主要负责与操作系统之间的交互及实际的内存申请。为降低内存申请的调用开销，交互单位一般在2MB 左右。此层同时也有内存预取和预占用的功能。

第三层实际上是非常重要的，主要因为:

• 内存预取可以非常有效地降低内存分配开销，提高吞吐量。
• 与 NUMA 库进行交互的性能成本非常高，如果直接放在交互层会对性能产生很大影响。

内存引擎对短期与长期的内存使用针对 NUMA 结构适配的角度也是不同的。短期使用，一般为事务或会话(session)本身，那么此时一般需要在处理该会话的 CPU 核对应的 NUMA 节点上获取本地内存，使得交易(transaction)本身的内存使用有着较小的开销;而长期的内存使用，如表、索引、记录的存储，则需要用到 NUMA 概念中类似全局分布(interleaved)内存，并且要尽量将其平均分配在各个 NUMA 节点上，以防止单个 NUMA 节点内存消耗过多所带来的性能下降。

短期的内存使用，也就是 NUMA 角度的本地内存，也有一个很重要的特性，就是这部分内存仅供本事务自身使用(比如复制的读取数据及做出的更新数据)，因此也就避免了这部分内存上的并发管控。

（五）内存引擎的持久化

内存引擎基于同步的 WAL机制以及检查点来保证数据的持久化，并且此处通过兼容openGauss的 WAL机制(即 Transaction log，事务日志)，在数据持久化的同时，也可以保证数据能够在主备节点之间进行同步，从而提供 RPO=0的高可靠以及较小RTO 的高可用能力。

内存引擎的持久化机制如图20所示。

图20 内存引擎的持久化机制

可以看到，openGauss的 Xlog模块被内存引擎对应的管理器(manager)所调用，持久化日志通过 WAL的写线程(刷新磁盘线程)写至磁盘，同时被 wal_sender(事务日志发送线程)调起发往备机，并在备机 wal_receiver(事务日志接收线程)处接收、落盘与恢复。

内存引擎的检查点也是根据 openGauss自身的检查点机制被调起。openGauss中的检查点机制是通过在做检查点时进行shared_buffer(共享缓冲区)中脏页的刷盘，以及一条特殊检查点日志来实现的。内存引擎由于是全内存存储，没有脏页的概念，因此实现了基于 CALC的检查点机制。

这里主要涉及一个部分多版本(partial multi-versioning)的概念:当一个检查点指令被下发时，使用两个版本来追踪一个记录:活跃(live)版本，也就是该记录的最新版本;稳定(stable)版本，也就是在检查点被下发且形成虚拟一致性点时此记录对应的版本。在一致性点之前提交的事务需要更新活跃和稳定两个版本，而在一致性点之后的事务仅更新活跃版本，保持稳定版本不变。在无检查点状态的时候，实际上稳定版本是空的，代表稳定与活跃版本在此时实际上其值是相同的;仅有在检查点过程中，在一致性点后有事务对记录进行更新时，才需要根据双版本来保证检查点与其他正常事务流程的并行运作。

CALC(CheckpointingAsynchronously using Logical Consistency，逻辑一致性异步检查点)的实现有下面5个阶段:

• 休息(rest)阶段:这个阶段内，没有检查点的流程，每个记录仅存储活跃版本。
• 准备(prepare)阶段:整个系统触发检查点后，会马上进入这个阶段。在这个阶段中事务对读写的更改，也会更新活跃版本;但是在更新前，如果稳定版本不存在，那么在更新活跃版本前，活跃版本的数据会被存入稳定版本。在此事务的更新结束，在放锁前，会进行检查:
  如果此时系统仍然处于准备阶段，那么刚刚生成的稳定版本可以被移除;反之，如果整个系统已经脱离准备阶段进入下一阶段，那么稳定版本就会被保留下来。
• 解析(resolve)阶段:在进入准备阶段前发生的所有事务都已提交或回滚后，系统就会进入解析阶段，进入这个阶段也就代表着一个虚拟一致性点已经产生，在此阶段前提交的事务相关的改动都会被反映到此次检查点中。
• 捕获(capture)阶段:在准备阶段所有事务都结束后，系统就会进入捕获阶段。此时后台线程会开始将检查点对应的版本(如果没有稳定版本的记录即则为活跃版本)写入磁盘，并删除稳定版本。
• 完成(complete)阶段:在检查点写入过程结束后，并且捕获阶段中进行的所有事务都结束后，系统进入完成阶段，系统事务的写操作的表现会恢复和休息阶段相同的默认状态。

CALC有着以下优点:

• 低内存消耗:每个记录至多在检查点时形成两份数据。在检查点进行中如果该记录稳定版本和活跃版本相同，或在没有检查点的情况下，内存中只会有数据自身的物理存储。
• 较低的实现代价:相对其他内存库检查点机制，对整个系统的影响较小。
• 使用虚拟一致性点:不需要阻断整个数据库的业务以及处理流程来达到物理一致性点，而是通过部分多版本来达到一个虚拟一致性点。

小结

openGauss的整个系统设计是可插拔、自组装的，openGauss通过支持多个存储引擎来满足不同场景的业务诉求，目前支持行存储引擎、列存储引擎和内存引擎。其中面向 OLTP不同的时延要求，需要的存储引擎技术是不同的。例如在银行的风控场景里，对时延的要求是非常苛刻的，传统的行存储引擎的时 延很难满足业务要求。openGauss除了支持传统行存储引擎外，还支持内存引擎。在 OLAP(联机分析处理) 上openGauss提供了列存储引擎，有极高的压缩比和计算效率。另外一个事务里可以同时包含三种引擎的 DML操作，且可以保证 ACID特性。

Gauss松鼠会是汇集数据库爱好者和关注者的大本营， 大家共同学习、探索、分享数据库前沿知识和技术， 互助解决问题，共建数据库技术交流圈。