Question

我创建了两个表，每个表都有43,547,563行：

CREATE TABLE metrics_compressed (
    some_id bigint ENCODE ZSTD,
    some_value varchar(200) ENCODE ZSTD distkey,
    ...,
    some_timestamp bigint ENCODE ZSTD,
    ...,
    PRIMARY KEY (some_id, some_timestamp, some_value)
)
sortkey (some_id, some_timestamp);

第二个与第一个完全相同，但没有压缩任何列。

运行此查询（它只计算一行）：

select count(*)
from metrics_compressed
where some_id = 20906 
and some_timestamp = 1475679898584;

显示42,394,071行的表格扫描（来自rows_pre_filter中的svl_query_summary列，列is_rrscan为真），并在未压缩的表格上运行时扫描{{ 1}}。我想这是因为压缩的一个使用了更少的1MB块，因此扫描显示了检索到的块的总行数。

扫描的行是否表现不佳？或者，Redshift在一个块中使用某种二进制搜索来进行如此简单的查询，而扫描的行只是混淆了优化查询的信息？

Answer 1

通常，您应该让Amazon Redshift确定自己的压缩类型。它通过加载100,000行并根据此示例数据确定要用于每列的最佳压缩类型来实现此目的。然后它丢弃这些行并重新启动负载。如果在列上没有指定压缩类型，则首次加载表时会自动发生这种情况。

SORTKEY对于快速查询比压缩更重要，因为它允许Redshift完全跳过不包含所需数据的块。在您的示例中，在some_id子句中使用WHERE允许它仅查看包含该特定值的块，因为它也是SORTKEY，这将非常有效。

一旦块被识别为包含SORTKEY数据的潜在，Redshift将从磁盘读取块并处理内容。

一般规则是将DISTKEY用于JOIN中最常用的列，将SORTKEY用于WHERE语句中最常用的列（但是这些列也有更微妙的变化一般规则）。

Redshift是否优化块间搜索或仅扫描整个块？

1 个答案: