我最初的直觉是尽可能使用 BatchWrite，但我越熟悉 DynamoDB 和 lambda，我认为如果 DynamoDB 吞吐量是您的主要瓶颈（可能是这里的情况），那应该没什么区别。
如果我有一个我不关心单个写入操作的延迟的应用程序，那么无论是 BatchWrite 还是单个 PutItem/UpdateItem 调用，lambda 是否都应该扩大直到达到 DynamoDB 的最大吞吐量？
如果出于任何其他原因单次写入是有利的（例如错误处理），那我为什么不使用它们呢？我希望整体吞吐量没有差异。这个逻辑有错误吗？我还没有测试。
【问题讨论】：
标签： amazon-web-services performance aws-lambda amazon-dynamodb throughput
对于个别请求，您只会浪费资源。但是 lambda 的扩展性非常好，你甚至可能看不到它。
长话短说，进行 dynamoDB 查询需要一些隐藏的计算。您必须准备好您的请求、对其进行身份验证并通过网络发送。与使用两倍有效负载（但只有一个标头）进行单次查询相比，进行两次会浪费 CPU 时间和网络带宽。
在某些时候触发单个请求的成本会更高，但很可能开销成本对您来说不是问题。这很可能取决于您的实际使用情况。
【讨论】：
您的PutItem 请求首先到达请求路由器，然后请求路由器将识别负责您的项目的三个存储节点（基于分区键）并将新数据发送到所有三个存储节点。一旦三个存储节点中的两个确认写入，它就会响应您它已写入该项目。
这是一个有根据的猜测，据我所知，它没有正式记录，但在我看来这是有道理的。
当您发送BatchPutItem 请求时，此请求也会到达请求路由器，并包含多个要写入的不同项目。对于每个单独的项目，路由器将识别相关的存储节点，写入它们并等待其中两个确认写入。这很可能是以某种方式并行化的，而不是完全顺序的。一旦所有项目都处理完毕（成功或不成功），您就会收到响应，DynamoDB 会告诉您哪些项目失败了。
当您必须编写多个项目时，使用单独的 PutItem 调用可能会导致从您的客户端建立到 DynamoDB 的更多网络连接，这在时间方面是昂贵的。但是：现有的 TCP 连接通常会保留一段时间，并且会被重新使用，因此这种影响可能是有限的。对于BatchWriteItem，网络请求较少，应该会改善网络延迟。
正如@aherve 在他们的answer 中正确指出的那样，在您的客户端向 DynamoDB 发送请求时也会产生一些开销。您需要对数据进行编码、计算一些校验和并使用您的凭据对请求进行签名，这需要 CPU 时间，因此最大限度地减少请求量可能对您的客户端有益。
对于您写入的每个单独项目，无论您使用 BatchPutItem 还是多个 PutItem 调用，DynamoDB 都会消耗每个项目所需的写入容量单位。 消耗的写入容量没有差异。
DynamoDB 在检查身份验证时可能会在内部进行一些优化，但我预计这不会太多，因为 DynamoDB 仍然需要对每个单独的写入进行身份验证，因为您可以使用 IAM conditions。
在错误处理方面，单独的PutItem 调用非常简单：如果写入失败，则调用失败，您可以修复数据并重试。 BatchPutItem 需要更复杂的错误处理，因为即使写入部分失败，调用也会成功。您需要检查失败项目的响应并自行重试。这是增加的复杂性，您需要维护。
【讨论】：