开头还是介绍一下群，如果感兴趣PolarDB ,MongoDB ,MySQL ,PostgreSQL ,Redis, Oceanbase, Sql Server等有问题，有需求都可以加群群内有各大数据库行业大咖，可以解决你的问题。加群请联系 liuaustin3 ，（共2300人左右 1 + 2 + 3 + 4 +5+6） 新人分配到6群,准备建立7 群。*（1 2 3 4 5 均没有空位了，请不要在问了谢谢）
非常荣幸能参加，7月12-13日在杭州举办的PostgreSQL中文社区大会，这次代表使用PG的一些资深用户来说说这些年使用PG的感受，PG使用中的一些问题，及使用中的问题引导我们用户孕育出的一个PG周边的产品，及vacuum集中管理平台帮助我们更好的使用PostgreSQL的故事。
基于工作和非公派私人请假的原因，和杭州就只有一天的接触，实在是遗憾，有更多的时间更近距离的和 人间天堂多接触，不过即使是短暂的停留还是阻挡不住杭州城独特的韵味。
正题：
我们为稳定的运行PostgreSQL产品，自行研发并搭建了一个PostgreSQL稳定性平台（vacuum集中管理平台），此次将从四个步骤来介绍，PG怎么引起我们想干这个事情，怎么一开始觉得很简单，后面遇到很多的问题，在到进行系统的改造完善，最终到得到一个好结果的故事。
相信长时间使用PostgreSQL的老老少少们，都有一个体会，这系统运行的好好的，突然就IOPS升高了，突然就CPU升高了，然后呢我们就用其他数据库的经验来查慢SQL，查来查去没有问题，要不就是没有慢SQL，要不就是有慢SQL，但在其他时间这个SQL不是慢SQL。这到底是为什么，是人性的扭曲还是道德的堕落。
实际上都不是，这主要还是没有拿捏PostgreSQL的基本原理，在PG运行中会基于PG实现MVCC的原理的方式，将数据的各个在事务中的版本存储在每个数据表内，引发的autovacuum 来回收这些已经过期的数据引发的性能问题。PG 本身是有能力来回收这些dead tuple，来将空间重用，同时也可以针对单张表来进行深度的参数调节，让每张表都有合适的触发autovacuum的时机。方案很多，都在民间，我们之前就是调节大表的一些参数，写一些脚本来对大表进行人工vacuum来去解决一些问题。
可惜了，这些方案都有各种各样的问题，比如条件参数，调节完毕过些日子，这参数又不合适了，我还的去调节，或者我忘记了调节了，在或者我写脚本定期做vacuum，但是这不行呀表太大了做不完，等做完都到业务高峰期了。而最悲催的是，目前我们没有找到一个集成化的工具来解决这个问题，人少数据库实例多，数据库容量大，单表体积行数惊人。
我们不禁要问，这问题竟然没有工具，主要的问题可能在以下几个部分，实际上除了我们知道的几个问题，真正的根源在于，做这个工具他没有经济效益，你说谁会花钱买一个 PostgreSQL稳定性平台的东西，实际上就是一个做vacuum 自动化的一个集成器，投入没有回报呀
那么这个工具只能谁来做，只能有大批PostgreSQL 数据库服务器的，还的是核心业务的，并且表的量级和体积都有一定高度的，还的懂得PG原理，有点设计能力，devops能力的，有点突破创新的一群人，才能做这个事情，恰巧我们就是。
既然我们决定要干这个事情，我们就的定出目标，否则老板不给时间你做这个项目，你必须说出一个 1 2 3 来告诉老板，做这个事情的好处是什么
说到这个问题，我们的从资本家最关心的地方来，成本，我们提出如果我们的系统上线会降低磁盘的消耗，为公司降低在PG存储上的成本，同时我们能解决一些之前业务部门投诉POSTGRESQL 数据库不稳定的问题，比如业务高峰期突然就IOPS升高，业务卡顿，开发后来也知道是autovacuum的问题，他们还提出关闭autovacuum行不行的馊主意，让我们否定了。最终我们另一个诱惑点是，我们的系统上线，减少95%以上的autovacuum的触发。
老板就答应了这个项目，并看着我们到底这个项目能不能为公司省钱，解决一些客诉的问题。实际上我上次在ITPUB也对PG的运行维护做过一期，PG数据库是十分需要细致的维护的，尤其对于核心的系统，大表，热表。那么我们就从这里下手，通过我们的系统将这些表的autovacuum的时间，次数，以及dead tuple, live tuple进行分析，并搞成一个历史数据模型，通过这些模型来更智能的告诉什么时候要进行vacuum的操作，并且避开业务高峰期。当时想这个事情很简单，但实际上做起来，问题就百出了。
上面这张图就是我们最初画的一个系统的原型草图，非常的简单，主要的思路就是利用定时器将分析需要进行vacuum操作的表进行vacuum的操作。
在这样幼稚的想法下，想不出问题就很难了，第三个部分我们就说说由于想的太简单我们除了那些问题，以及我们如何解决的。
我们将遇到的问题进行了梳理，产生了我们展示的这个思维导图，核心的问题是，我们没有想到表太多，大表太多，实例太多，整理的方法快了不行，慢了不行，整体的初期的工作是比较狼狈的，不是数据库告警，就是我们自己的系统告警，IOPS，是告警最频繁的，其次就是数据量太大，根本在分析数据的时候，分析不出来，分析错误，存储分析数据的数据量太大爆掉等等各种问题。
这里我们总结出以下问题
1 大表 vacuum的时间长，需要控制每次进行vacuum的表的个数
2 数据库获取分析数据失败，导致分析程序错误
3 大表在规定时间无法完成，转移到下次执行，而下次的列表还有这个表，导致执行两次，或者永远在执行计划中，无法执行完毕
4 初期表执行时，多个表执行VACUUM 导致系统IOPS告警 5 分析的数据太多，导致分析的数据表查询数据缓慢，或需要很长时间查询数据
这些问题我们逐步解决，调整执行大表的时间，并且在任务列表中进行去重的工作，保证在一次执行当中，不会出现对于大表一天执行两次，同时我们也在研究在执行vacuum的情况中，如果系统告警，我们需要接受到告警后，能自动降低下一次并行进行vacuum操作的数量，目前我们的系统仅仅能承接固定版本的数据库 vacuum 的操作，而对于更高版本如15 16 提出了新的vacuum的命令我们还不能智能进行转换，对于操作日志的部分我们记录的比较详细，对于一些接受到数据库告警后，停止和减慢vacuum的操作的部分我们还需要更多的时间进行研究。、
同时我们也在软件的成型中，对于规则引擎中对于表固定的分类产生了一些更深的感触，PostgreSQL 数据库在autovacuum 操作中尽管在众多的版本中进了优化，但唯一最大的问题，对于表触发autovacuum的时机不能动态判断这是最大的问题，所以我们的规则引擎也逐渐在演进，其中已经在开发动态规则的部分，也就是表是否进行整理，评判的标准要动态而不是和触发器一样只有达到某种上线才进行工作，而是要根据历史数据预判，同时根据动态数据变化趋势来进行表的分类，将静态的规则引擎和动态的规则引擎合二为一，最终逐步完善PG表触发vacuum 操作的指标判断。举例：通过动态因子系数+数据递增的规律作为第二道判断的门槛。
针对我们发现的问题，进行了重新的系统设计，这是我们现行的系统设计，比如我们的数据处理和核心数据都在REDIS中，利用REDIS 的一些特性来解决我们系统调用中的去重和先进先出的一些需求，同时我们对我们的程序也进行了功能和模块的划分，对于表的评判规则使用了规则引擎来进行工作，对于配置信息部分我们也是通过ETCD 来进行配置信息的下发，避免每个模块获得的配置信息有差异导致系统运行错误问题。
在我们不断的对系统进行BUG FIXED 和改造的基础上，系统已经运行了一段时间
我们也对我们的系统进行了梳理，产生了5个固定的模块，如数据源配置，数据采集，计划与执行，配置文件，角色管理等。
下面我们对我们的每个模块进行简单的介绍，上图是录入PostgreSQL数据库到vacuum集中管理平台中的操作页面，通过输入一些关键的信息，如用户密码链接串，逻辑库等将数据库与系统进行挂接。为了方便用户对于系统进行控制，我们添加了仅采集数据，与状态两个开关，关闭状态则数据库将与系统进行脱钩，系统将停止收集数据或仅仅收集数据不进行vacuum的操作。
这个界面是我们在获得数据后，对表进行分析的页面，其中包含了一些对于表与死，或元祖有关的信息以及 vacuum 和 autovacuum 的信息等。同时这个界面对于管理员还开放了手动调节表参数，以及手动vacuum 与关闭autovacuum的功能。通过这些功能来方便使用者快速的对表的一些问题进行响应。
在页面前我们还能显示出那些表进行了autovacuum关闭或那些表的年龄问题，方便快速找到已经设置参数的表但忘记那些表已经设置的独立的参数。
在每个表中都有vacuum 或 anaylze操作后的操作记录，并可以直接查看其中的工作的信息。
基于我们可以让非DBA的同学对于表进行 analyze的操作，我们对于 analyze 操作的记录有单独的地方进行记录和展示。
最后这幅图是展示权限管理部分的界面，其中将用户分为两类，DBA用户和非DBA用户两类。对于在系统中操作的用户进行权限管理。
我们的系统目前已经接管了80%的PG生产数据库，在使用中我们已经逐步达到当初给领导的承诺
1 在介入的PG系统，降低磁盘添加的频率，具体看PG库承接的业务，90%的PG系统添加磁盘的频率从原来的一个月两次加磁盘，现在变更到2个月1次或一个半月1次。
2 在加入到vacuum集中管理平台的的数据库，相较历史数据告警相比较，减少IOPS 告警部分库可达90%，CPU 的告警情况也有所降低，部分库最大可以降低60%的告警频次。
3 另外两个是功能性的，一个是提高了工作的效率，对于一些极端情况下大量的UPDATE 等操作我们也有了良好的闭环的管理措施，另一个提高了工作的效率，让需要对数据库表有analyze需求的人也都可以灵活处理分析操作。
结语：系统我们还在持续的发现问题，并进行改善，我们也深知随着PG后续的发展，逐步完善dead tuple回收的机制，或许我们的系统将在某天失去意义，但我们发现问题，解决问题，并且有想法敢动手的能力，还是值得称赞的！
置顶文章：
PolarDB 从节点Down机后，引起的主从节点强一致的争论
往期热门文章：
PolarDB 从节点Down机后，引起的主从节点强一致的争论
SQL SERVER 2022 针对缓存扫描和Query Store 的进步，可以考虑进行版本升级
临时工访谈：从国产数据库 到 普罗大众的产品 ！与在美国创业软件公司老板对话
PostgreSQL 分组查询可以不进行全表扫描吗？速度提高上千倍？
