DELETE和INSERT之后的Redbackift(AWS)上的VACUUM

Question

我有一个表格如下(简化示例,我们有超过60个字段):

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表都变得过于繁琐:
- sort步骤需要几秒钟
- merge步骤需要6个小时

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

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

我们已尝试DELETE and INSERT而不是UPDATEDML步骤现在明显更快.但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即使我们只是在表格末尾修剪最后746行,它们也会合并所有20亿条记录.

问题

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

Answer 1

您多久清理一次桌子？持续时间长对您有何影响？我们的负载处理在 VACUUM 期间继续运行，并且我们从未遇到过这样做的任何性能问题。基本上，花多长时间并不重要，因为我们只是继续运行 BAU。

我还发现我们不需要经常清理我们的大桌子。每周一次就足够了。您的用例可能对性能非常敏感，但我们发现查询时间在正常变化范围内，直到表超过 90% 未排序。

如果您发现存在显着的性能差异，您是否考虑过使用最近的表和历史表（如果需要，在 UNION 视图内）？这样您就可以快速 VACUUM 小“最近”表。