【连载】如何掌握openGauss数据库核心技术？秘诀三：拿捏存储技术（5）

前文回顾：

openGauss数据库SQL引擎
openGauss数据库执行器技术
openGauss存储技术

一、openGauss存储概览

二、openGauss行存储引擎

三、openGauss列存储引擎

Ⅰ、列存储引擎的总体架构

Ⅱ、列存储的页面组织结构

Ⅲ、列存储的MVCC设计

IV、列存储的索引设计

V、列存储自适应压缩

VI、列存储的持久化设计

四、openGauss内存引擎

openGauss事务机制
openGauss数据库安全

openGauss存储技术

三.openGauss列存储引擎

列存的索引设计

列存支持的索引设计有：

§ Btree索引

§ 稀疏索引

§ 聚簇索引

1. 列存的Btree索引

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

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

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

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

2. 列存的稀疏索引

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

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

图31 稀疏索引图

注：txn_info 表示事务信息；CUPtr 压缩单元的指针；CUNone 表示肯定不命中；CUSome 表示可能有数据匹配；CU_Full 表示压缩单元数据全命中。

3. 列存的聚簇索引

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

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

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

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

其示意图如图33和图34所示。

图33 聚簇索引生效前

图34 聚簇索引生效后

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

列存储自适应压缩

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

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

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

图35 压缩比示意图

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

图36 面向列的自适应压缩

列存储的持久化设计

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

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

未完待续.......

END

本站仅提供存储服务，所有内容均由用户发布，如发现有害或侵权内容，请点击举报。