我开发了一个高负载的应用程序，用于从DynamoDB按需表中读取数据。假设它恒定地每秒执行大约500次读取。
我不时需要将一个大型数据集上传到数据库中(1亿条记录(。我使用python、spark和audienceproject/spark-dynamodb。我将吞吐量设置为40k，并使用BatchWriteItem()进行数据写入。
一开始，我观察到一些写限制的请求，写容量只有4k，但后来进行了升级，写容量增加了。
问题：
- 在按需表格的情况下，密集型写作会影响阅读吗？自动缩放在读/写方面独立工作吗
- 在短时间内设置大吞吐量可以吗？在我看来，按需表的成本是相同的。潜在的问题是什么
- 我观察到一些被抑制的请求，但最终，所有数据都成功上传了。这怎么解释呢？我建议我使用的客户端具有高级的速率限制逻辑，到目前为止我还没有找到明确的答案
一个问题有很多问题，你会得到一个高水平的答案
DynamoDB通过增加分区数量来扩展。每个项目都存储在一个分区上。每个分区可以处理：
- 最多3000个读取容量单元
- 最多1000个写入容量单元
- 高达10 GB的数据
一旦达到这些限制中的任何一个，就会将分区一分为二，并重新分配项。这种情况一直持续到有足够的容量来满足需求。你无法控制这种情况是如何发生的，它是一个在后台执行此操作的托管服务。
分区的数量只会不断增长。
根据这些信息，我们可以解决您的问题：
-
在按需表的情况下，密集型写作会影响阅读吗？自动缩放在读/写方面独立工作吗？
读写活动的缩放机制相同，但缩放点不同，如上所述。在按需表中，不涉及AutoScaling，这仅适用于具有规定吞吐量的表。你不应该注意到这会影响你的阅读。
-
在短时间内设置大吞吐量可以吗？在我看来，按需表的成本是相同的。潜在的问题是什么？
我假设您设置了spark可以用作编写预算的吞吐量，它不会对按需表产生太大影响。它是信息，可以在内部使用它来决定并行化的可能性。
-
我观察到一些被抑制的请求，但最终，所有数据都成功上传了。这怎么解释呢？我建议我使用的客户端具有高级的速率限制逻辑，到目前为止我还没有找到明确的答案。
如果客户端使用BatchWriteItem，它将获得无法为每个请求写入的项的列表，并可以再次将它们排入队列。可能会涉及指数退避，但这是一个实现细节。这不是魔术，你只需要记录你成功地写了哪些项目，并将那些没有写的项目重新排队，直到"；写"；队列为空。