我有一个要求，我的 Redshift 不仅可以作为前端的语义层，还可以用于表的插入和更新。
疑问：
1) 前端将是一个简单的框架，它将表格获取到 UI 并通过分页显示，截至目前，我们正在执行 select * from table，大约需要 10 秒才能获取大约 3000 行。可以做得更快吗？
2) 这对我来说是一个非常新的用例，我正在尝试找出在这种情况下哪种分发方式最好？数据非常小，只有几万左右。我正在使用 diststyle all，因为文档建议将它全部用于任何少于 100 万行的表。
3) 对于插入/更新，我们需要一个唯一列，因此我们在表格顶部创建一个自定义标识 (1,1) 列，并将其设置为排序键，因为每次更新都将通过搜索数据库中的唯一行，插入只会为其添加一个增量值。这是正确的方法还是有更复杂的方法来解决这个问题？
4) 欢迎任何其他建议。
【问题讨论】：
标签： database-design amazon-redshift data-warehouse
像 Amazon Redshift 这样的数据仓库在执行INSERT 和UPDATE 操作方面非常糟糕。
原因是每当修改一行（UPDATE）时，当前行被标记为已删除，并在存储空间的末尾追加一个新行。即使一列中只有一个值被修改，这也适用。这是因为数据是在存储块内压缩的，如果不重写整个块，就无法修改压缩数据。
当使用INSERT 添加数据时，新行将添加到每一列的存储区域的末尾。 （作为一个列式数据库，每一列都是单独存储的。）这意味着每当添加数据时，未排序区域都会增长，从而降低使用表查找数据的效率。这可以通过运行 VACUUM 来解决，这将重新排序行。
Amazon Redshift 不适合用作标准 OLTP 数据库。相反，它最适合从现有数据源加载大量信息并跨数百万行运行复杂查询。
您最好在普通数据库中进行此类更新，然后将数据提取到 Redshift 以用于报告（“只读”）目的。
对于DISTKEY/SORTKEY，一般规则是：
DISTKEY 设置为JOIN 中最常用的列，因为它将两个表中的数据共同定位到同一个切片中SORTKEY 设置为WHERE 语句中最常用的列，因为它允许Redshift“跳过”不包含匹配行的磁盘块。【讨论】：