|
前文回顾： 1.如何掌握openGauss数据库核心技术？秘诀一：拿捏SQL引擎（1） 2.如何掌握openGauss数据库核心技术？秘诀一：拿捏SQL引擎（2） 3.如何掌握openGauss数据库核心技术？秘诀一：拿捏SQL引擎（3） 4.如何掌握openGauss数据库核心技术？秘诀一：拿捏SQL引擎（4） 5.如何掌握openGauss数据库核心技术？秘诀二：拿捏执行器技术（1） 6.如何掌握openGauss数据库核心技术？秘诀二：拿捏执行器技术（2） 7.如何掌握openGauss数据库核心技术？秘诀三：拿捏存储技术（1） 8.如何掌握openGauss数据库核心技术？秘诀三：拿捏存储技术（2） 
一、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）文件来记录主备机例之间文件的同步状态。 未完待续....... |
|
|
