Redshift 并发扩展如何工作？
How does Redshift concurrency scaling work?
在 AWS 文档中写道：
When you turn on concurrency scaling, Amazon Redshift automatically
adds additional cluster capacity to process an increase in both read
and write queries. Users see the most current data, whether the
queries run on the main cluster or a concurrency-scaling cluster.
这对我来说真的很模糊。
如何创建这个新集群？
"Users see the most current data"
如果数据分布在不同 EBS 磁盘上的多个节点上，如何使用最新数据创建新集群？
该功能是否基于 EBS 节点快照？
为什么你认为Redshift存储是基于EBS的？这将是一个网络存储解决方案，无法提供像 Redshift 这样的大数据解决方案所需的速度和带宽。节点存储是系统内部 AFAIK。
要了解并发集群的工作原理，让我们来看一个简单的近似值。 Redshift 一致性（允许用户看到最新信息的属性）的基础是块。这些块分布在基本集群的节点周围，因此任何节点使用的数据都可能是远程的（通过该节点的网络）。因此，即使对于基础集群，数据也可以是远程的，Redshift 一致性系统确保在所有情况下都提供任何块的正确版本。该系统是一个 MVCC 模型（多版本一致性控制），适用于分布在像 Redshift 这样的网络集群中的数据库。
并发集群可以看作是更多的节点，它们利用了基础集群的一致性系统。在这种情况下，所有数据块都远离执行工作的节点，而不仅仅是某些块。一致性系统确保将正确的块提供给任何请求节点（基本或远程）。
现在并发集群的实际实现比这更复杂，以确保高性能执行。并发集群中的节点与基础集群中的“相同”节点配对，并且可以缓存块供该集群使用。但是对这些缓存块的请求总是针对基础集群进行一致性检查，因为这是源。如果事情没有改变，那么可以使用数据的缓存版本。通过这种方式，并发集群可以拥有它需要的所有数据，并且能够相当独立地执行只读查询。一旦块被缓存在并发集群上，除了在基础集群上完成的一致性检查外，基础集群上几乎没有额外的负载。如果数据库中的大部分数据是静态的并且大部分查询负载是只读的，那么可以实现非常高级别的并发扩展。然而，如果你的数据变化很快，就会有很多额外的一致性检查和新版本块的复制。由于这些操作会影响基础集群，因此在这些情况下，一致性缩放的数量应该受到限制 (1-3)。
更新：已请求进一步探索 Redshift 存储、块和 MVCC 的参考资料和材料。
Redshift 架构概述：https://docs.aws.amazon.com/redshift/latest/dg/c_high_level_system_architecture.html
Redshift 数据组织概览：https://docs.aws.amazon.com/redshift/latest/dg/t_Distributing_data.html
AWS 对 Redshift 的深入研究（幻灯片 28 关于存储）：https://www.slideshare.net/AmazonWebServices/deep-dive-on-amazon-redshift-72473281
MVCC 概述：https://en.wikipedia.org/wiki/Multiversion_concurrency_control
Posgres8（Redshift 从 Postgres8 分叉）MVCC：https://www.postgresql.org/docs/8.1/mvcc.html
来自 re:Invent 的 Redshift 介绍介绍：https://www.slideshare.net/AmazonWebServices/deep-dive-on-amazon-redshift-72473281
作为 re:Invent 2016 年的一部分，我对此的削减：https://www.youtube.com/watch?v=bxfnWTiY7EM
在 AWS 文档中写道：
When you turn on concurrency scaling, Amazon Redshift automatically adds additional cluster capacity to process an increase in both read and write queries. Users see the most current data, whether the queries run on the main cluster or a concurrency-scaling cluster.
这对我来说真的很模糊。 如何创建这个新集群？
"Users see the most current data"
如果数据分布在不同 EBS 磁盘上的多个节点上，如何使用最新数据创建新集群？ 该功能是否基于 EBS 节点快照？
为什么你认为Redshift存储是基于EBS的？这将是一个网络存储解决方案，无法提供像 Redshift 这样的大数据解决方案所需的速度和带宽。节点存储是系统内部 AFAIK。
要了解并发集群的工作原理，让我们来看一个简单的近似值。 Redshift 一致性（允许用户看到最新信息的属性）的基础是块。这些块分布在基本集群的节点周围，因此任何节点使用的数据都可能是远程的（通过该节点的网络）。因此，即使对于基础集群，数据也可以是远程的，Redshift 一致性系统确保在所有情况下都提供任何块的正确版本。该系统是一个 MVCC 模型（多版本一致性控制），适用于分布在像 Redshift 这样的网络集群中的数据库。
并发集群可以看作是更多的节点，它们利用了基础集群的一致性系统。在这种情况下，所有数据块都远离执行工作的节点，而不仅仅是某些块。一致性系统确保将正确的块提供给任何请求节点（基本或远程）。
现在并发集群的实际实现比这更复杂，以确保高性能执行。并发集群中的节点与基础集群中的“相同”节点配对，并且可以缓存块供该集群使用。但是对这些缓存块的请求总是针对基础集群进行一致性检查，因为这是源。如果事情没有改变，那么可以使用数据的缓存版本。通过这种方式，并发集群可以拥有它需要的所有数据，并且能够相当独立地执行只读查询。一旦块被缓存在并发集群上，除了在基础集群上完成的一致性检查外，基础集群上几乎没有额外的负载。如果数据库中的大部分数据是静态的并且大部分查询负载是只读的，那么可以实现非常高级别的并发扩展。然而，如果你的数据变化很快，就会有很多额外的一致性检查和新版本块的复制。由于这些操作会影响基础集群，因此在这些情况下，一致性缩放的数量应该受到限制 (1-3)。
更新：已请求进一步探索 Redshift 存储、块和 MVCC 的参考资料和材料。
Redshift 架构概述：https://docs.aws.amazon.com/redshift/latest/dg/c_high_level_system_architecture.html
Redshift 数据组织概览：https://docs.aws.amazon.com/redshift/latest/dg/t_Distributing_data.html
AWS 对 Redshift 的深入研究（幻灯片 28 关于存储）：https://www.slideshare.net/AmazonWebServices/deep-dive-on-amazon-redshift-72473281
MVCC 概述：https://en.wikipedia.org/wiki/Multiversion_concurrency_control
Posgres8（Redshift 从 Postgres8 分叉）MVCC：https://www.postgresql.org/docs/8.1/mvcc.html
来自 re:Invent 的 Redshift 介绍介绍：https://www.slideshare.net/AmazonWebServices/deep-dive-on-amazon-redshift-72473281
作为 re:Invent 2016 年的一部分，我对此的削减：https://www.youtube.com/watch?v=bxfnWTiY7EM