哪一个在 redshift 中性能更高 - 截断后跟插入或删除并创建表为？

Question

我一直在研究 AWS Redshift，有点好奇哪种数据加载（完全重新加载）方法的性能更高。

方法 1（使用截断）：

1. 截断现有表
2. 使用 Insert Into Select 语句加载数据

方法 2（使用拖放和创建）：

1. 删除现有表
2. 使用 Create Table As Select 语句加载数据

我们一直在 ETL 中使用这两种方法，但我有兴趣了解 AWS 方面的幕后情况。

在我看来 - Drop and Create Table As 语句应该更高效，因为它减少了在 Insert Into 语句中扫描/处理关联数据块的开销。 此外，AWS Redshift 中的截断不会重新设置身份列 - Redshift Truncate table and reset Identity?

请分享你的想法。

Answer 1

Redshift 在 1MB 块上运行，作为存储和一致性的基本单元。 当对表进行更改时，这些块将被“发布”以供所有人查看何时提交更改。 表只是组成它的块 id 的列表（数据结构），因为在任何时候都可能有许多版本的表在运行（如果在其他人正在查看它时正在更改它）。

为了这个问题，让我们假设有问题的表很大（包含大量数据），我希望这是真的。 这两个语句最终执行了一个共同的操作 - 取消链接并释放表中的所有块。 这些块是所有数据存在的地方，因此您会认为这两者的速度是相同的，并且在空闲系统上它们很接近。 两者都会自动提交结果，因此在工作完成之前命令不会完成。 在这个空闲系统比较中，我看到 DROP 运行得更快，但是您需要再次创建表，因此需要时间来重新创建表的数据结构，但这可以在事务块中，所以我们需要包含 COMMIT ? 底线是，在空闲系统中，这两种方法在运行时非常接近，当我上次为客户测量它们时，DROP 方法要快一些。 我建议您在做出决定之前继续阅读。

然而，在现实世界中，Redshift 集群很少空闲，在负载情况下，这两个语句可能完全不同。 DROP 需要对表进行独占控制，因为它不在事务块内运行。 在执行 DROP 之前，必须关闭（提交或回滚）表的所有其他用途。 因此，如果您在表上执行此 DROP/recreate 过程，其他人正在使用 DROP 语句将被阻止，直到所有这些使用完成。 这可能需要一段不确定的时间才能发生。 对于“隐藏”或“未发布”表的 ETL 处理，DROP/recreate 方法可以工作，但您需要非常小心哪些其他会话正在访问相关表。

Truncate 确实在事务内部运行，但在完成时执行提交。 这意味着它不会被使用该表的其他人阻止。 只是表的一个版本是满的（对于那些在 truncate 运行之前查看它的人），一个版本是完全空的。 该表的数据结构具有每个 session 打开的版本，并且每个都看到与其版本对应的块（或缺少块）。 我怀疑它正在管理这些数据结构并通过提交队列传播这些更改，这会稍微减慢 TRUNCATE - 簿记。 这种记账的好处是 TRUNCATE 不会被其他读取表格的会话阻塞。

在这些方法之间进行选择的决定性因素通常不是性能，而是哪一种具有在您的解决方案中起作用的锁定和一致性特性。