AWS Redshift:应该压缩DISTKEY/SORTKEY列吗? [英] AWS Redshift : DISTKEY / SORTKEY columns should be compressed?

问题描述

让我问一些有关AWS Redshift上列压缩的问题. 现在，我们正在验证使用适当的diststyle，sortkey和列压缩可以使性能更好的地方.

Let me ask something about column compression on AWS Redshift. Now we're verifying what can be made better performance using appropriate diststyle, sortkeys and column compression.

如果我的理解是正确的，列压缩可以帮助降低IO成本.我尝试了分析压缩表名".并且大多数Redshift建议对我们的列使用'zstd'或'lzo'作为压缩方法.

If my understanding is correct, the column compression can help to reduce IO cost. I tried "analyze compression table_name;". And mostly Redshift suggests to use 'zstd' or 'lzo' as compression method for our columns.

总的来说，请问设置为DISTKEY/SORTKEY的列也应该像其他列一样压缩吗?

In general speaking, may I ask the columns set as DISTKEY/SORTKEY should be also compressed like other columns?

我是Redshift的新手，任何建议都将不胜感激.

I'm totally new to Redshift and any advice would be appreciated.

真诚地.

推荐答案

DISTKEY可以压缩，但 first SORTKEY列应未压缩(ENCODE raw).如果您有多个排序键(复合)，则可以压缩其他排序键列.

DISTKEY can be compressed but the first SORTKEY column should be uncompressed (ENCODE raw). If you have multiple sort keys (compound) the other sort key columns can be compressed.

此外，通常建议使用通常过滤的日期/时间戳列(如果存在)作为复合排序键中的第一排序键列.

Also, generally recommend using a commonly filtered date/timestamp column (if one exists) as the first sort key column in a compound sort key.

最后，如果要在非常大的表之间进行联接，请尝试在两个表上使用相同的dist和sort键，以便Redshift可以使用更快的合并联接.

Finally, if you are joining between very large tables try using the same dist and sort keys on both tables so Redshift can use a faster merge join.

这篇关于AWS Redshift:应该压缩DISTKEY/SORTKEY列吗?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！