gpt4 book ai didi

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

转载 作者:行者123 更新时间:2023-12-04 08:52:16 26 4
gpt4 key购买 nike

我有一个如下表(简化示例,我们有 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%?

最佳答案

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

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

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

关于sql - DELETE 和 INSERT 后 Redshift (AWS) 上的 VACUUM,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/23427095/

26 4 0
Copyright 2021 - 2024 cfsdn All Rights Reserved 蜀ICP备2022000587号
广告合作:1813099741@qq.com 6ren.com