Amazon redshift 有多个sortkey列意味着什么？

Redshift允许将多个列指定为

SORTKEY

列，但大多数最佳实践文档的编写方式都与只有一个SORTKEY一样

如果我用

SORTKEY（COL1，COL2）

创建一个表，这是否意味着所有列都是按COL1，然后按COL2排序存储的？或者，因为它是一个列存储，所以每个列的存储顺序不同？即COL1按COL1顺序排列，COL2按COL2顺序排列，其他列无序排列

我的情况是，我有一个表，其中有一个type_id和一个timestamp列。数据大致按时间戳顺序到达。大多数查询都是根据type_id和timestamp连接/限制的。通常，type_id子句更为具体，这意味着通过查看type_id子句可以排除的行的百分比比查看timestamp子句要大得多。因此，type_id是DISTKEY。我试图了解

SORTKEY（type\u id）

，

SORTKEY（stamp）

，

SORTKEY（type\u id，stamp）

，

SORTKEY（stamp，type\u id）

---

谢谢。

如果您声明

SORTKEY（COL1，COL2）

，所有列都将按

COL1

排序，然后

COL2

就好像完成了

orderby（COL1，COL2）

一样

如果您正在使用

SORTKEY

来加速联接，那么只要您在将要联接的表上使用相同的

SORTKEY

，这并不重要，因为发生的是合并联接

如果

COL1

像您的

type\u id

一样具有高度选择性，则表示只有少量行具有相同的

type\u id

。因此，尽管您可以向SORTKEY添加另一列，但它的实用性是有限的，因为大多数行消除已经发生

---

如果

COL1

不像您的

stamp

那样具有很高的选择性（顺便说一句，这有点奇怪；我本来希望它比

type\u id

？更具选择性），这意味着通过

stamp

进行过滤不会消除那么多行。因此，声明第二个排序键更有意义。但是，这比另一种方法效率低，因为提前消除行会更便宜。如果您有时按

戳记
过滤，而不是按
类型id
过滤，那么这样做可能是有意义的。
我们也在使用红移，我们有大约20亿条记录（+2000万条每天），我不得不说，排序键的选择性越低，它在排序键列表中应该越靠前

在我们的例子中（请注意分析您如何使用/查询自己的数据），我们使用时间戳作为第一个排序键。问题是，即使在1秒之内，我们也记录了大约200行，这导致我们的1MB块只包含几秒钟，并且每个块中都包含各种类型的数据。这意味着，即使时间戳是高度选择性的，但由于每个块中都有各种各样的数据，所以我们无法进一步过滤

最近我们颠倒了排序键的顺序。第一个有大约15个不同的值，第二个有大约30个，等等。。。时间戳是现在的最后一个，但是，一个块仍然是以秒为单位测量的

这将导致（因为我们经常使用前两个sort_键作为过滤器）以下结果：
旧的解决方案：一年的数据，选择一个月，它会删除91%的块，但在它打开所有的块之后，即使我们想进一步过滤

新的解决方案在第一步中删除了约14/15个块（不考虑日期范围），然后删除了约95%的剩余块，时间戳仍然删除了91%的剩余块

我们已经用两个8亿记录表对它进行了彻底的测试，除了排序键的顺序之外，它们都是相同的。“where”子句中的时间段越长，我们得到的结果越好。显然，在连接的情况下，它变得更加重要

因此，我的建议是，了解您的数据库以及您经常运行的查询类型，因为最有选择性的列可能不是最佳的第一排序键。正如Enno Shioji所说，这完全取决于您过滤的内容。
我会说
排序键的顺序应该是

首先考虑dist、filter和join中的那些
考虑过滤器中的那些，加入
以过滤器中的那些为例
考虑那些加入的人
考虑group by、order by中的那些（包括窗口功能）
一般规则：如果相同级别，则将较低的基数放在第一位。
如果您希望结果按多个列排序（或按1.2.3…），请相应地对数据进行排序。关于奇怪之处，这些类型类似于用户组（相当细粒度），并且时间戳已经经历了一些调整。顺便说一句，我发现你最近的Redshift博客文章（）也很有帮助。它并不完全是黑白的，因为sortkey的类型对于基于特定查询语义的性能非常重要，例如，交错sortkey在根据Hmm进行更复杂选择的大数据集上的性能将优于复合sortkey，这很有趣。我们发现，如果数据是随时间到达的，则必须主要按时间进行排序和分区。否则，真空和操作很快就会变得成本高昂（因为最近到达的数据不仅必须在新块中排序，而且还需要重新排列所有旧块）。在您的情况下，您认为哪个DIST KEY最合适？