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