dynamoDB自动缩放比较慢

时间:2018-02-23 05:52:40

标签: amazon-web-services spring-boot amazon-dynamodb

我在我的一个应用程序中使用dynamoDB,并且我已经在桌面上启用了自动扩展,因为我的请求模式是零星的。但是我面临一个问题,流量增加的速度远远大于速度自动缩放。看下面的图片  enter image description here

通常会错过爆发,导致爆发,并在某些情况下导致数据丢失。以前有人在这面对吗?任何已知的修复?

3 个答案:

答案 0 :(得分:3)

它都解释了自动缩放如何与云观察指标一起使用,为什么它不那么“激进”。我认为你正在寻找的是你在评论中提到的那个

https://hackernoon.com/the-problems-with-dynamodb-auto-scaling-and-how-it-might-be-improved-a92029c8c10b

答案 1 :(得分:1)

对于那样的小爆发,实际上你不太可能受到限制 - 如果你在一段时间内低于阈值,发电机会给你一点额外的突发容量 - 来自DynamoDB Best Practices

  

DynamoDB在每分区吞吐量配置方面提供了一些灵活性。如果您没有充分利用分区的吞吐量,DynamoDB会保留一部分未使用的容量,以便以后突发吞吐量使用。 DynamoDB目前保留最多五分钟(300秒)的未使用读写容量。

看起来自动缩放大约10分钟后就开始了。根据他们的documentation FAQ(强调添加),这是合理的。

  

问:更改表的预配置吞吐量级别需要多长时间?

     

一般情况下,吞吐量下降需要从几秒到几分钟,而吞吐量的增加通常需要从几分钟到几个小时

     

我们强烈建议您不要尝试计划在需要额外吞吐量时几乎同时增加吞吐量。我们建议提前充分配置吞吐量,以确保在您需要时能够存储吞吐量。

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

最佳选择是在给定的时间表上进行自己的缩放,并确保规划足够的容量。

答案 2 :(得分:1)

AWS专家告诉我:DynamoDB是按分区组织的,要进行扩展,可能需要通过添加其他分区来重新组织分区。这需要时间。缓解这种情况的一种方法是创建具有等于最大配置容量的配置容量的表,一旦创建了表,就将容量减小到实际值。这样就可以实现可以支持更高容量级别的分区方案,并且在不进行重组的情况下可以更快地进行扩展。