Redshift 是优化块间搜索还是只扫描整个块？

Posted 2023-03-30

【中文标题】Redshift 是优化块间搜索还是只扫描整个块？

【英文标题】：Does Redshift optimize inter-block search or just scans the whole block?

【发布时间】：2017-08-25 17:30:19

【问题描述】：

我创建了两个表，每个表都有 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 行的表扫描（来自svl_query_summary 中的rows_pre_filter 列，is_rrscan 列真），并在未压缩表上运行时扫描3,143,856。我猜这是因为压缩后的块使用较少的 1MB 块，因此扫描显示检索到的块中的总行数。

扫描的行是否表明性能不佳？或者 Redshift 是否在一个块中使用某种二进制搜索来处理像这样的简单查询，而扫描的行只是用于优化查询的混淆信息？

【问题讨论】：

性能不佳的第一个迹象是查询的执行时间，它们有什么不同，如果有的话？一般来说，不建议压缩排序键，可能是由于您猜测的问题（一个块中的行更多，在一个块中搜索的时间更长）。

对压缩表的查询需要两倍的时间。我们有一些复杂的查询需要更长的时间，而且他们还检索 3M 来计算几行。我们只是想知道是否还有其他关于压缩或键的优化，但我们需要了解它如何处理逐块检索如此多的行。也许 Redshift 更适合用来计算数百万行，而不仅仅是几行。

那么我认为答案是否定的，Redshift 没有优化块间搜索。因为它是一种列存储，可能类似于对数组进行排序，其中数组是块中一列的一大块数据。压缩排序键不是一个好习惯，因为您将搜索更大的数组。

您能否提供显示它正在扫描不同数量“行”的输出？您是指 EXPLAIN TABLE 输出中的 cost 计算吗？请提供更多信息！

^^ 我从 svl_query_summary 表中看到该查询的数据。我更新了问题。

【参考方案1】：

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

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

一旦一个块被识别为可能包含 SORTKEY 数据，Redshift 将从磁盘读取该块并处理其内容。

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

【讨论】：

谢谢，约翰。我的问题是针对您刚才描述的情况的。 “一旦一个块被识别为可能包含 SORTKEY 数据，Redshift 将从磁盘读取该块并处理内容”。进而？一旦 Redshift 有潜在的阻塞，它会提供什么样的优化？它会按顺序扫描吗？

我不知道它在 within 块中做了什么，但显然它读取了结果所需的其他块（即，包含与块读取）。当主块被高度压缩（包含很多行）时，这可能会导致问题，因为它必须读取潜在的许多其他块才能加载相同数量的行。这就是为什么他们经常建议不要压缩 DISTKEY，因为它会导致读取太多其他块。我不会太担心块内效率，因为它在 RAM 中并且只有 1MB 大小。