PostgreSQL的表膨胀与Vacuum和Vacuum Full

为什么会有表膨胀--多版本并发控制机制

多版本并发控制机制(MVCC)的原理在于,当它需要更改某块数据的时候,它不会直接去更改,而是会创建这份数据的新版本,在新版本进行更改,所以会存储多份版本,每个事务能看见哪一份版本的数据,由事务隔离级别控制。

MVCC引入了一个问题,如何消除老旧的、没有使用的无用数据(版本),目前主流上有3种处理实现方式:

来看看各种数据库的解决方式:

第一种:以Oracle为代表的,把旧版本数据放入UNDO,新数据放入REDO,然后更改数据。这种方式,旧版本的数据放入了UNDO,所以可以有效避免膨胀。

第二种,以SQL Server为代表的,把旧版本的数据写入专门的临时表空间,新数据写入日志,然后去更改数据。这种方式,旧版本的数据放入了专门的临时表空间,所以也可以有效地避免膨胀。

第三种,以PostgreSQL为代表的,把旧版本标示为无效,新数据写入日志,成功后把新版本的数据写入新的位置。这种实现机制是导致数据膨胀严重的一个重要原因,因为旧版本的数据虽然表示为无效状态,但是没被回收前还是占据存储空间。

PostgreSQL清理表膨胀之vacuum

PostgreSQL的表膨胀清理就需要依赖vacuum,vacuum的主要任务就是清理表和索引中不需要的数据(dead tuples),为新加入的数据清理出来空间。

vacuum的执行过程主要分为以下三步:

    1. 清除dead tuples指向的index tuples

        该过程中,vacuum会顺序扫描目标表,并构建一个dead tuples组成的list链表,该list链表会存储在maintenance_work_mem缓存中。然后vacuum根据dead  tuples list移除dead tuples指向的index。

    2. 移除dead tuples,更新VM和FSM

        这里的移除dead tuples只是标记为可重用该空间,并没有真正物理删除。所以vacuum清理表后,表的实际空间并没有减小。dead tuples在做移除标记后,vacuum会重新排列剩余的元组以进行碎片化整理。然后,需要更新目标表的VM(可见性映射文件)和FSM(空闲空间映射文件)。

    3. 更新统计信息和相关系统表

       需要更新vacuum目标表的统计信息(以适应最新的查询优化)和相关系统表。

但是vacuum也有存在的问题。比如,vacuum完成清理工作后,那些空间并没有真正被释放给操作系统,只能被vacuum清理过的表和索引所利用。

PostgreSQL清理表膨胀之vacuum full

Vacuum Full和Vacuum最大的不同就是,Vacuum Full是物理删除dead tuples,并把释放的空间重新交给操作系统,所以在vacuum full后,表的大小会减小为实际的空间大小。其处理过程和vacuum大不相同,处理步骤如下:

    1.  vacuum full开始执行时,系统会先对目标创建一个AccessExclusiveLock ,不允许外界再进行访问(为后面拷贝做准备),然后创建一个表结构和目标表相同的新表。

    2. 扫描目标表,把表中的live tuples 拷贝到新表中。

    3. 删除目标表,在新表上,重新创建索引,更新VM, FSM以及统计信息,相关系统表等。

    所以,vacuum full的本质是生成一个新的数据文件,然后把原有表的live tuples存放到该数据文件中。对比vacuum, vacuum full缺点就是在执行期间不能对表进行访问,由于需要往新表中导入live tuples数据,其执行效率也会很慢。优点是执行后,表空间只存放live tuples,没有冗余的dead tuples,在执行查询效率上会有所提高。

当然,vacuum full 也有存在的问题,在执行过程中,它会block所有对表的访问,不只是写操作,读操作也会全部block。很多情况下这是不可接受的,尤其是生产环境。

 

如何解决vacuum或vacuum full 带来的问题,社区也提供了pg_squeeze,pg_repack等工具,下回分解。

 

posted @ 2022-01-12 22:39  明矾  阅读(2733)  评论(0编辑  收藏  举报