Question

我正在使用Amazon Redshift来存储连接到巨大的日志表的关系表。

架构应如下所示：

CREATE TABLE public.my_table (
  id INT IDENTITY(1,1),
  identifier INTEGER      NOT NULL encode lzo DISTKEY,
  foreign_id VARCHAR(36)  NOT NULL encode runlength 
)
SORTKEY(foreign_id);

我的问题是：我可以将编码应用于用作DISTKEY的列（以及扩展SORTKEYs），而不会破坏重新分区和索引编制背后的逻辑吗？

是否考虑了没有编码的原始值来应用DISTKEY和SORTKEY或者压缩值？

Answer 1

是的，您可以应用压缩而不必担心影响DISTKEY。 Amazon Redshift将使用未压缩的值。

实际上，从磁盘读取块时会立即对块进行解压缩，因此所有操作都是在未压缩的数据上执行的。

请记住黄金法则：

在DISTKEY

JOIN

对SORTKEY

WHERE

始终压缩数据（磁盘读取越少意味着访问速度越快） - 自动压缩通常会找到最佳编码方法

Answer 2

经过很多天，我还设法让AWS员工回答这个问题：

1）您是否可以将编码应用于用作DISTKEY的列（以及扩展SORTKEYs），而不会破坏重新分区和索引编制背后的逻辑？

您可以将编码应用于分发键列，该列也是排序键。但是，这违反了我们的最佳做法建议，因为我们不建议将编码应用于排序键列。根据您提出的问题，DIST KEY的扩展名也可能是一个SORT键，因此不建议这样做。如果分发键不是排序键的一部分，那么您可以对其进行编码。

2）是否考虑了没有编码的原始值来应用DISTKEY和SORTKEY或者压缩值？

DISTKEY和SORTKEY算法应用于原始值。压缩仅在存储级别，这意味着在查询执行期间，它是写入时的最后一步，也是读取数据之前的第一步。看一下您使用行程长度编码对SORT KEY进行编码的示例，我们在指南中特别指出“我们不建议对任何指定为排序键的列应用runlength编码”。这是因为如果排序键列的压缩程度更高，则范围限制扫描可能表现不佳。我们建议不要压缩排序键，因为这会导致排序键偏斜。如果您有时间，请查看我们的Redshift Deep Dive视频，我们会详细讨论压缩，并实际提到这个经验法则。

编码压缩可以应用于DISTKEY（没有性能问题）

2 个答案: