可以做视频的一个网站,页面设计在哪,重庆设计网站,怎么做自己的网站卖东西VACUUM 剖析
为什么需要 Vacuum
MVCC
MVCC#xff1a;Multi-Version Concurrency Control#xff0c;即多版本并发控制。
PostgreSQL 使用多版本并发控制#xff08;MVCC#xff09;来支持高并发的事务处理#xff0c;同时保持数据的一致性和隔离性。MVCC 是一种用于管…VACUUM 剖析
为什么需要 Vacuum
MVCC
MVCCMulti-Version Concurrency Control即多版本并发控制。
PostgreSQL 使用多版本并发控制MVCC来支持高并发的事务处理同时保持数据的一致性和隔离性。MVCC 是一种用于管理数据库并发操作的技术它允许多个事务同时访问同一数据而不会产生冲突或阻塞。
MVCC 的工作原理 版本化 PostgreSQL 为表中的每行数据存储多个版本。当一个事务更新一行数据时它不会立即覆盖原始数据而是创建该数据的新版本。 事务ID 每个事务被分配一个唯一的事务IDXID该ID 用于跟踪数据的变更。 快照 当一个事务开始时它会创建一个快照该快照是数据库在某一时刻的状态。即使其他事务在该事务进行时对数据进行了更改该事务仍然可以看到它开始时的数据库状态。 可见性规则 MVCC 通过一组可见性规则来确定事务可以看到哪些数据版本。通常一个事务只能看到在它开始之前已经提交的其他事务所做的更改。 垃圾回收 PostgreSQL 使用 VACUUM 命令来清理不再需要的数据版本释放空间。VACUUM 操作由系统自动调度也可以手动执行。
MVCC 的关键特点
无锁读取 MVCC 允许其他事务在读取数据时不被锁定因为它们可以访问数据的旧版本。写入时复制 当数据被更新时PostgreSQL 会复制旧版本的数据并创建新版本而不是直接在原地修改。隔离级别 PostgreSQL 支持不同的事务隔离级别如读未提交Read Uncommitted、读已提交Read Committed、可重复读Repeatable Read和串行化Serializable。隔离级别决定了事务可以看到其他事务更改的时间点。性能 MVCC 可以提高数据库的性能因为它减少了锁的争用和事务间的阻塞。一致性 通过使用快照MVCC 确保了事务在整个过程中看到的是一致性的数据视图。
MVCC 的挑战
表膨胀 由于多版本的存在表可能会膨胀需要定期维护。长事务 长事务可能导致较旧的数据版本长时间不被回收从而影响性能和空间。系统资源 MVCC 需要额外的系统资源来管理多个数据版本。
MVCC 是 PostgreSQL 强大并发控制机制的核心它使得数据库能够高效地处理大量的并发事务同时保持数据的一致性和隔离性。
表膨胀
多版本并发控制机制MVCC的原理在于当它需要更改某块数据的时候它不会直接去更改而是会创建这份数据的新版本在新版本进行更改所以会存储多份版本每个事务能看见哪一份版本的数据由事务隔离级别控制。
MVCC引入了一个问题如何消除老旧的、没有使用的无用数据版本目前主流上有3种处理实现方式
来看看各种数据库的解决方式 以Oracle为代表的把旧版本数据放入UNDO新数据放入REDO然后更改数据。这种方式旧版本的数据放入了UNDO所以可以有效避免膨胀。 以SQL Server为代表的把旧版本的数据写入专门的临时表空间新数据写入日志然后去更改数据。这种方式旧版本的数据放入了专门的临时表空间所以也可以有效地避免膨胀。 以PostgreSQL为代表的把旧版本标示为无效新数据写入日志成功后把新版本的数据写入新的位置。这种实现机制是导致数据膨胀严重的一个重要原因因为旧版本的数据虽然表示为无效状态但是没被回收前还是占据存储空间。
Vacuum 工作原理
PostgreSQL的表膨胀清理就需要依赖vacuumvacuum的主要任务就是清理表和索引中不需要的数据dead tuples为新加入的数据清理出来空间。
Vacuum
PostgreSQL中的VACUUM命令是一种数据库维护任务用于清理数据库中的无用空间也称为“dead tuples”或“ghost tuples”并防止表膨胀。VACUUM还更新数据库的统计信息这些信息由查询优化器用来选择最有效的查询计划。以下是VACUUM如何工作的详细步骤
标记删除 PostgreSQL使用一种称为标记-清除mark-sweep的垃圾收集机制。当DELETE或UPDATE命令删除或修改表中的数据行时原始数据行不会被立即从存储中移除而是被标记为“已删除”。这意味着这些行仍然占用空间但对查询来说是不可见的。移除元组 这里的移除dead tuples只是标记为可重用该空间并没有真正物理删除。所以vacuum清理表后表的实际空间并没有减小。dead tuples在做移除标记后vacuum会重新排列剩余的元组以进行碎片化整理。然后需要更新目标表的VM可见性映射文件和FSM空闲空间映射文件。更新统计信息 VACUUM收集有关表和索引中数据分布的统计信息并将这些信息存储在系统目录中。这些统计信息对于查询优化器来说是至关重要的因为它们帮助优化器决定如何执行查询。 VACUUM 在这段时间删除的数据并不会从此磁盘上删除只是将数据标为可删除这部分可删除的空间会出现以下两种情况 当有新的数据进行新数据会写入至这部分可删除的空间中即老数据从磁盘上移除了系统执行 vacuum full PgSql 会重新整理所有的元组(Tuples)最终将数据从磁盘上移除这一步比较耗费资源和时间有可能锁表生产环境慎用 Vacuum Full
Vacuum Full和Vacuum最大的不同就是Vacuum Full是物理删除dead tuples并把释放的空间重新交给操作系统所以在vacuum full后表的大小会减小为实际的空间大小。其处理过程和 vacuum 大不相同处理步骤如下 创建排它锁 vacuum full 开始执行时系统会先对目标创建一个AccessExclusiveLock 不允许外界再进行访问为后面拷贝做准备。 创建新表 系统会创建一张表结构和源表一模一样的新表方便后续做数据操作。 复制数据 扫描目标表把表中的live tuples 拷贝到新表中。 替换数据表 删除目标表在新表上重新创建索引更新VM FSM以及统计信息相关系统表等。
综上所述vacuum full的本质是生成一个新的数据文件然后把原有表的live tuples存放到该数据文件中。对比vacuum vacuum full缺点就是在执行期间不能对表进行访问由于需要往新表中导入live tuples数据其执行效率也会很慢。优点是执行后表空间只存放live tuples没有冗余的dead tuples在执行查询效率上会有所提高。
但是vacuum full 也有存在的问题在执行过程中它会block所有对表的访问不只是写操作读操作也会全部block。很多情况下这是不可接受的尤其是生产环境。
Vacuum 的好处
PostgreSQL中的VACUUM命令具有多个好处主要包括
回收空间VACUUM可以清理数据库中的无用空间即那些被标记为“已删除”的行占用的空间从而释放这些空间供其他数据使用。更新统计信息VACUUM会更新数据库的统计信息这些信息对于查询优化器选择最有效的查询计划至关重要。维护索引VACUUM还会维护索引删除索引中指向已删除数据行的条目并可能重建索引以优化性能。防止表膨胀随着时间推移表中的死元组会越来越多这会导致存储空间利用率下降VACUUM可以防止这种情况。提高查询性能通过清理无用的元组VACUUM可以减少查询需要遍历的数据量从而提高查询性能。自动回收空间VACUUM可以自动回收已经释放的空闲空间减少了数据库管理员的手动干预。
VACUUM是PostgreSQL数据库维护和性能优化的重要组成部分正确理解和运用VACUUM命令及其变种对于保持数据库的良好运行状态具有重要意义。
Vacuum 的最佳实践
PostgreSQL中的VACUUM操作是数据库维护的重要组成部分以下是一些最佳实践
定期执行VACUUM根据业务负载和表的更新频率制定合理的VACUUM策略特别是对于频繁更新的大表。启用并调优Autovacuum依赖Autovacuum来自动维护数据库健康。通过调整autovacuum_vacuum_threshold和autovacuum_vacuum_scale_factor等参数可以更精确地控制自动VACUUM的触发时机。考虑使用VACUUM FULL虽然VACUUM FULL可以最大程度地释放磁盘空间但由于它可能会锁定表并需要较长时间执行建议在业务低峰期使用并确保有足够的磁盘空间来创建表的新副本。监控Vacuum活动利用pg_stat_user_tables视图或其他监控工具了解Vacuum操作的状态和效果以便及时调整相关参数。不要无故运行手动VACUUM或ANALYZEAutovacuum通常可以很好地管理数据库除非有特殊情况否则不必频繁手动执行这些操作。在数据批量加载后运行ANALYZE在大量新数据被插入数据库后运行ANALYZE以确保统计信息的准确性从而帮助查询优化器制定更有效的查询计划。收集数据库信息在调整参数或实施手动VACUUM/ANALYZE之前收集有关数据库的足够信息如表的行数、死元组数、最后一次VACUUM/ANALYZE的时间等以便做出更明智的决策。
通过遵循这些最佳实践可以确保数据库的性能和健康状况得到良好的维护。
参考文档
Kimi.ai - 帮你看更大的世界
PostgreSQL的表膨胀与Vacuum和Vacuum Full - 明矾 - 博客园
深入浅出 PostgreSQL VACUUM 流程全面掌控数据健康与性能 - ByteZoneX社区
blog/202405/20240530_01.md at master · digoal/blog · GitHub
