前文回顾:
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数据库SQL引擎
openGauss数据库执行器技术
openGauss存储技术
一、openGauss存储概览
二、openGauss行存储引擎
三、openGauss列存储引擎
四、openGauss内存引擎
openGauss事务机制
openGauss数据库安全
三.openGauss列存储引擎
列存支持的索引设计有:
§ 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开销。
列存储引擎每个列自带min/max稀疏索引,每个CUDesc存储该CU的最小值和最大值。
那么在查询的时候,可以根据查询条件做简单的min/max判断,如果查询条件不在(min,max)范围内,肯定不需要读取这个CU,可以大大地减少IO读取,如图31所示。
图31 稀疏索引图
注:txn_info 表示事务信息;CUPtr 压缩单元的指针;CUNone 表示肯定不命中;CUSome 表示可能有数据匹配;CU_Full 表示压缩单元数据全命中。
列存表在建立时可以选择在列上建立聚簇索引(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)文件来记录主备机例之间文件的同步状态。
未完待续.......
联系客服