在Skyeng，我们使用Amazon Redshift（包括并行缩放），因此dotgo.com创始人Stefan Gromall关于intermix.io的文章对我们来说似乎很有趣。 转移后-根据Daniyar Belkhodzhaev的观点，我们从工程师那里得到了一些经验。Amazon Redshift体系结构允许通过向集群添加新节点来进行扩展。 必须应对峰值请求数量可能会导致节点的超额配置。 与添加新节点相反，并发扩展按需增加了计算能力。
Amazon Redshift并行扩展为Redshift群集提供了额外的功能来处理高峰请求。 它通过在后台将请求传输到新的“并行”集群来工作。 根据WLM配置和规则路由请求。
并行扩展的定价基于免费使用的信用模型。 除了免费贷款的标准，还款额取决于并行扩展集群处理请求的时间。
作者在一个内部集群上测试了并行缩放。 在这篇文章中，他将讨论测试结果并提供入门指南。
集群要求
要使用并行扩展，Amazon Redshift集群必须满足以下要求：
- 平台： EC2-VPC;
- 节点类型： dc2.8xlarge，ds2.8xlarge，dc2.large或ds2.xlarge；
- 节点数： 2到32（不支持带有一个节点的集群）。
有效的请求类型
并行缩放不适用于所有类型的查询。 在第一个版本中，它仅处理满足以下三个条件的读取请求：
- 只读SELECT查询（尽管计划了更多类型）；
- 该查询不引用具有INTERLEAVED排序规则的表；
- 该查询不使用Amazon Redshift Spectrum引用外部表。
要路由到并行扩展集群，必须将请求排队。 另外，适合
SQA（短查询加速）队列的
查询将不会在并行扩展群集中执行。
队列和SQA需要正确配置
Redshift工作负载管理（WLM） 。 我们建议您首先优化WLM-这将减少并行缩放的需求。 这很重要，因为并行扩展仅在一定小时内是免费的。 AWS声称并行扩展将对97％的客户免费提供，这使我们面临定价问题。
并行缩放成本
对于并行扩展，AWS提供了一个信用模型。 每个活动的
Amazon Redshift集群每小时都会累积贷款，每天最多可以免费获得一小时的并行并行扩展贷款。
仅当使用并行扩展群集时，您才需要支付超过您收到的贷款额的费用。
成本是按超出免费速率使用的并行群集的每秒需求速率计算的。 仅在执行请求期间付款，每次激活并行扩展集群时，至少要支付一分钟。 每秒点播速率是根据
Amazon Redshift定价的一般原则计算的，也就是说，它取决于节点的类型和集群中节点的数量。
运行并行缩放
并行缩放开始于每个WLM队列。 转到AWS Redshift控制台，然后在左侧导航菜单中选择“工作负载管理”。 在下一个下拉菜单中选择群集的WLM组。
您将在每个队列旁边看到一个称为“并发扩展模式”的新列。 默认值为“关”。 单击“更改”，您可以更改每个队列的设置。
构型
并行扩展通过将相关查询转发到新的专用集群来工作。 新群集的大小（节点的类型和数量）与主群集相同。
用于并行扩展的默认群集数为一（1），最多可以配置十（10）个群集。
可以通过max_concurrency_scaling_clusters参数设置用于并行扩展的群集总数。 增加此设置可提供其他冗余群集。
监控方式
AWS Redshift控制台还有几个其他图形。 “ Max Configured Concurrency Scaling Clusters”图表显示随时间变化的max_concurrency_scaling_clusters值。
活动缩放集群的数量显示在用户界面的“并发缩放活动”部分中：
在“请求”选项卡中，有一列显示该请求是在主集群中执行还是在并行扩展集群中执行：
无论特定请求是在主集群中执行还是通过并行伸缩集群执行，该请求都存储在stl_query.concurrency_scaling_status中。
值1表示该请求正在并行伸缩集群中运行，而其他值则表明该请求正在主集群中运行。
一个例子：
有关并行缩放的信息也存储在其他一些表和视图中，例如SVCS_CONCURRENCY_SCALING_USAGE。 此外，还有许多目录表存储有关并行缩放的信息。
结果
作者于2019年3月29日格林尼治标准时间下午6:30对内部集群中的一个队列进行并行扩展。他们于2019年3月29日下午8:30将参数max_concurrency_scaling_clusters更改为3。
模拟请求队列，并将该队列的插槽数从15减少到5。
以下是一个intermix.io仪表板图，显示了减少插槽数后正在运行和排队的请求数。
我们看到队列中请求的等待时间增加了，而最大时间超过了5分钟。
以下是AWS控制台中有关这段时间发生的相关信息：
Redshift按照配置启动了三（3）个并行扩展集群。 尽管我们集群中的许多请求都已排队，但这些集群似乎并未得到充分利用。
用法图与扩展活动图相关：
几个小时后，作者检查了队列，似乎使用并行扩展执行了6个请求。 我们还通过用户界面选择性地检查了两个请求。 当几个并行集群同时处于活动状态时，他们没有检查如何使用这些值。
结论
并行缩放可以减少高峰负载期间请求的排队时间。
根据基础测试的结果，事实证明加载请求的情况已部分改善。 但是，仅并行缩放并不能解决所有并发问题。
这是由于对可以使用并行扩展的查询类型的限制。 例如，作者的许多表具有交错的排序键，而我们的大部分工作量都是一条记录。
尽管并行缩放不是WLM配置中的通用解决方案，但是在任何情况下，使用此功能都是简单易懂的。
因此，作者建议将其用于您的WLM队列。 从单个并行群集开始，并通过控制台监视峰值负载，以确定是否充分利用了新群集。
随着AWS添加对其他类型的查询和表的支持，并行扩展应逐渐变得越来越有效。
Skyeng的工程师Belkhodzhaev Daniyar的评论
Skyeng的我们也立即提请人们注意并行缩放的新兴可能性。
该功能非常吸引人，特别是考虑到AWS认为大多数用户甚至不必为此付费的事实。
碰巧的是，在4月中旬，我们向Redshift集群发出了一系列异常请求。 在此期间，我们经常求助于并发扩展，有时附加集群每天24小时不间断地工作。
如果不能完全解决排队问题，这至少可以使情况令人满意。
我们的观察结果与intermix.io给人的印象非常吻合。
我们还注意到，尽管队列中存在挂起的请求，但并非所有请求都会立即重定向到并行集群。 显然，这是由于并行集群仍需要一些时间才能启动。 结果，在短期峰值负载期间，我们的队列仍然很小，并且相应的警报还有时间工作。
正如AWS预期的那样，在4月份消除了异常负载之后，我们进入了偶发使用模式-这是免费规范的一部分。
您可以在AWS Cost Explorer中跟踪并发扩展成本。 您需要选择服务-Redshift，使用类型-CS，例如USW2-CS：dc2.large。
可以在这里找到俄语价格的详细信息。