greenplum 单表磁盘空间持续高速增长，解决办法(2)

描述

自上次解决空间增长问题后，又出现了此问题。初步解决方案还是上次的步骤，但是感觉治标不治本，这不是个办法，而且只有一张或两张表有这个问题。

这样就有了一个排查的入手点了。是因为频繁的插入删除么，还是频繁的更新新呢？

1. GP物理空间使用的特性建议去了解一下
2. 简单介绍一下，就是修改的动作，是逻辑删除，空间不释放
3. 运行一段时间后有修改的表，需要进行真空处理

发现其中一张表是有删除、插入动作，另一张表只有插入动作。尝试了一下 真空还能释放空间，这就比较郁闷了。没有进行逻辑删除，那释放的空间是什么呢？

原因

排查后发现，两张表都有一个特点就是批量写入失败 重试。。。。

1. 复杂的多表关联查询，然后写入汇总表
2. 关联查询的同时，某些数据是异步的，拿不到
3. 生成的数据对应汇总表的字段，有些异步字段是分布键

 

1. 上游接口变更没有通知下游
2. 比如类型变更，长度变更

以上情况导致了批量写入失败。

分析

以上情况分析原因，可能是在插入数据之前，会先在各个节点上申请足量的空间，比如数据，索引、静态分析等。

申请到空间后才会写入，但是写入失败了，空间也没有进行回收操作。这时程序触发的重试操作，没有回收的空间也不会再次 被分配，而是分配新的空间给到请求。

就导致了大量的闲置空间。

后果

线上使用到这种表的代码，会逐渐卡顿，温水煮蛙啊，等意识到卡顿的时候，去看表的大小 ，就几十个G了。如果是那种PV较高的平台，不回会让你有时间去停服处理的。只能用方案一种的方法。

如果必须要查询的情况下，就必须在临时表 生成对应条件的数据了，可能时间就比较紧迫了。

以上仅为个人观点，如有错误欢迎指正