Redshift中的sortkey是如何内部工作的？

Question

总的来说，我是Redshift和数据仓库的初学者。

当数字或时间戳列指定为sortkey时，Redshift DBMS是否在查询期间使用二进制搜索来尽可能有效地查找所需的行？

我觉得，更多地了解这一点将提高我的桌子设计技能。

Answer 1

Amazon是一个列式数据存储，这意味着每一列都分别存储。这对于宽表很好，因为Redshift只需要在查询中专门使用的列中读取。数据库查询最耗时的部分是磁盘访问，因此任何减少/避免磁盘访问的方法都是一件好事。

当数据存储在磁盘上时，数据存储在1MB的磁盘块中。每个列可以使用多个块，每个块只包含与一列相关的数据。Redshift保存每个块的区域映射，它存储存储在块中的最小值和最大值。例如，如果查询正在搜索2021年的数据，而Redshift知道某个特定块的时间戳列在2018年具有最大值，则不需要从磁盘读取该块来检查内容。这大大减少了查询时间。

数据存储在基于所选压缩编码的块中。这些是减少数据存储空间的非常聪明的技术。例如，如果列包含国家列表，并且行按国家的字母顺序排序，那么Redshift可以简单地存储块包含Jamaica x 63, then Japan x 104, then Jordan x 26这一事实。这可能只需要24个字节来存储193行数据，而且不要忘记每个块的大小是1MB。因此，压缩减少了检索数据所需的磁盘访问量，再次使查询速度更快。

要回答有关Redshift如何找到所需行的问题：

• 如果在WHERE语句中使用SORTKEY，那么Redshift可以快速找到可能包含所需数据的相关块。我不确定它是否能用二进位搜索。
• 如果WHERE语句不使用SORTKEY，那么查找正确的行就不那么有效了，因为磁盘上的许多块可能包含与不同列中的WHERE语句匹配的行，因为它们没有被排序在一起。这降低了查询的效率。
• Redshift仍然可以“跳过”不包含区域地图中所有列的匹配数据的块，从而避免了从磁盘读取这些块的需要。此外，对各种列的压缩可以减少需要从磁盘读取的块数。

Amazon 的一般规则如下：

• 将DISTKEY设置为JOIN中最常用的列
• 将SORTKEY设置为WHERE中最常用的列

请参阅：优化查询性能- Amazon