Amazon Redshift - 查询槽、并发和队列之间的区别？

Question

我们正在构建一个商业智能系统，我们有一个巨大的 PostgreSQL 数据库 (DB)，可以在其中进行所有信息处理，还有一个 Redshift 数据仓库 (DWH)，可以在其中存储数据并执行查询。

后端是用 Java Server Faces (JSF) 构建的，之前的查询都是线性的。有些视图需要一分多钟的时间才能完成查询并将信息加载到屏幕中，因此我们决定在 Java 中使用线程并使查询异步。

因此，我们为每个视图准备了必要的查询，以便从我们的 EC2 应用程序机器并行运行到我们的 Redshift DWH，并运行线程，但视图仍然需要很长时间才能加载，有时甚至更长。

我们在文档中发现：

http://docs.aws.amazon.com/redshift/latest/dg/cm-c-executing-queries.html

http://docs.aws.amazon.com/redshift/latest/dg/c_troubleshooting_query_performance.html

http://docs.aws.amazon.com/redshift/latest/dg/r_wlm_query_slot_count.html

默认情况下，redshift 同时接收 5 个查询，但我们可以更改此设置。

有 3 个主要因素需要考虑：查询槽、并发和队列。我们已经明白了这一点：

队列就像 Java 中的线程。查询到达并被指定到“负载较少”队列，然后等待轮到它得到解决。我们可以有任意数量的队列。队列分配了一些内存（我们猜是平均分配的？）在队列中我们可以分配用户组或查询组。但短期来看，我们现在无法在查询中完成大量分类工作。

并发度是队列可以并行运行的查询量。默认为 5。

查询槽是查询可以使用的内存量。正如我们所理解的，它与并发有关。队列的并发性越高，每个查询槽中的内存就越少。

我们尝试过有 3 个队列，每个队列并发数为 5，但性能仍然很慢。

那么，如果我们理解正确的话，有些视图会进行 25-28 次查询，并且总加载时间约为 60 秒，那么我们如何保留设置才能更快地解决查询呢？

Answer 1

我认为您对查询队列的理解有点偏差。

队列就像 Java 中的线程。查询到达并被指定到“负载较少”队列，然后等待轮到它得到解决。

将查询放置在何处的决定与队列的繁忙程度无关；查询是根据您设置的规则分配的：http://docs.aws.amazon.com/redshift/latest/dg/cm-c-wlm-queue-assignment-rules.html

我们可以有任意数量的队列。

不完全是，请查看http://docs.aws.amazon.com/redshift/latest/dg/cm-c-defining-query-queues.html。相关行是

所有用户定义队列（不包括保留的超级用户队列）的最大总并发级别为 50。

所以并发肯定是有限的，但这是一个合理的限制，因为每个并发槽都会保留一些集群资源。

队列分配了一些内存（我们猜是平均分配的？）

默认情况下，内存在队列之间平均分配，但您可以以集群内存 1% 的粒度分配内存。请参阅上面有关定义查询队列的链接。

在队列中，我们可以分配用户组或查询组。但短期来看，我们现在无法在查询中完成大量分类工作。

创建用户组和设置查询组实际上非常简单，请参阅http://docs.aws.amazon.com/redshift/latest/dg/r_CREATE_GROUP.html和http://docs.aws.amazon.com/redshift/latest /dg/r_query_group.html。

如果您没有设置用户组或查询组，那么我的猜测是，在添加额外队列后您没有看到任何改进，因为所有查询仍然在单个查询队列中运行。（事实上​​，额外的队列只会从运行查询的队列中获取资源。）由于所有查询都是从同一用户运行且出于相同目的，因此它们应该全部解析到同一查询队列是有意义的。更好的解决方案可能是只有一个队列，但提高并发级别。（请记住，查询队列的资源在所有并发槽之间平均分配，即使它们没有被使用，因此并发级别为 50 意味着没有查询获​​得超过总资源的 2%。）

话虽如此，Redshift 是一个比许多其他数据库解决方案延迟更高的系统。如果您只想运行大量小型查询，那么它可能不是最适合您的问题。