amazon-web-services - 首次运行的查询非常慢

Question

我们的 Redshift 查询在第一次执行时极度慢。随后的执行速度要快得多(例如，45 秒 -> 2 秒)。调查此问题后，查询编译似乎是罪魁祸首。这是一个已知问题，甚至在 AWS Query Planning And Execution Workflow 上被引用和 Factors Affecting Query Performance页。亚马逊本身相当tight lipped关于查询缓存的工作原理(tl；博士，这是一个您不必担心的神奇黑匣子)。

我们尝试的其中一件事是增加我们拥有的节点数量，但是我们并不期望它能解决任何问题，因为无论如何查询编译都是一个单节点操作。它没有解决任何问题，但它是一个有趣的消遣。

如前所述，这是一个已知问题，但是，无论在何处在线讨论，唯一的要点是“这只是您使用 Redshift 时必须忍受的问题”或“这是一个 super 笨拙的解决方法，仅适用于时间，因为我们不知道查询缓存是如何工作的”。

我们能做些什么来加快编译过程或以其他方式处理这个问题吗？到目前为止，关于已找到的最佳解决方案是“预运行您可能希望在给定日期按计划运行的每个查询”，这......不是很好，特别是考虑到我们对查询缓存的工作方式知之甚少.

Answer 1

有3件事要考虑

1. 任何查询的第一次运行都会导致查询被“编译” Redshift 。这可能需要 2-20 秒，具体取决于它有多大。相同查询的后续执行使用相同的编译代码，即使 where 子句参数发生变化，也不会重新编译。
2. 当查询运行时，数据被测量为标记为“热”反对它，并缓存在 Redshift 内存中。你不能(可靠地)手动以任何方式清除它，除非重新启动集群。
3. Redshift 将“结果缓存”，具体取决于您的 redshift 参数(默认启用)redshift 将快速返回相同的结果对于完全相同的查询，如果基础数据没有改变。如果您的查询包括 current_timestamp 或类似的，那么这将如果从缓存中停止。这可以通过 SET enable_result_cache_for_session TO OFF; 关闭。

考虑到您的问题，您可能需要运行一些示例查询来预编译或重新设计您的查询(我猜您正在构建一些动态查询，这会大大改变查询的形状)。根据我的经验，更多的节点会增加编译时间。这个过程发生在主节点上而不是数据节点上，并且由于要考虑更多的数据节点而变得更加复杂。