sql - DELETE 和 INSERT 后 Redshift (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 行。

无论我们选择哪种机制，对表进行 VACUUM 都变得过于繁重:
- sort一步需要几秒钟
- merge步骤需要6个多小时

我们可以从SELECT * FROM svv_vacuum_progress;看到那个全部 正在合并 20 亿行。即使前 99.9% 完全不受影响。

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

我们试过 DELETE and 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%？

Answer 1

你多久清理一次 table ？持续时间长对你有什么影响？我们的负载处理在 VACUUM 期间继续运行，我们从未遇到过任何性能问题。基本上它需要多长时间并不重要，因为我们只是继续运行 BAU。

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

如果您发现存在有意义的性能差异，您是否考虑过使用最近和历史表(如果需要，在 UNION View 中)？这样您就可以快速清空“最近”的小表。