sql – DELETE和INSERT之后的Redshift(AWS)上的VACUUM

CREATE TABLE "fact_table" (
  "pk_a" bigint                 NOT NULL ENCODE lzo,"pk_b" bigint                 NOT NULL ENCODE delta,"d_1"  bigint                 NOT NULL ENCODE runlength,"d_2"  bigint                 NOT NULL ENCODE lzo,"d_3"  character varying(255) NOT NULL ENCODE lzo,"f_1"  bigint                 NOT NULL ENCODE bytedict,"f_2"  bigint                     NULL ENCODE delta32k
)
DISTSTYLE KEY
DISTKEY ( d_1 )
SORTKEY ( pk_a,pk_b );

该表以高基数维度分布.

该表按一对按时间顺序递增的字段排序.

该表包含超过20亿行,并使用~350GB的磁盘空间,均为“每个节点”.

我们的每小时管理包括更新一些最近的记录(在表的最后0.1％内,基于排序顺序)并插入另外的100k行.

无论我们选择何种机制,VACUUMing表都变得过于繁琐：
– 排序步骤需要几秒钟
– 合并步骤需要6个小时

我们可以从SELECT * FROM svv_vacuum_progress中看到;所有20亿行都被合并了.即使前99.9％完全不受影响.

我们的理解是合并只会影响：
1.删??除记录
2.插入记录
3.从(1)或(2)到表格末尾的所有记录

我们尝试过DELETE和INSERT而不是UPDATE,现在DML步骤明显更快了.但是VACUUM仍然合并了所有20亿行.

DELETE FROM fact_table WHERE pk_a > X;
-- 42 seconds

INSERT INTO fact_table SELECT <blah> FROM <query> WHERE pk_a > X ORDER BY pk_a,pk_b;
-- 90 seconds

VACUUM fact_table;
-- 23645 seconds

实际上,VACUUM合并了所有20亿条记录,即使我们只是修剪了表格末尾的最后746行.

问题

有没有人对如何避免这种巨大的VACUUM开销有任何建议,并且只有MERGE在最后0.1％的表上？

解决方法

我还发现我们不需要经常使用VACUUM我们的大表.每周一次绰绰有余.您的用例可能对性能非常敏感,但我们发现查询时间在正常变化范围内,直到表格超过90％未排序.

如果您发现有显着的性能差异,您是否考虑使用最近和历史表(如果需要,在UNION视图内)？这样你就可以快速VACUUM这个小的“最近”表.

（编辑：李大同）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!