AZ64压缩格式性能

Question

AWS Redshift 最近发布了他们自己的新编码格式AZ64，他们对此表示：

与 ZSTD 编码相比，AZ64 消耗的存储空间减少了 5-10%，速度提高了 70%

当我使用ANALYZE COMPRESSION my_table 时，我仍然收到ZSTD 作为其所有列的编码格式。

那么真的推荐它作为 ZSTD 的编码格式吗？我是不是天真地喜欢 AZ64 尽可能使用它？

Answer 1

我收到了 AWS Support 关于这个问题的回复：

TL;DR

关于您选择 AZ64 而不是 ZSTD 的问题是可能的，是的，您可以做到。

鉴于 AZ64 提供了比 ZSTD 更好的性能

进一步解释：

是的，AZ64 比 ZSTD 好。与 ZSTD 相比，它具有相当的压缩率，但性能要好得多，这是您已经了解的 using。 截至目前ANALYZE COMPRESSION 命令不支持 AZ64，我也没有关于 AZ64 何时可用的 ETA ANALYZE COMPRESSION。建议大家关注一下

• https://docs.aws.amazon.com/redshift/latest/mgmt/rs-mgmt-cluster-version-notes.html
• https://aws.amazon.com/redshift/whats-new/

有关 AWS Redshift 的任何更新。我已经与内部服务团队核实了这一点。

ANALYZE COMPRESSION 是一个咨询工具，它会根据列推荐最佳的列编码。

Answer 2

当 ZSTD 第一次出现时，它也需要一段时间才能添加到 analyze compression 命令中。

ZSTD 可以用于任何数据类型，尽管有些数据类型不会像其他数据类型那样受益。你可以天真地把它应用到所有东西上，它工作得很好。

AZ64 只能应用于这些数据类型：

SMALLINT
INTEGER
BIGINT
DECIMAL
DATE
TIMESTAMP
TIMESTAMPTZ

我进行了一个实验来测试压缩系数。我惊讶地发现它并不总是让事情变得更小。

步骤

1. 为原始表生成了create table DDL
2. 更改了表名和有效列的编码
3. 创建了从旧表插入新表的表运行
4. VACUUM FULL <tablename> TO 99 PERCENT 用于新旧表
5. 为新旧表运行 ANALYZE <tablename>

我用来检查从https://stackoverflow.com/a/33388886/1335793借来的列大小的查询

结果

• id 列是主键，因此具有非常大的基数，也许这有帮助？
• sort_order 列的值在 0-50 范围内，更多的值接近 0
• created_at 时间戳跨越多年，最近有更多数据
• completed_step 与排序顺序类似，但中位数更接近 0

编辑：我没有进行任何性能比较，所以这只是一部分 的故事。总体而言，表的大小更小，即使某些字段不是。

Answer 3

正如 Davos 所指出的，AZ64 可以显着减少使用的存储空间。

我在两个表中使用相同的数据集进行了基本测试。一个使用 ZSTD，另一个尽可能使用 AZ64。我没有看到性能上的提升。总的来说，我发现使用 AZ64 的表查询的平均运行时间更长。

下图显示了所有查询的总执行时间。 AZ64 的速度要慢得多。这是针对我的 Redshift 用例的，在某些情况下 AZ64 实际上更快。但是我找不到。

完整信息可在我的博客上找到：http://www.hydrogen18.com/blog/redshift-az64-performance-vs-zstd.html