Redshift Querying: error xx000 disk full redshift

Question

我执行了以下查询

select employee_name, max(employee_dept) as dept
from employeeDB 
where employee_name is not null and employee_name != ''
group by employee_name
order by employee_name asc
limit 1000

并收到错误ERROR: XX000: Disk Full。

通过执行以下查询进行调查后，我发现我有 94​​1 GB 可用空间和 5000 GB 已用空间。

select
  sum(capacity)/1024 as capacity_gbytes, 
  sum(used)/1024 as used_gbytes, 
  (sum(capacity) - sum(used))/1024 as free_gbytes 
from 
  stv_partitions where part_begin=0;

任何人都可以建议如何缓解这一挑战，以便我能够获得预期的结果吗？

Answer 1

可用磁盘空间对于 Redshift 上的查询执行很重要。这就是为什么 VACUUM 过程很重要并且应该定期执行的原因，尤其是对于经常发生删除的表。

您最近是否清理过您的桌子？

查看 VACUUM documentation 并查看 StackOverflow 上的 Amazon Redshift at 100% disk usage due to VACUUM query 问题。

Answer 2

+-------+              +-------+
|-------|              |-------|
||10 kb||              ||25 kb||
+-------+              +-------+
|xxxxxxx|              |xxxxxxx|
|xxxxxxx|              |xxxxxxx|
|xxxxxxx+------------->+xxxxxxx|
+-------+              |xxxxxxx|
||10 kb||              |xxxxxxx|
+-------+              |xxxxxxx|
|xxxxxxx|              |xxxxxxx|
|xxxxxxx|              |xxxxxxx|
+-------+              |xxxxxxx|
||05 kb||              |xxxxxxx|
+-------+              +-------+

请看上面的表示。让我们假设xxxxxxx 代表磁盘上的已占用空间，而数字代表可用的空白空间。

两种方案都代表 25 kb 的空置空间。但在案例 1 中，如果您必须插入（或执行操作）需要连续分配内存的操作，例如 15 kb，您将无法执行此操作。虽然有 25 kb 的空间可用，但由于这不是连续的，您可能会得到一个 Memory / Disk Full Error，因此该空间将被浪费或分配给内存需求非常低的任务。

在案例 2 中，有一块连续的内存可用。可以轻松执行需要~25kb 内存的任务，

这不仅适用于 Redshift 或 DBMS；它适用于任何远程涉及内存管理的东西，包括操作系统。

是什么导致了这种内存分区（称为碎片化）？

碎片是由磁盘上不断创建和删除（修改）文件引起的。当占用空间的文件被删除时，它会在那里创建一个巨大的内存孔。小于内存孔大小的文件可能会占用该空间，否则空间将被浪费。

应该怎么做？

碎片整理！在您的具体情况下，Amazon Redshift 向VACUUM 表和/或架构提供预置。您可能有足够的磁盘空间，但没有足够的连续内存，引擎无法分配给您执行的任务。