dynamoDB 自动缩放很慢答案

【问题标题】：dynamoDB auto scale is slowdynamoDB 自动缩放很慢
【发布时间】：2019-11-27 04:17:00
【问题描述】：

我在我的一个应用程序中使用 dynamoDB，并且我在表上启用了自动缩放，因为我的请求模式是零星的。但是我一直面临一个问题，流量的增长速度远远超过自动缩放。看下面的图片

突发通常会丢失，这会导致其受到限制，在某些情况下还会丢失数据。这里有人遇到过这个吗？任何已知的修复？

【问题讨论】：

【解决方案1】：

对于这样的小爆发，您实际上不太可能受到限制 - 如果您在一段时间内低于阈值，发电机会为您提供一些额外的爆发能力 - 来自DynamoDB Best Practices：

DynamoDB 在每个分区的吞吐量配置方面提供了一些灵活性。当您没有充分利用分区的吞吐量时，DynamoDB 会保留一部分未使用的容量，以供以后突增使用吞吐量。 DynamoDB 目前最多保留五分钟（300 秒）未使用的读写容量。

大约 10 分钟后，自动缩放似乎开始了。根据他们的documentation FAQ（强调添加），这是合理的。

问：更改表的预置吞吐量级别需要多长时间？

一般来说，吞吐量下降将需要几秒钟到几分钟，而吞吐量增加通常需要几分钟到几小时 >.

我们强烈建议您不要尝试在需要额外吞吐量时几乎同时安排吞吐量增加。我们建议您提前充分预置吞吐量容量，以确保在您需要时就可以使用。

您提到这些峰值导致您丢失数据 - 您使用的是哪种重试策略？您是否尝试过配置超出默认值的重试？

最好的选择是按照给定的时间表进行自己的扩展，并确保规划足够的容量。

【讨论】：

【解决方案2】：

它既解释了自动缩放如何与 cloudwatch 指标一起工作，也解释了为什么它不那么“激进”。正如您在 cmets 中提到的那样，我认为这就是您正在寻找的东西

【讨论】：

【解决方案3】：

AWS 专家告诉我：DynamoDB 是按分区组织的，扩展可能需要通过添加额外的分区来重新组织分区。这需要时间。缓解这种情况的一种方法是创建预置容量等于最大预置容量的表，一旦创建表，将容量减少到实际值。这将获得可以支持更高容量级别的分区方案，并且无需重组就可以更快地进行扩展。

【讨论】：