我们正在运行一个5 dc1.large节点集群，并且在扩展数据加载时遇到了问题。
每个＆＃34;装载机＆＃34;是一个单独的过程： - 从S3运行COPY命令到临时表 - 然后在活动表上执行删除（以删除登台表中的行） - 最后将暂存数据插入主表
以上基本上是doc中推荐的技术：
需要注意的一个重要细节是每个加载器都在不同的表集上运行（即加载器之间没有锁争用，因为它们在不同的客户数据集上运行）因此加载器将复制到L1_Staging表中并最终复制到L1_main中table，loader two将复制到L2_staging并最终复制到L2_main表等。
我们注意到的是，当我们并行运行多个加载器时，作业时间会增加，就好像redshift正在序列化所有写入操作一样。同样，没有锁争用。
为什么我们看到这种模式？ redshift不能很好地处理并行写入吗？
答案 0 :(得分：1)
是的redshift确实序列化了所有操作。所有内容都在其WLM（工作负载管理）队列中排队等候
答案 1 :(得分：1)
如果您可以split each load进入多个节点的文件（在您的情况下为5），您将获得更好的性能。使用一个文件，您将受限于一个节点的吞吐量。
使用带有多个文件加载的manifest file会很有帮助。还压缩文件并在表列上启用压缩。表压缩会增加计算，但数据可以更快地在节点之间移动，以便在需要时获取（加载节点与静止节点相同）。
由于您正在进行频繁且繁重的删除操作，因此您需要在受影响的表上安排regular vacuum operations。
查询（包括副本）可以同时运行，但同步数量受资源限制（默认值为每个节点5个）。这可以稍微调整一下。因此，您应该能够有效地加载不同的表。如上所述，该问题可能与加载单个文件有关。查看query queues上的信息。
以下是一些other hints。