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