AWS Redshift 最近发布了他们自己的新编码格式AZ64，他们说：
与 ZSTD 编码相比，AZ64 消耗的存储空间减少了 5-10%，速度提高了 70%
当我使用它时，ANALYZE COMPRESSION my_table我仍然会收到ZSTD它所有列的编码格式。
那么它真的被推荐为 ZSTD 的编码格式吗？我是否应该尽可能天真地选择 AZ64 来使用它？
问问题
1296 次
3 回答
6
我收到了 AWS Support 对这个问题的回复：
TL;博士
关于您更喜欢 AZ64 而不是 ZSTD 的问题是可能的，是的，您可以做到。
鉴于 AZ64 提供了比 ZSTD 更好的性能
进一步说明：
是的，AZ64比 ZSTD 好。与 ZSTD 相比，它具有相当的压缩率，但性能要好得多，这是您使用. 截至目前，
ANALYZE COMPRESSION命令不支持 AZ64，我也没有关于 AZ64 何时可用的 ETAANALYZE 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是一种咨询工具，它会根据列推荐最佳列编码。
于 2019-11-22T10:58:48.253 回答
2
当 ZSTD 第一次出现时，它也需要一段时间才能添加到analyze compression命令中。
ZSTD 可以用于任何数据类型，尽管有些人不会像其他人那样从中受益。你可以天真地把它应用到所有东西上，它工作得很好。
AZ64 只能应用于以下数据类型：
SMALLINT
INTEGER
BIGINT
DECIMAL
DATE
TIMESTAMP
TIMESTAMPTZ
我进行了一个实验来测试压缩因子。我惊讶地发现它并不总是让事情变得更小。
脚步
create table为原始表生成DDL- 更改了表的名称和有效列的编码
- 创建表从旧表插入新表运行
VACUUM FULL <tablename> TO 99 PERCENT旧表和新表ANALYZE <tablename>为新旧表跑
我用来检查从https://stackoverflow.com/a/33388886/1335793借来的列大小的查询
结果
- 该
id列是主键，因此具有非常大的基数，也许这有帮助？ - sort_order 列的值在 0-50 范围内，更多的值接近 0
- created_at 时间戳跨越多年，最近有更多数据
- completed_step 类似于排序顺序，但中位数更接近 0
编辑：我没有进行任何性能比较，所以这只是故事的一部分。总体而言，表的大小更小，即使某些字段不是。
于 2019-12-13T06:00:26.033 回答
0
正如 Davos 所指出的，AZ64 可以显着减少使用的存储空间。
我在两个表中使用相同的数据集进行了基本测试。一个使用 ZSTD，另一个尽可能使用 AZ64。我没有看到性能上的提升。总体而言，我看到使用 AZ64 的表查询的平均运行时间更长。
下图显示了所有查询的总执行时间。AZ64 的速度要慢得多。这是针对我的 Redshift 用例的，在某些情况下 AZ64 实际上更快。但我找不到任何东西。
完整信息可在我的博客上找到：http ://www.hydrogen18.com/blog/redshift-az64-performance-vs-zstd.html
于 2020-07-25T21:48:08.050 回答