没有 INSERT_XID 的 RedShift 深度复制（隐藏元数据）列数据
RedShift Deep Copy Without INSERT_XID (Hidden metadata) Column Data
我在 AWS Redshift 中有一个又长又窄的 table。它已成为隐藏元数据列 INSERT_XID 问题的受害者，与 table.
相比，它的大小非常不成比例
画一个 table 的 632K 行，其中包含 22gb 可见数据和一个包含 83gb 的隐藏列。
我想收回 space，但是 Vacuum has no effect on it
我尝试复制 table:
BEGIN;
CREATE TABLE test.copied (like prod.table);
INSERT INTO test.copied (select * from prod.table);
COMMIT;
这会导致真正的深层复制，其中隐藏的元数据列仍然非常大。我希望 table 的副本一次进入一个新副本将允许压缩隐藏的 INSERT_XID 列，但它没有这样做。
有什么想法可以优化 AWS Redshift 中的这个隐藏列吗？
我用以下方法测量了每列的大小：
SELECT col, attname, COUNT(*) AS "mbs"
FROM stv_blocklist bl
JOIN stv_tbl_perm perm
ON bl.tbl = perm.id AND bl.slice = perm.slice
LEFT JOIN pg_attribute attr ON
attr.attrelid = bl.tbl
AND attr.attnum-1 = bl.col
WHERE perm.name = 'table_name'
GROUP BY col, attname
ORDER BY col;
更新：
我还尝试将此 table 卸载到 S3 中，然后将单个 COPY 返回到新的 table 中，隐藏列的大小没有改变。我不确定这是否可以解决。
谢谢！
我对你提供的数字做了一些计算，我认为你可能 运行 进入 1MB 块大小的量子效应。但是，数学还是不行。
Redshift 根据 table 的分布方式将数据存储在集群周围。对于非 diststyle-all tables 这意味着每列在集群的每个切片上都有行。 Redshift 上的最小存储大小，一个块，大小为 1MB。当您的 table 中的行数较少（对于 Redshift）时，每个切片上的数据不足以填满一个块，因此磁盘上有很多浪费的 space。
如果你有一个 table 的 2 列，其中有 630K 行，并且你正在处理一个有 1024 个切片的集群（比如 dc2.8xl 的 32 个节点），那么这些影响会非常明显。每个切片只有 615 行（平均），几乎没有填满 1MB 块的地方。所以这个 table 的非元数据部分将占用 2X1024X1MB = 2.048gb。如您所见，即使在这种情况下，我也只能得到您所显示内容的十分之一。
我可以用 20 列而不是 2 列重新运行它，我会达到你的 22gb 数字，但是这样元数据列的大小就没有多大意义了——它们并不是那么低效。有可能我没有像您那样查看配置 - 4000 片？ 8 列？
22gb of space 是 22,000 个块分布在集群的切片和列中/table。了解您的列数和集群配置将极大地帮助理解数据的存储方式。
建议 - 将此 table 移至 DISTSTYLE ALL，您将大大节省存储空间 space。 60 万行对于 Redshift 来说太小了，而且将数据分散到所有切片中效率很低。请注意，DISTSTLYE ALL 对查询编译有影响 - 大多数是积极的，但并非全部，因此如果您进行此更改，请监控您的查询性能。
我在 AWS Redshift 中有一个又长又窄的 table。它已成为隐藏元数据列 INSERT_XID 问题的受害者，与 table.
相比，它的大小非常不成比例画一个 table 的 632K 行，其中包含 22gb 可见数据和一个包含 83gb 的隐藏列。
我想收回 space，但是 Vacuum has no effect on it
我尝试复制 table:
BEGIN;
CREATE TABLE test.copied (like prod.table);
INSERT INTO test.copied (select * from prod.table);
COMMIT;
这会导致真正的深层复制，其中隐藏的元数据列仍然非常大。我希望 table 的副本一次进入一个新副本将允许压缩隐藏的 INSERT_XID 列，但它没有这样做。
有什么想法可以优化 AWS Redshift 中的这个隐藏列吗？
我用以下方法测量了每列的大小：
SELECT col, attname, COUNT(*) AS "mbs"
FROM stv_blocklist bl
JOIN stv_tbl_perm perm
ON bl.tbl = perm.id AND bl.slice = perm.slice
LEFT JOIN pg_attribute attr ON
attr.attrelid = bl.tbl
AND attr.attnum-1 = bl.col
WHERE perm.name = 'table_name'
GROUP BY col, attname
ORDER BY col;
更新：
我还尝试将此 table 卸载到 S3 中，然后将单个 COPY 返回到新的 table 中，隐藏列的大小没有改变。我不确定这是否可以解决。
谢谢！
我对你提供的数字做了一些计算，我认为你可能 运行 进入 1MB 块大小的量子效应。但是，数学还是不行。
Redshift 根据 table 的分布方式将数据存储在集群周围。对于非 diststyle-all tables 这意味着每列在集群的每个切片上都有行。 Redshift 上的最小存储大小，一个块，大小为 1MB。当您的 table 中的行数较少（对于 Redshift）时，每个切片上的数据不足以填满一个块，因此磁盘上有很多浪费的 space。
如果你有一个 table 的 2 列，其中有 630K 行，并且你正在处理一个有 1024 个切片的集群（比如 dc2.8xl 的 32 个节点），那么这些影响会非常明显。每个切片只有 615 行（平均），几乎没有填满 1MB 块的地方。所以这个 table 的非元数据部分将占用 2X1024X1MB = 2.048gb。如您所见，即使在这种情况下，我也只能得到您所显示内容的十分之一。
我可以用 20 列而不是 2 列重新运行它，我会达到你的 22gb 数字，但是这样元数据列的大小就没有多大意义了——它们并不是那么低效。有可能我没有像您那样查看配置 - 4000 片？ 8 列？
22gb of space 是 22,000 个块分布在集群的切片和列中/table。了解您的列数和集群配置将极大地帮助理解数据的存储方式。
建议 - 将此 table 移至 DISTSTYLE ALL，您将大大节省存储空间 space。 60 万行对于 Redshift 来说太小了，而且将数据分散到所有切片中效率很低。请注意，DISTSTLYE ALL 对查询编译有影响 - 大多数是积极的，但并非全部，因此如果您进行此更改，请监控您的查询性能。