我在DynamoDB表上的更新中看到了一些限制.我知道节流阀每秒工作一次,高于预设容量的峰值有时会被吸收,但不能保证.我知道应该均匀分配负载,这是我没有做过的.
但请查看指标的1分钟平均图表; 连接.使用的容量远低于预配容量.这些节流阀来自哪里？因为所有写入都转到了特定的碎片？
没有批量写入.工作负载分配是不容易控制的.
DynamoDB建立在这样的假设之上:为了充分发挥您的预配置吞吐量,您的读写必须在空间(散列/范围键)和时间上均匀分布(并非所有都在同一秒内完成).
根据图表上分配的吞吐量,您仍然最有可能在一个分片上,但如果您之前已将吞吐量提高到当前级别以上并将其降低到现在的水平,则可能存在两个或更多分片.虽然这是值得注意的,但可能不是直接导致这种限制行为的原因.如果您的表中有大量数据,超过10 GB,那么您肯定会有多个分片.这意味着您的表中可能会有很多冷数据,这可能会导致此问题,但这似乎不太可能.
最可能的问题是你有一些热键.具体来说,您只有一条或几条记录正在接收大量的读取或写入请求,这会导致限制.基本上DynamoDB可以支持写入和读取的大量IOPS,但是您不能将所有这些IOPS应用于少数记录,它们需要在理想情况下统一分布在所有记录中.
由于您显示的节流阀数量在10到100秒的数量级,因此可能无需担心.只要您使用官方AWS SDK,它就会自动处理指数退避的重试,以便在完全放弃之前多次重试请求.
虽然在许多情况下很难控制对表的读写分配,但是可能值得再看一下你的散列/范围键设计,以确保它对于你的表的读写模式真的是最佳的. .此外,对于读取,您可以通过Memcached或Redis使用缓存,即使缓存在几分钟或几秒钟内过期,以帮助减少热键的影响.对于写入,您需要查看应用程序中的逻辑,以确保不会执行任何可能导致此问题的不必要写入.
最后一点与批量写入有关:DynamoDB中的批处理操作不会减少不同子请求消耗的读取或写入消耗量,它只会减少发出多个HTTP请求的开销.虽然批处理请求通常有助于提高吞吐量,但它们对降低DynamoDB中的限制可能性没有用.
京公网安备 11010802040832号 | 京ICP备19059560号-6 