为了在 Multi-Tenancy 维度 DW 中处理特定对象的自定义字段，我创建了 Redshift 不太喜欢的超宽非规范化维度表(数百列，列的硬编码限制)；)。
user1|attr1|attr2...attr500
即使是对少量记录的单列的无辜更新查询也需要大约 20 秒。 (这有点令人惊讶，因为我猜它在列式数据库上不应该是这样的问题。)
任何指示如何修改设计以更好地从规范化源表(一个用户有多个不同的属性，一个属性是一行)到非规范化(每个用户一行，具有通用列，每个租户不同)的报告？
或者有人试图在 Redshift 中将规范化记录转置(旋转)到非规范化 View (表)中？我担心性能。
最佳答案
考虑 Redshift 如何存储数据然后对该数据实现更新可能很重要。
每一列都存储在它自己的 1MB block 序列中，这些 block 的内容由 SORTKEY 确定。因此，排序键值的多少行可以容纳在 1MB 中就是所有其他列对应的 1MB 中有多少(以及哪些)值。
当您要求 Redshift UPDATE 一行时，它实际上会为对应于该行的所有列写入整个 block 的新版本 - 而不仅仅是 block (s ) 变化。如果您有 1,600 列，这意味着更新单行需要 Redshift 将最少 1,600MB 的新数据写入磁盘。
如果您的更新涉及许多不在同一位置的行，则此问题可能会被放大。我强烈建议选择与要更新的数据范围密切对应的 SORTKEY，以最大限度地减少写入量。
关于amazon-redshift - Redshift 和超宽表，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/40749398/