AWS Redshift 修改编码压缩的影响

问题描述：

能否将某个表中的某一列修改成使用lzo编码方式压缩，期望通过这种方式提高查询性能，

同时需要确认进行修改时是否能够即时修改，并希望确认该修改不会对正在运行的查询有影响。

分析过程：

首先，对于修改某一列为lzo的编码方式而言，需要注意此修改可能会影响性能：

在对Redshift进行查询的时候，通过block/page的header的扫描就可以定位到查询涉及到的block/page。 对表中的一些列进行压缩处理，可以在一个block/page中存储更多的信息，以达到以最少的IO操作获取到尽量多的数据的目的，进而提高查询效率。

但是，在将相关的block/page读入内存之后，还需要对其进行解压处理才能对内部的数据完成读写操作，这相当于又增加了查询的延时。所以，在对表结构进行修改的时候，我们建议对已经定义为sortkey和distkey的列不进行压缩处理，因为对其进行压缩后由于sortkey和distkey频繁读取使用的特性，会增高查询语句的执行时长，反而影响查询效率。

因此，需要我们先进行确认想修改的列既不是sortkey，也不是distkey，再决定是否要进行修改；

在修改过程中，也有一些建议：

在进行表结构修改的操作时，由于里面涉及到了对此列进行写操作，所以会产生大量的锁，所以一定会block针对这张表的其他查询。在表比较大的情况下，列修改的耗时也会比较长。如果这个表有业务在使用，那么我们不会推荐直接对这个表进行修改操作。

在集群的存储空间比较富裕的情况下，我们建议可以考虑在原表的基础上，做一个深层复制[1]创建出一个一样的新表，然后在新表上进行表结构的修改。这样在修改后确认两个表的数据一致，可以将原表删除，然后之后的分析操作迁移到新表中来。

[1] https://docs.amazonaws.cn/redshift/latest/dg/performing-a-deep-copy.html

在进行修改前，如果之前没有设置自动执行 vacuum 操作，很长时间也没有进行过手动的vacuum 操作，建议依据参考链接[2]执行vacuum，由于vacuum操作在大数据量又有很多未排序列的情况下，会占用很多资源并且比较费时，文档中建议也可以使用深层复制的方式进行优化，相应对资源的占用会相对较低，并耗时较短。

[2] https://docs.amazonaws.cn/redshift/latest/dg/r_VACUUM_command.html

总结： 更改lzo编码方式是table DDL更改的一种，涉及DDL更改操作均可以采用上述理论，深层复制的方式进行。