redshift 是否序列化写操作？答案

【问题标题】：Does redshift serialize write operations?redshift 是否序列化写操作？
【发布时间】：2015-11-26 19:56:14
【问题描述】：

我们正在运行一个 5 dc1.large 节点集群，并且在扩展我们的数据加载时遇到了问题。

每个“加载程序”都是一个单独的进程，它： - 将 S3 中的 COPY 命令运行到临时表中 - 然后对活动表执行删除（以删除暂存表中的行） - 最后将暂存数据插入到主表中

以上基本上是doc中推荐的技术：

需要注意的一个重要细节是每个加载器都在单独的一组表上运行（即加载器之间没有锁争用，因为它们在不同的客户数据集上运行）所以加载器将复制到 L1_Staging 表并最终复制到 L1_main表，加载器二将复制到 L2_staging 并最终复制到 L2_main 表等。

我们注意到，当我们并行运行多个加载程序时，作业时间会增加，就好像 redshift 正在序列化所有写入操作一样。同样，没有锁争用。

为什么我们会看到这种模式？ redshift 不能很好地处理并行写入吗？

【问题讨论】：

写入是否可能正在使用存储的可用带宽？如果查询是 I/O 绑定的，那么其他线程将不会运行得更快。
查询肯定是 i/o 绑定的，它是一个大插入，然后是一个删除，然后是另一个插入。 Redshift 是一个黑匣子，所以我真的不知道每个查询消耗了多少 IO 吞吐量。

【解决方案1】：

是的，redshift 确实序列化了所有操作。一切都在他们的 WLM（工作负载管理）队列中排队

【讨论】：

【解决方案2】：

如果您可以将split each load 放入多个节点的倍数（在您的情况下为 5 个）的文件中，您将获得更好的性能。使用一个文件，您将被限制为一个节点的吞吐量。

在加载多个文件时使用manifest file 会很有帮助。还可以压缩文件并在表格列上启用压缩。表压缩增加了计算，但是数据可以更快地在节点之间移动以获得它需要去的地方（加载节点与静止节点不同）。

由于您正在执行频繁且繁重的删除操作，您需要在受影响的表上安排regular vacuum operations。

查询（包括副本）可以同时运行，但同时数量受资源限制（默认为每个节点 5 个）。这可以稍微调整一下。所以你应该能够有效地加载不同的表。如上所述，该问题可能与加载单个文件有关。查看query queues 上的信息。

这里有一些other hints。

【讨论】：