【问题标题】:Amazon redshift large table VACUUM REINDEX issueAmazon redshift 大表 VACUUM REINDEX 问题
【发布时间】:2018-04-23 07:17:09
【问题描述】:

我的表有 500GB 大,有 8 亿多行,按 4 个键交错排序。 其中一个键有很大的偏差 680+。运行 VACUUM REINDEX 需要很长时间,每十亿行大约需要 5 个小时。

当我跟踪真空进度时,它会显示以下内容:

SELECT * FROM svv_vacuum_progress;
         table_name          |                                        status                                        | time_remaining_estimate 
-----------------------------+--------------------------------------------------------------------------------------+-------------------------
 my_table_name               | Vacuum my_table_name sort (partition: 1761 remaining rows: 7330776383)               | 0m 0s

我想知道它需要多长时间才能完成,因为它也没有给出任何时间估计。它当前正在处理的分区 1761... 是否有可能知道某个表中有多少个分区?请注意,这些似乎是 Redshift 中的一些存储级别较低层的分区。

【问题讨论】:

    标签: amazon-web-services amazon-redshift


    【解决方案1】:

    这些天来,建议您不要使用交错排序。

    排序算法给 VACUUM 操作带来了巨大的负担,而交错排序的好处只适用于非常小的用例。

    我建议您将 WHERE 子句中最常用的字段更改为复合排序。

    最有效的排序是那些涉及始终递增的日期字段的排序。例如,想象这样一种情况,将行添加到带有事务日期的表中。所有新行的日期都大于前一行。在这种情况下,实际上不需要 VACUUM,因为数据已经根据 Date 字段进行了排序。

    另外,请注意 500 GB 实际上是很多数据。做任何重新排列数据量的事情都需要时间。

    【讨论】:

    • 感谢约翰的意见。运行 36 小时后,真空重新索引现已完成。但最令人震惊的是,桌子的大小现在翻了一番!!!我尝试只进行真空删除,但这根本没有帮助......我不知道这里发生了什么。当在这张表上运行常规的完全真空时,它再次尝试对 8 Bil 行进行排序......我杀死了常规的完全真空,因为我认为它可能会再次使表的大小翻倍,此时它将杀死数据库!
    • 第一个明显的建议...做一个快照!其次...创建一个具有非交错排序的等效表,然后执行 SELECT INTO。运行一些典型查询以查看您是否对性能满意,然后重命名表以改用非交错版本。
    【解决方案2】:

    如果您的 Vacuum 运行缓慢,则可能是集群上没有足够的空间。我建议您在进行真空时暂时将节点数量增加一倍。

    您可能还想考虑更改架构的设置方式。值得仔细阅读这个红移提示列表,看看您是否可以更改任何内容: https://www.dativa.com/optimizing-amazon-redshift-predictive-data-analytics/

    【讨论】:

    • 谢谢汤姆。将节点列表加倍会导致大量停机和数据重新平衡,对吗?
    • 它会将其置于只读模式一段时间,是的,但我认为无论哪种方式你都必须拥有这个。我还会根据我的链接检查您表上的编码。
    【解决方案3】:

    我们恢复到上一阶段的方式是删除表,并从备份快照中的预真空索引时间恢复它。

    【讨论】:

      猜你喜欢
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 2014-09-06
      • 2010-11-02
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      相关资源
      最近更新 更多