基于 VARCHAR 大小的 Amazon Redshift 查询性能不佳

Question

我正在构建一个 Amazon Redshift 数据仓库，并且遇到了基于 VARCHAR 列的定义大小的意外性能影响。详情如下。我的三个专栏来自 pg_table_def：

 schemaname | tablename |     column      |            type             | encoding  | distkey | sortkey | notnull 
------------+-----------+-----------------+-----------------------------+-----------+---------+---------+---------
 public     | logs      | log_timestamp   | timestamp without time zone | delta32k  | f       |       1 | t
 public     | logs      | event           | character varying(256)      | lzo       | f       |       0 | f
 public     | logs      | message         | character varying(65535)    | lzo       | f       |       0 | f

我最近运行了 Vacuum 和 Analyze，我在数据库中有大约 1 亿行，我看到的性能非常不同，具体取决于我包含的列。

查询 1： 例如，以下查询大约需要 3 秒：

select log_timestamp from logs order by log_timestamp desc limit 5;

查询 2： 要求更多数据的类似查询在 8 秒内运行：

select log_timestamp, event from logs order by log_timestamp desc limit 5;

查询 3： 但是，这个查询与前面的非常相似，需要 8 分钟才能运行！

select log_timestamp, message from logs order by log_timestamp desc limit 5;

查询 4： 最后，这个查询与慢查询相同，但有明确的范围限制，非常快（~3s）：

select log_timestamp, message from logs where log_timestamp > '2014-06-18' order by log_timestamp desc limit 5;

message 列被定义为能够容纳更大的消息，但实际上它并没有容纳太多数据：消息字段的平均长度为 16 个字符（std_dev 10）。事件字段的平均长度为 5 个字符（std_dev 2）。我真正能看到的唯一区别是 VARCHAR 字段的最大长度，但我认为这不会对简单查询返回的时间产生一个数量级的影响！

任何见解将不胜感激。虽然这不是这个工具的典型用例（我们将汇总远远超过我们将检查单个日志），但我想了解我的表格设计的任何微妙或不那么微妙的影响。

谢谢！

戴夫

Answer 1

Redshift 是一个“真正的列式”数据库，仅读取查询中指定的列。因此，当您指定 2 个小列时，只需读取这 2 个列。但是，当您添加到第 3 大列时，Redshift 必须做的工作会急剧增加。

这与将整行存储在一起的“行存储”数据库（SQL Server、MySQL、Postgres 等）非常不同。在行存储中，添加/删除查询列对响应时间没有太大影响，因为无论如何数据库都必须读取整行。

最后，您的最后一个查询非常快的原因是您告诉 Redshift 它可以跳过大部分数据。 Redshift 将您的每一列存储在“块”中，这些块根据您指定的排序键进行排序。 Redshift 会记录每个块的最小值/最大值，并且可以跳过任何不能包含要返回的数据的块。

limit 子句不会减少必须完成的工作，因为您告诉 Redshift 它必须首先按 log_timestamp 降序排列 all。 问题是您的 ORDER BY ... DESC 必须在整个潜在结果集上执行，然后才能返回或丢弃任何数据。列小时快，列大时慢。

Answer 2

出于好奇，这需要多长时间？

select log_timestamp, message
from logs l join
     (select min(log_timestamp) as log_timestamp
      from (select log_timestamp
            from logs
            order by log_timestamp desc
            limit 5
           ) lt
     ) lt
     on l.log_timestamp >= lt.log_timestamp;