在AWS Aurora中切分有什么好处？

Question

多主Aurora上的AWS‘’RDS文档声明如下：

在Aurora多主集群中，每个碎片由一个特定的DB实例管理，一个DB实例可以负责多个碎片。

稍后在同一文档中，我们读到：

您可以避免重新分配操作，因为集群中的所有DB实例都可以通过共享存储卷访问所有数据库和表。

因此，一个多主Aurora实例可以负责多个碎片。这在一定程度上是因为所有DB实例都访问相同的共享存储卷。

如果多主Aurora实例可以管理多个碎片，那么使用切分有什么好处呢？为什么不配置所有实例来管理所有的碎片呢？(基本上消除了切分的需要)

A理论

我怀疑不使用切分会导致更多的死锁在极光的内部，如果不同的主人在同一时间写同一页。反过来，这将导致延迟增加，而Aurora则重新尝试有争议的写入。或者，Aurora会生成一个错误，应用程序本身将不得不重试查询。(很明显，我对Aurora不够熟悉，不知道会发生什么，因此我问了这个问题)

Answer 1

我记得Facebook的马克卡拉汉( Mark )在会议上介绍了InnoDB引擎在MySQL中的可伸缩性。这是在2010年初的S，他说存储技术已经变得足够好，能够处理比InnoDB发送的更多的吞吐量。也就是说，InnoDB的软件体系结构是瓶颈，具有足够快的存储速度。他说，可以在一个存储卷上运行多个InnoDB引擎，在峰值写入输出时，然后才能饱和该卷的I/O容量。

他说的是非云托管，但Aurora的存储量也是如此。随着存储技术的进步，它能够接收比单个Aurora编写器实例能够发送的更多的写入通信量。因此，运行多个Aurora编写器实例，并将其写入同一个存储区是有意义的。

但每项技术都有一个限度，即使限制比过去更大。您无法通过单个InnoDB数据库引擎或当前一代存储每秒输出100万次写入。

这就是切分变得必要的地方。假设您的应用程序的流量增加了，所以它需要每秒处理100万次写入。但是，单个Aurora实例只能每秒处理5k写操作，因此您需要至少将写入拆分到200个集群上(假设您可以将写入平均地分开)。

但是如果最新一代的存储容量更高级，那么它可以每秒处理20k的写操作。那么多位作家也许能帮上忙。由于软件的限制，每个作者仍然只能每秒做5k。但从理论上讲，它们中的两个可以写入相同的卷，这可以处理两个卷的吞吐量。因此，您不需要将数据库分割成同样多的碎片；您可以在同一个集群中共同托管多个逻辑碎片。

这都取决于实际情况，例如，您的应用程序甚至能够非常可靠地平衡写入操作。如果有“热点”或碎片收到不成比例的写入通信量，那么它就不太好用了。

您链接到的Aurora文档听起来就像您可以在同一个Aurora集群中共同托管所有碎片，但这可能不是这样的。记住，他们所谓的技术文档也是他们销售宣传的一部分，所以他们会让它听起来比实际情况更好。

Answer 2

在AWS Aurora中切分有什么好处？

一般说来，切分有什么好处？

它允许您跨多个计算资源分配工作负载，每个计算资源都使用自己的数据子集，从而为您提供了一个横向可伸缩性选项；如果数据或工作负载增加，您可以添加更多的碎片。

传统上，分片应用程序可能如下所示：

客户端C1.3将酌情连接到服务器S1.3，而每台服务器将有自己的独立存储区，并有数据Dx的子集。

在其中一台服务器发生故障之前，所有操作都很好。在这种情况下，在恢复服务器之前，客户端将无法使用它保存的数据。为了提高可用性，经常使用复制，在其他服务器的存储中放置数据碎片的冗余副本。

因此，如果服务器发生故障，存储其数据碎片副本的其他服务器将接收负载，因此客户端继续访问所有数据。这是由于复制和更高的存储利用率而导致的网络流量增加的代价，因为您需要存储额外的数据副本。

多主Aurora通过提供一个可同时被所有服务器访问的存储卷来解决后一个问题。

这样就不需要通过网络发送数据碎片的副本，并将它们的冗余副本存储到其他地方。

在正常情况下，每个服务器只使用分配给它的碎片，但如果失败，其他服务器可以在不增加成本的情况下处理工作负载。