POSTGRESQL 一个 autovacuum 自控的想法与实现架构

随着问问题的同学越来越多，公众号内部私信回答问题已经很困难了，所以建立了一个群，关于各种数据库的问题都可以，目前主要是 POSTGRESQL, MYSQL ,MONGODB ,POLARDB ,REDIS 等，期待你的加入，加群请添加微信liuaustin3.

______________________________________________________________________

其实提出这个问题的想法并不是自发的，而是一个被逼无奈的选择，POSTGRESQL 被骂的最惨的，（MYSQL 的同学）就是没有REDO LOG 导致表膨胀的问题，而autovacuum就是缓解这个问题的良药，但是药就有问题，问题的主要因素在于，autovacuum会在不合时宜的时候，去操作数据库的表，尤其大表，然后导致系统的性能消耗飙升，而导致各种各样的一些问题，当然这些问题在小的PG 数据库并不多见，而我们动辄几个T 的POSTGRESQL ，那是吃到了不少苦头。

所以，我们必须控制AUTOVACUUM 的发生，并且大概率的向和天气预报一样，预告大概率那些表要被AUTOVACUUM ，同时可以选择在预告的这段，不触发AUTOVACUUM ，或大概率不触发AUTOVACUUM。

实际上要完成这个功能，先画一个草图

这里的主要的思想，就是POSTGRESQL 的表在数据UPDATE 后，INSERT 后，对于大表的  analyze 和 vacuum 需求是并不一致

1   大部分同学希望 ANALYZE 更频繁一些

2   大部分客户希望  autovacuum 少一些,尤其在高峰期

所以第一步就是，把 analyze 和 vacuum的对于表的触发频率进行调整，同时调整只能针对，业务繁忙的大表，小表，和业务不繁忙的表，可以暂时不在考虑范围。

设置业务工作繁忙时间，在业务繁忙时间点，前调整大表的的图中的参数，根据算法（算法还在想，但一定是基于业务的方式，来设定一些等级，通过等级来对表的量级，和表的业务属性来进行批量化的调整）

然后在非业务时间，在次调整参数，让这些在业务繁忙期的大表和业务表，在非业务期间，更加积极的进行autovacuum的工作。

系统设计主要基于几个模块

1   大表收集器，这里面分为动态收集大表和用户自行设定大表 （根据行数和业务特性）

2   根据 autovacuum_vacuum_scale_factor +   autovacuum_vacuum_threshold 来调整 autovacuum 在所在表是否进行最近可能触发，或不触发的的可能，如果触发，就将值调整下降，如果想避免触发，将值调整高，解决问题。这个模块的主要的目的是 

1  存储对表的改动值和时间（延缓autovacuum可能发生的值和修改时间）

2  存储上一次表的两个参数的原值

3  修改表的参数的算法  1   调整多大的值后，表的autovacuum可以被延后   2  算法会计算表的 autovacuum_freeze_max_age 是否会被触发，如果表很快就会触发 freeze，那么这个表就会被跳过，并标记，不能进行参数的修改。3  在非业务繁忙时间，调回值是否会引发持续性的autovacuum 的工作繁忙的问题。

实际上，这些问题很复杂，实际上如果开发这样的系统，会有很长一段时间需要持续性的改进。

3  时间调度器，这个是这个模块中比较简单的，就是根据设定的时间，定期调用收集大表数据，定期根据用户的设定，来调用参数修改的模块，和判断数据表有无  freezeing 的风险的模块，所以调度本身不难，但怎么调度，时间的间隔等等是一个难点。

另外还有一个想法，就是加速和降速 VACUUM 的工作速度的问题，这个问题主要的工作部分在 autovacuum_vacuum_cost_delay , autovacuum_vacuum_cost_limit ，在业务非繁忙期动态调整这两个值，让CPU 和 内存以及IO 更高强度的为 autovacuum 服务。

后期会开始针对这个问题，进行相关的工作，这个功能后续也会集成在数据库智能平台的POSTGRESQL 部分，将管理POSTGRESQL 变成一种“艺术”。