postgresql技术大讲堂 -凯发app官方网站

凯发app官方网站-凯发k8官网下载客户端中心 | | 凯发app官方网站-凯发k8官网下载客户端中心
  • 博客访问: 593327
  • 博文数量: 486
  • 博客积分: 0
  • 博客等级: 民兵
  • 技术积分: 4941
  • 用 户 组: 普通用户
  • 注册时间: 2018-07-05 13:59
个人简介

ocp考试资料群:569933648 验证码:ocp ocp 12c 19c考试题库解析与资料群:钉钉群号:35277291

文章分类

全部博文(486)

文章存档

2024年(3)

2023年(35)

2021年(151)

2020年(37)

2019年(222)

2018年(38)

我的朋友
相关博文
  • ·
  • ·
  • ·
  • ·
  • ·
  • ·
  • ·
  • ·
  • ·
  • ·

分类: mysql/postgresql

2023-07-27 15:55:36


postgresql从小白到专家,是从入门逐渐能力提升的一个系列教程,内容包括对pg基础的认知、包括安装使用、包括角色权限、包括维护管理、、等内容,希望对热爱pg、学习pg的同学们有帮助,欢迎持续关注cuug pg技术大讲堂。

第24讲:toast技术

内容1 : toast简介

内容2 : toast的存储方式

内容3 : toast4种压缩策略

内容4 : toast表的计算方式

内容5 : toast表的优点与缺点

内容6 : 与oracle大对象存储方式对比


toast简介

· toast技术产生背景

元组不允许跨页面存储

· tost技术特点

toast是超长字段在pg的一个存储方式

全称the oversized attribute storage technique(超尺寸字段存储技术)

它会将大字段值压缩或者分散为多个物理行来存储

对于用户来说不用关注这一技术实现,完全是透明的


toast的存储方式

· pg的部分类型数据支持toast,因为有些字段类型是不会产生大字段数据(比如date,time,boolean等)

· 支持toast的数据类型应当是可变长度的(variable-length)

· 表中任何一个字段有toast,这个表都会有这一个相关联的toast表,oid被存储在pg_class.reltoastrelid里

· 超出的的数值将会被分割成chunks,并且{banned}最佳多toast_max_chunk_size 个byte(缺省是2kb)

· 当存储的列长度超过toast_tuple_threshold值(通常是2kb),就会触发toast存储

· toast将会压缩或者移动字段值直到超出部分比toast_tuple_targer值小(这个值通常也是2kb)。


建表时自动创建toast表

--创建表

create table toast_t(id int,vname varchar(48),remark text);

--其中remak数据类型是text,列值长度超过2kb则就会自动产生toast表来存储。


更改表的存储方式为toast

语法:

alter table toast_t alter column vname

set storage {plain | extended | main | external};

示例:

create table toast_t1(dd character varying);

alter table toast_t1 alter column dd set storage main;


/d toast_1

column | type | storage |

-------- ----- --------- -

dd | character varying | main |

access method: heap


查看toast表的名字

--查看tost表的oid

testdb=# select relname,relfilenode,reltoastrelid from pg_class where relname='toast_t1';

relname | relfilenode | reltoastrelid

---------- ------------- ---------------

toast_t1 | 16385 | 16389

--根据tost表oid查看其名字

testdb=# select relname from pg_class where oid = '16389';

relname

----------------

pg_toast_16385


toast4种策略

策略:plain

说明:避免压缩和行外存储。

只有那些不需要 toast 策略就能存放的数据类型允许选择(例如 int 类型),而对于 text 这类要求存储长度超过页大小的类型,是不允许采用此策略的。

策略:main

说明:允许压缩,但不许行外存储。

不过实际上,为了保证过大数据的存储,行外存储在其它方式(例如压缩)都无法满足需求的情况下,作为{banned}最佳后手段还是会被启动。因此理解为尽量不使用行外存储更贴切。

策略:extended

说明:允许行外存储和压缩。

一般会先压缩,如果还是太大,就会行外存储

策略:externa

说明:允许行外存储,但不许压缩。

类似字符串这种会对数据的一部分进行操作的字段,采用此策略可能获得更高的性能,因为不需要读取出整行数据再解压。


toast表额外的三个字段

字段名:chunk_id

属性:标识toast表的oid字段

字段名:chunk_seq

属性:chunk的序列号,与chunk_id的组合唯一索引可以加速访问

字段名:chunk_data

属性:存储toast表的实际数据

--查看tost表oid

testdb=# select relname,oid,rreltoastrelid from pg_class where relname='toast_t1';

relname | relfilenode | reltoastrelid

---------- ------------- ---------------

toast_t1 | 16385 | 16389

--查看tost表结构,tost表属于pg_tost模式

testdb=# \d pg_toast.pg_toast_16385

column | type | storage

------------ --------- ---------

chunk_id | oid | plain

chunk_seq | integer | plain

chunk_data | bytea | plain


toast表的计算

计算一个表的大小时要注意统计toast的大小,因为对超长字段存储时,在基础表上可能只存了20%,另外的数据都存到了toast里面去了,计算大小时要结合起来看

索引也是一样,对于表里有extended或者externa 类型的会创建toast表,两者的关联是通过pg_class里的oid去关联的


· toast表的计算案例(一)

testdb=# create table toast_t(id int,vname varchar(48),remark text);

create table

testdb=# select relname,oid from pg_class where relname = 'toast_t';

relname | oid

--------- -------

toast_t | 16392

testdb=# select relname,reltoastrelid from pg_class where relname = 'toast_t';

relname | reltoastrelid

--------- ---------------

toast_t | 16395

testdb=# select relname from pg_class where oid = '16395';

relname

----------------

pg_toast_16392


· toast表的计算案例(二)

--插入数据,此时remark列值长度小于2kb,所以不会触发tost存储:

insert into toast_t

select generate_series(1,4),repeat('kenyon here'||'^_^',2),repeat('^_^ kenyon is not god,remark here!!',2000);

--查看表中列值大小:

testdb=# select pg_column_size(id),pg_column_size(vname),pg_column_size(remark) from toast_t limit 10;

pg_column_size | pg_column_size | pg_column_size

---------------- ---------------- ----------------

4 | 29 | 851

4 | 29 | 851

4 | 29 | 851

4 | 29 | 851


· toast表的计算案例(三)

--查看基础表和 toast 的大小

testdb=# select pg_size_pretty(pg_relation_size('toast_t'));

pg_size_pretty

----------------

8192 bytes

--查看tost表尺寸

testdb=# select pg_size_pretty(pg_relation_size('16395'));

pg_size_pretty

----------------

0 bytes

此时remark列值长度小于2kb,所以不会触发tost存储。


· toast表的计算案例(四)

--remark列值超过 2kb 左右时触发了tost存储方式

insert into toast_t select generate_series(3,4),repeat('kenyon here'||'^_^',2),repeat('^_^ kenyon is not god,remark here!!',5500);

testdb=# select pg_size_pretty(pg_relation_size('16395'));

pg_size_pretty

----------------

8192 bytes


· toast表的计算案例(五)

--查看各列的数据变化,说明在列尺寸超过2k的时候就会把数据存放到toast表中:

testdb=# select pg_column_size(id),pg_column_size(vname),pg_column_size(remark) from toast_t;

pg_column_size | pg_column_size | pg_column_size

---------------- ---------------- ----------------

4 | 29 | 851

4 | 29 | 851

4 | 29 | 851

4 | 29 | 851

4 | 29 | 1651

4 | 29 | 1651

4 | 29 | 2247

4 | 29 | 2247


· toast表的计算案例(六)

--继续插入更多的数据:

insert into toast_t select generate_series(1,2),repeat('kenyon here'||'^_^',2),repeat('^_^ kenyon is not god,remark here!!',10000);

--查看toast表大小:

testdb=# select pg_size_pretty(pg_relation_size('16395'));

pg_size_pretty

----------------

16 kb

--继续插入更多的数据,20000

可以看到后插入的数据随着字段内容的增多,toast 段一直在变大。基础表的大小没有变化。这个和 oracle 存储的大字段内容比较像,oracle 存储 blob和clob 类的数据时也是指定另外的 segment 来存储,而不是在原表中存储,当然可以设置 enable storage in row 来指定表中存储


toast表的优点

1.可以存储超长超大字段,避免之前不能直接存储的限制

2.物理上与普通表是分离的,检索查询时不检索到该字段会极大地加快速度

3.更新普通表时,该表的toast数据没有被更新时,不用去更新toast表


toast表的缺点

1.对大字段的索引创建是一个问题,有可能会失败,通常不建议在大字段上创建,全文检索是一个凯发app官方网站的解决方案

2.大字段的更新会有点慢,其它db也存在相同问题


oracle大对象段存储特点

11g版本中推出了针对 lob字段处理的新技术:securefiles

该技术在性能、可管理性、易用性等方面,具有如下具体特点和优势:

· 提供数据去重、压缩和透明加密功能

· securefiles不仅可以有效降低lob字段存储空间消耗,提高了访问效率,而且提高了lob字段的数据安全性。


以上述某系统为例,我们将其中一个100gb的lob字段转换为securefiles,并采用压缩技术之后,{banned}最佳终只消耗30gb空间,大大压缩了存储空间。

·新的网络协议

securefiles提供一种新的client/server方式的内部读写机制,有效提高了大量数据传输的效率。

· 简化物理属性设计和管理

securefiles提供了大量自动化的物理属性机制,免去了大量物理属性设计和管理工作。例如:chunk属性为可变长,{banned}最佳大能支持到64m;oracle能自动进行碎片整理;


· securefiles还自动进行redo和undo的管理,避免大量不必要的redo和 undo信息的产生。




以上就是【postgresql从小白到专家】第24讲 - toast技术  的内容,欢迎一起探讨交流钉钉交流群:35,82,24,60,往期视频及文档内容联系cuug

阅读(89) | 评论(0) | 转发(0) |
给主人留下些什么吧!~~
")); function link(t){ var href= $(t).attr('href'); href ="?url=" encodeuricomponent(location.href); $(t).attr('href',href); //setcookie("returnouturl", location.href, 60, "/"); }
网站地图