Amazon dynamodb DynamoDB延迟是否取决于每个分区的项目数

这里是DDB的新手。我已经使用DDB表一年了。最近，我通过使用gzip压缩有效负载（并在DDB中将其表示为二进制）并将新数据存储在另一个新创建的beta表中进行了改进。总压缩率为3倍。我希望读取延迟（GetItem）会有所改善，同时通过网络传输的数据也会减少。但是，我发现读取延迟从~50ms p99.9增加到~114ms p99.9。我不确定这是怎么发生的，我想知道是否因为压缩，现在每个分区有很多行（我认为定义为根据您的描述，您的更改包括两个不相关的部分：您压缩了有效负载，并增加了每个分区的项目数。第一个更改-压缩-可能对p99延迟几乎没有影响（它可能会对平均延迟产生更显著的影响，根据利特尔定律，如果您的客户端具有固定的并发性，则延迟与吞吐量相关，但我希望它会降低，而不是增加）

一些人猜测是什么增加了p99延迟：

每个分区有更多的项意味着DynamoDB（使用B-树）需要进行更多的磁盘读取以查找特定项。由于每个磁盘访问都有排队引起的罕见延迟，这会增加尾部延迟

您说过更改导致每个分区容纳更多的项目，我想这意味着您现在拥有的分区更少。如果分区太少，您可能会在不同的DynamoDB分区上获得不平衡的负载，以及特定“热”分区的更多争用和延迟

我不知道你是如何测量延迟的。你的客户端现在需要（我猜）解压缩返回的结果，也许现在更忙了，在客户端中添加queening延迟？你能降低客户端的并发性（并行运行多少个客户端线程）吗看看高尾延迟是服务器设计还是客户端设计的产物

---

您好，我只压缩了有效负载。压缩有效负载的效果是每个分区（根据DDB文档，上限为10GB）现在保存的条目比以前多了3倍。我同意1和2可能会发生。但我的理解是，理想情况下，热分区不应导致延迟增加，而应导致可用性下降，不是吗？此外，DDB是否对分区键或分区和排序键组合使用B树索引？