由于运行查询

Question

由于查询运行时间超过100小时，在Aginity中我们看到我们的群集大小从1到5 TB。

通过检查svv_table_info，我们看到每个表的大小比我们过去看到的大。之后，我们检查了AWS控制台，我们看到5天前开始大小增加，同时开始运行100小时查询。

杀死查询后，Redshift大小恢复到1 TB后几分钟，每个表格大小恢复正常。

为什么会这样？

仅仅是为了记录，100小时运行查询并不涉及在查询运行时大小显着增加的所有表。

EDITED

我现在无法真正重现错误。但步骤如下：

• 在Aginity中，我偶然发现群集大小为5TB，即使群集只有2 x ds2.xlarge节点（总共4TB）

• 我查询svv_table_info以获取每个表的大小 - 它们总计达到5TB，我看到它们中的大多数看起来非常大

• 我看到DWH拥有所有最新数据，即使它“据报道”已满至少2天（它也超过了4TB）

• 我看到一个正在运行的查询超过100个小时，其中一个数据分析师留下了一个打开的笔记本。查询并未涉及所有似乎不合理的大表

• 我终止查询，片刻后一切都恢复正常

所以： - 如果我们只有2x2TB = 4TB的可用空间，Redshift如何增长到5TB！

Answer 1

也发生在我们身上。 Redshift在运行查询时使用磁盘空间，这就是当您终止查询时群集大小恢复正常的原因。

这是关于https://www.periscopedata.com/blog/disk-based-temporary-tables

的非常好的文章

Answer 2

先区分Amazon Redshift在查询执行期间如何使用存储可能会有所帮助。有两种方法：

1. 基于磁盘的查询。当查询用完内存时，溢出“溢出”到磁盘，查询变为“基于磁盘”。
2. 中间存储。当查询需要保存中间操作的结果时，可用作将来操作的输入。

在这种情况下，我认为您正在考虑使用中间存储。无论查询计算出什么，它都会开始用中间结果填充磁盘。当查询进入连接两个非常大的表（例如每个都有数十亿行）的查询时，通常会发生这种情况，这些表通常是由没有编写OLAP查询经验的人编写的。 5TB的绝对数量与所用磁盘空间百分比的相关性较小，在您的情况下为100％。

我们写了一篇有关如何解决基于磁盘的查询的文章，其中详细介绍了Redshift：https://www.intermix.io/blog/how-to-fix-disk-based-queries-amazon-redshift/