1、存储引擎

##存储引擎概述
```
图中展示了存储引擎在数据库中
1. SQL语句从客户端发到SQL引擎后，
首先进行语法分析，然后经过优化器
优化生成一个执行计划。

2.接下来执行器与存储引擎进行交互，
GaussDB(DWS)的存储引擎支持行存
和列存（普通列存表和
HStore/HstoreOPT），并分别提供
了存储访问接口，组织与管理数据的
存储。
```
![title](/api/file/getImage?fileId=682c2ff02cbdfd19ee000688)

##行存储–page结构
```
行存表的page页面包括页头(page header)、空闲空间（free space）、数据(heap tuple)
下图展示了表文件page页头各个字段的存储信息：
tuple：一行数据为一个tuple
空闲空间：行指针的末尾与最新元组起始位置之间的空余空间
数据(heap tuple)：存储实际数据的地方
```
![title](/api/file/getImage?fileId=682c309f2cbdfd19ee00068a)
##行存储page结构–示例
```
假设有一张表仅包含了一个tuple1，该page header的pd_lower指向line pointers的第一个（箭头①），pd_uppder指向tuple1 （箭头②），第一个line pointer指向tuple1。
在line pointers末尾和最后一个tuple之前的空间被称为空闲空间(free space)。
当插入第二个tuple，则生成line pointer递增，并指向第二个tuple（箭头④）。与此同时，pd_lower、pd_upper更新对应的指向。随着数据的插入，页头信息也在不断实时更新
```
![title](/api/file/getImage?fileId=682c30d62cbdfd19ee00068b)
##行存：建表和索引
```
直接使用create table建立，默认为行存表。
B- Tree索引：

结构：B-Tree（平衡树）是一种有序树，每个节点包含多个键，并且子节点的键值范围是确定的。
优势：高效支持范围查询、等值查询和排序操作。
```
![title](/api/file/getImage?fileId=682c36062cbdfd19ee00068c)

##列存储引擎总体架构-CU
```
列存储引擎的最小存储单位是CU(Compression Unit, 压缩单元)。
    一个CU是由表中某一列的一部分数据组成的压缩数据块。
    通过(cu_id,col_id)标识一个CU。
```
![title](/api/file/getImage?fileId=682c36442cbdfd19ee00068d)

##列存储引擎总体架构-辅助表
```
辅助列存储的实现，记录存储元信息或者用于提升存储效率
    辅助表均为行存表
分类：
 CUDesc表：记录CU的事务时间戳信息，CU大小、存储位置、magic校验码、min/max等信息。
 delta表：由表级参数enable_delta控制是否开启。用于缓存列存表的入库数据，攒批后再刷到CU中。

查询pg_class得到列存表辅助表信息，下面字段为对应辅助表。
reldeltarelid
 delta表
reldeltaidx
 relcudescrelid
 delta表索引
CUDesc表
relcudescidx
 CUDesc表索引
```
##列存储引擎总体架构–场景
```
实时场景（性能）：
 Hstore表：增强实时场景的小批量DML性能，兼容列存2.0，可以切换。
 Hstore opt表：相比Hstore在入库和查询中能力提升显著，但不兼容老数据。
⚫ 海量数据场景（数据）：
表的类型
 冷热表：可以自动将冷数据放到OBS服务中进行存储，降低数据存储成本，保证热数据性能。
 存算分离表：将数据完全使用OBS存储，可以让用户根据性能和存储分别选择相应的规格。
⚫ 兼容：
 Hstore表、Hstore opt表、列存2.0都能够兼容冷热表和存算分离表。
```
##列存表建表和索引
```
⚫ 列存：
指定orientation = column选项，建立列存表。
compress_level: 指定压缩级别（low, middle, high）
max_batchrows: CU内最大的行数，默认6w行
columns_version: 1.0/2.0/3.0(存算分离）
⚫ 索引：
• Gin索引：
CREATE INDEX pgweb_idx_1 ON tsearch.pgweb USING gin(to_tsvector('english', body));
表的类型
基于B-tree树结构的倒排索引，存储被索引字段的VALUE或VALUE的元素，主要适用于数组过滤、全文检索的场景
• Gist索引：一个通用的索引接口，不同的类型支持不同检索方式，主要适用于位置搜索
• PSort索引：对该列进行聚簇排序，可大幅提升查询的过滤性能
• CBTree索引：列存的Btree索引，原理和行存相同
```
##Hstore表与普通列存表的差异
```
⚫ HStore表与列存表差异——辅助Delta表的差异
数仓类型列存的delta表HStore的delta表
表结构与列存主表的表定义一致。与主表表定义不一样。
功能用于暂存小批量insert的数据，满阈值后再merge
到主表，避免直接insert到主表产生大量小CU。
用于持久化存储update/delete/insert信息。在故
障拉起后用于恢复内存更新链等管理并发更新的内
存结构。
缺陷来不及merge导致delta表膨胀，影响查询性能，同
时无法解决并发update的锁冲突问题。依赖后台常驻autovacuum来做merge操作。
⚫使用HStore表时需要注意：
表级参数enable_delta与enable_hstore无法同时开启，因为enable_delta用于控制普通列存表的
delta开启，会与enable_hstore冲突。
 HStore表只支持COLVERSION 2.0版本。
```
##Hstore表的建表和索引
```
 HStore：在with中指定enable_hstore 选项为开启，即可开启Hstore,  也可以通过alter修改为普通列存。
此时，就不能在指定enable_delta了，这个是强制开启的，而且前提是，必须建立的是列存表，
orientation还是需要指定为columns。
⚫ Hstore支持异步排序（基础版）：
当指定了Psort后，会对存量的未排序数据在后台进行排序，但是在压力较大的时候会造成Delta膨胀的问题。
⚫ Hstore支持小CU合并：
在多次进行DML操作后，CU内的数据会被标记删除，发挥不出优势，小CU合并会在后台将小CU合并成一
个新CU，提升实时能力。
```
##HstoreOPT表与Hstore表的辅助表差异—Cudesc辅助表
![title](/api/file/getImage?fileId=682c36f72cbdfd19ee00068f)

##HstoreOPT表与Hstore表的辅助表差异—Delta辅助表
![title](/api/file/getImage?fileId=682c37102cbdfd19ee000690)

##Hstore OPT表的建表和索引
```
⚫ 建表：在with中可以指定enable_hstore_opt，前提是必须为列存，这个选项也可以和
enable_hstore同时指定，同时指定时，开启的也是hstoreopt版本，hstoreopt还会有
bitmap_columns或者buckets, 设置bitmap索引，二级分区等。当Hstore Opt开启时，将无法通过
alter关闭，此外opt会默认打开turbo属性，除非手动关闭（turbo请参考其他文档）。
⚫ 异步排序（增强版）, 小CU合并：当指定了Psort后，会对存量的未排序数据在后台进行排序，无Delta
表膨胀的问题。
⚫ 支持Bitmap Columns索引：这个索引和其他的索引的建立方式不同，需要通过with选项中的
bitmap_columns = ‘列名1,列名2’指定。此索引只针对varchar/text类型，并且字符长度不能大于
127。这个索引针对的场景比较明显，针对基数特征比较明显的列。在低基数时，内部会使用bitmap配
合字典压缩存储数据，在高基数时会通过bloomfilter生成hash的bit列加速过滤。
```
##冷热表
```
⚫ 冷热存储定义：
对于时间相关的一些场景，我们将数据按照时间可以分为两类：热数据、冷数据。
1. Hot（热数据）：被频繁查询或更新，对访问的响应时间要求很高；
2. Cold（冷数据）：不允许更新，偶尔被查询，对访问的响应时间要求不高。
用户可以定义冷热管理表，将符合规则的冷数据切换至OBS上进行存储，可以按照分区自动进行冷热数据的
判断和迁移。
⚫ 冷热切换策略：
支持两种模式：LMT（最后修改时间）和HPN（热分区数量）。
LMT（Last Modify Time）：
根据分区的最后更新时间进行切换。
切换[day] 天前修改的分区数据为冷数据，迁移至OBS 表空间。
[day] 范围：0 至36500 天。
HPN（Hot Partition Number）：
保留指定数量的热分区。
分区顺序根据分区的Sequence ID 确定，ID 由分区边界值大小生成。
切换时，将数据迁移至OBS 表空间。
HPN 范围：0 至1600。
```
##冷热表的建表
```
冷热表：
1. 创建OBS Tablespace，指定OBS路径：
CREATE TABLESPACE tablespace_name [relative location '']
 with (filesystem='obs', address='', access_key='', secret_access_key='', storepath=‘’);
  filesystem：表空间类型，OBS表明为OBS表空间；
 address：在为OBS表空间时为OBS的hostname；
 access_key：OBS访问秘钥ID；
 secret_access_key：与访问密钥ID结合使用的私有访问密钥，数据库内部加密存储；
 storepath：OBS上的数据存储路径。
表的类型
 relative location：可以省略，并且公有云环境只支持省略的方式，系统默认生成location：数据库data目录
/tablespace_name
 2. 在选项中指定orientation = column, cold_tablespace = ‘tablespace_name’, storage_policy= ‘’，同样是列存表。
 cold_tablespace：顾名思义，为冷表空间，这个是必选的选项。
 storage_policy：冷热数据切换规则，必选，规则以”冷热切换策略:冷热切换时间”的方式，目前切换策略只支
持”LMT”，以分区的最后修改时间为准，冷热切换时间支持[0, 36500],单位DEBUG版为秒，RELEASE版本为天。
```
##存算分离表
```
⚫ 存算分离背景：
表的类型
在云原生环境中，用户可以自由配置cpu型号、内存、磁盘、带宽等资源，需要在计算和IO之间做平衡；通过实现存算分离，
计算层和存储层可以独立增加节点互不干扰。
⚫ 存算分离原理：
```
![title](/api/file/getImage?fileId=682c37882cbdfd19ee000691)
##存算分离的建表
```
⚫ 存算分离表：
1. 与冷热表相同，首先需要创建一个OBS tablespace。
2. 需要创建一个逻辑集群，创建sql如下：
update pgxc_node set nodeis_central = true where node_name = 'coordinator1';
 CREATE NODE GROUP write_group
 WITH(datanode1,datanode2,datanode3,datanode4,datanode5,datanode6) vcgroup;
 3. 创建表：指定colversion=3.0，即可创建存算分离表。具体如下：
CREATE TABLE IF NOT EXISTS t1(c1 text,c2 text) 
with (orientation=column, enable_hstore_opt=on, COLVERSION = 3.0) 
TABLESPACE obs_ts distribute by hash(c1)
 TO GROUP write_group;
```

##不同表的优劣势
```
⚫ 行存：适合少量数据，对实时性要求较高的场景。
⚫ 列存1.0/2.0：因为并发能力相比HStore较弱，因此不再推荐使用。
⚫ HStore：微批copy无更新入库场景性能要求高的情况下可以使用HStore表。
表的类型
⚫ HStore Opt: 对列式存储有实时场景需求的，建议使用HStore Opt，这也是当前最推荐的版本。
⚫ 冷热表：业务系统中用户对不同时期数据的不同使用需求时可以使用冷热表，这和使用HStoreOpt不冲
突，可以同时开启。
⚫ 存算分离表：在云原生环境中，有需要分别增减计算节点和存储节点的场景时可以使用。
```

DBLOG

导航1234

最近发表

友情链接