189 8069 5689

PostgreSQL磁盘空间的保护伞PG_repack及表膨胀的示例分析

这期内容当中小编将会给大家带来有关PostgreSQL 磁盘空间的保护伞PG_repack及表膨胀的示例分析,文章内容丰富且以专业的角度为大家分析和叙述,阅读完这篇文章希望大家可以有所收获。

我们提供的服务有:成都网站设计、做网站、微信公众号开发、网站优化、网站认证、峰峰矿ssl等。为1000+企事业单位解决了网站和推广的问题。提供周到的售前咨询和贴心的售后服务,是有科学管理、有技术的峰峰矿网站制作公司

PG 最近的使用中,发现这个数据库确确实实是一个无底洞,东西太多了,但学习一样东西都是通过主干和分支的方式来学习,后续的学习其实有的时候是靠自觉和运气。

今天要说的pg_repack,这个插件,PG 的操作没有ORACLE 或SQL SERVER 那样简单化,因为PG 的很多功能是通过插件的方式来进行的,当然这也和MySQL 插件方式不同。

话归正题,PG 中通常会存在一些需要管理的问题如下:

删除大量记录后,从表中回收到磁盘的空闲空间
重新构建一个表来重新排序记录,并将它们压缩/打包到更少的页面。这可能让查询只从磁盘获取一个页面(或< n个页面),而不是n个页面。换句话说,IO越少,性能越好。
从由于不正确的auto vaccum设置而导致大量膨胀的表中不能回收空闲空间。

安装 pg_repack 是并不是一件难事,正常的编译,create extensiton pg_repack ,然后在配置文件中  shared_preload_libraries = 'pg_repack'

重新启动PG 即可

下面我们就是要模拟一个表膨胀的案例,然后再用 pg_repack 来解决一些问题

1  我们在postgres 数据库中创建一张表

CREATE TABLE large_test (id serial primary key,num1 bigint, num2 double precision, num3 double precision);

2 插入测试数据

INSERT INTO large_test (num1, num2, num3)

  SELECT round(random()*10), random(), random()*142

  FROM generate_series(1, 2000000) s(i);

3 我们查看这个表到底在机器物理那个文件上体现

select oid,datname from pg_database ;

PostgreSQL 磁盘空间的保护伞PG_repack及表膨胀的示例分析

OK 我们确认我们的表的物理文件应该在 13287 这个文件夹里面,在这里我们通过oid2name 命令来查看到底你的这个表在哪里文件里面,

oid2name -t large_test  下图中我们可以锁定物理的表在 16455 这个文件中

PostgreSQL 磁盘空间的保护伞PG_repack及表膨胀的示例分析

这张表现在有200万的记录,大小是115MB

PostgreSQL 磁盘空间的保护伞PG_repack及表膨胀的示例分析

下面我们就开始进行一个表膨胀的操作,我们开启两个事物

1第一个事物往表里面在插入 200万的数据  

2 第二个事物更新表里面的某个字段的值

PostgreSQL 磁盘空间的保护伞PG_repack及表膨胀的示例分析

PostgreSQL 磁盘空间的保护伞PG_repack及表膨胀的示例分析

我们可以看一下表的大小瞬间就从 115MB 暴涨到 345 MB

PostgreSQL 磁盘空间的保护伞PG_repack及表膨胀的示例分析

如果按照逻辑来说,其实表的大小不应该是在 230MB 左右,怎么这么夸张的到达了345MB.

其实这就的从PG 的表的结构设计来说了,(之前写过一篇文字在4个月前),主要是PG 的 undo log 其实是在糅合到表的物理设计中,每次UPDATE 其实都不会进行真正的数据修改,而是重新插入一个新的行,(这然我想起 cassandra),所以,更新了多少行,占用的数据的空间就是 *2 ,所以就造成了表膨胀,以及 vaccum 和  auto vaccum 这两个事情。(vaccum 也是写过了,大约是2个月前),所以有的时候我们就的祭出我们的神器,(注:请在非工作时间进行维护操作)PG_REPACK 工具,来收缩一下我们的膨胀过分的表,当然auto vaccum 也是可以解决的,但如果你的表膨胀的比较大,并且在非工作时间,其实一次性解决这个问题,也是一个好的办法。

我们下面就开始repack

pg_repack  -d postgres --table public.large_test;

PostgreSQL 磁盘空间的保护伞PG_repack及表膨胀的示例分析

在经过了10几秒的工作后,我们查看 large_test 表的物理文件在哪里,我看可以看到,在经过repack后,物理文件的名字更改了。

我们在看看这个物理的文件多大 230 MB 对比刚才的 磁盘占用率吗,可以很清楚的知道刚才那些被废弃的行的空间已经释放给了系统。

PostgreSQL 磁盘空间的保护伞PG_repack及表膨胀的示例分析

那么问题来了,repack 到底做了什么,原理是什么,其实热 repack 的原理很简单, 和 MYSQL 的 alter table table engine=innodb是一个意思(如果你是MYSQL的 DBA 估计会很快明白)。当然如果你是 SQL SERVER 的DBA ,shinrk  database 的功能 你懂得哈

这相当于重新写了一个新的文件,将原来的物理文件踢掉,重新对表进行了一次整理。

那这样的好处不光是表的占用空间变小了,收益的还有访问表的速度也会更快。最后这个命令还可以并行运行,后面加参数 J 和你的并行数。

PostgreSQL 磁盘空间的保护伞PG_repack及表膨胀的示例分析

最后如果你安装pg_repack 报了一些莫名奇怪的错误,你可以尝试安装

sudo yum -y install postgresql-static.x86_64

最后如果你想远程操作这个命令,是可以的,但你远程的机器也必须安装这个插件,不能说你本地安装,远程操作一个没有插件的PG ,那是不可以的。

上述就是小编为大家分享的PostgreSQL 磁盘空间的保护伞PG_repack及表膨胀的示例分析了,如果刚好有类似的疑惑,不妨参照上述分析进行理解。如果想知道更多相关知识,欢迎关注创新互联行业资讯频道。


分享名称:PostgreSQL磁盘空间的保护伞PG_repack及表膨胀的示例分析
转载注明:http://cdxtjz.cn/article/gsjeoe.html

其他资讯