红移和超宽表

Question

红移和超宽表

3

在尝试处理多租户维度DW中特定对象的自定义字段时，我创建了一个超宽的非规范化维度表（拥有数百列和硬编码列数的限制），但Redshift似乎不太喜欢它；即便是对少量记录单列进行无辜的更新查询也要花费大约20秒钟。（这有点让人惊讶，因为我认为在列存储数据库上不应该是这样的问题。）

请问如何修改设计以从规范化的源表（一个用户有多个不同的属性，一个属性占一行）转换为非规范化的表格（每个用户一行，具有通用列，针对每个租户不同）以获得更好的报告？或者是否有人尝试过将规范化的记录转置（枢轴）为Redshift中的非规范化视图（表格）？我担心性能问题。

- Dolfa

请问您能否澄清一下 - 您是说 SELECT 的性能不佳，还是只有 UPDATE 的性能不佳？（Redshift 优化了查询而非更新。）表中有多少行数据，正在更新的行数又有多少？您是否在表上使用了 SORTKEY 和 DISTKEY？能否提供一些查询示例以展示您的情况？谢谢。 - John Rotenstein

表很小（阶段表），假设只有几十条/几百条记录，但有数百个列。查询大致如下：_update stage set validFrom = sysdate, validTo = 2999-01-01_。规划师告诉我正在执行“顺序扫描”。 - Dolfa

1个回答

网页内容由stack overflow 提供, 点击上面的

可以查看英文原文，
原文链接

- Joe Harris · Accepted Answer

重要的是要考虑Redshift如何存储数据，然后实现对该数据的更新。

每个列都以自己的1MB块序列进行存储，并且这些块的内容由SORTKEY决定。因此，无论排序键值中有多少行可以适合在1MB中，就有多少（和哪些）值对应于所有其他列的相应1MB。

当您要求Redshift UPDATE一行时，它实际上会为与该行相对应的所有列写入整个块的新版本，而不仅仅是更改的块。如果您有1,600列，那么更新单个行需要Redshift将最小1,600MB的新数据写入磁盘。

如果您的更新涉及到许多不在一起的行，则可能会放大此问题。我强烈建议选择一个SORTKEY，以便与正在更新的数据范围密切对应，以最小化写入量。