# 高效执行批量操作
<a name="BestPractices_EfficientBulkOperations"></a>

**使用此模式的时机**

这些模式对于在 DynamoDB 项目上高效地执行批量更新非常有用。
+ 生产环境应用场景不支持 DynamoDB-shell。
+ `TransactWriteItems` – 最高 100 个单独的更新，可以有条件或无条件，以全有或全无的 ACID 捆绑的形式执行 

  权衡 – 会消耗额外的吞吐量，每 1 KB 写入 2 个 WCU。
+ PartiQL `BatchExecuteStatement` – 最高 25 个更新，可以有条件或无条件

  权衡 – 需要额外的逻辑，以便按照 25 的批次大小分发请求。
+ AWS Step Functions – 为熟悉 AWS Lambda 的开发人员提供速率受限的批量操作。

  权衡 – 执行时间与速率限制成反比。受最大 Lambda 函数超时时间的限制。该功能会使得在读取和写入之间发生的数据更改可能会被覆盖。有关更多信息，请参阅 [Backfilling an Amazon DynamoDB Time to Live attribute using Amazon EMR: Part 2](https://aws.amazon.com/blogs/database/part-2-backfilling-an-amazon-dynamodb-time-to-live-attribute-using-amazon-emr/)。
+ AWS Glue 和 Amazon EMR – 速率受限的批量操作，采用托管式并行度。对于不注重时效性的应用程序或更新，这些选项可以在后台运行，只消耗一小部分吞吐量。这两项服务都使用 emr-dynamodb-connector 来执行 DynamoDB 操作。这些服务会执行大量读取，然后大量写入更新的项目，并有速率限制选项。

  权衡 – 执行时间与速率限制成反比。使用该功能时，所包含的在读取和写入之间发生的数据更改可能会被覆盖。您无法从全局二级索引（GSI）中读取。请参阅 [Backfilling an Amazon DynamoDB Time to Live attribute using Amazon EMR: Part 2](https://aws.amazon.com/blogs/database/part-2-backfilling-an-amazon-dynamodb-time-to-live-attribute-using-amazon-emr/)。
+ DynamoDB Shell – 使用类似 SQL 的查询执行速率受限的批量操作。您可以从 GSI 中读取以提高效率。

  权衡 – 执行时间与速率限制成反比。请参阅 [Rate limited bulk operations in DynamoDB Shell](https://aws.amazon.com/blogs/database/rate-limited-bulk-operations-in-dynamodb-shell/)。

## 使用模式
<a name="BestPractices_EfficientBulkOperations_UsingThePattern"></a>

批量更新会对成本造成巨大的影响，尤其是当您使用按需吞吐量模式时。如果您使用预置吞吐量模式，则需要在速度和成本之间进行权衡。设置极为严格的速率限制参数可能会导致极长的处理时间。您可以使用平均项目大小和速率限制来大致确定更新速度。

或者，您可以根据更新过程的预期持续时间以及平均项目大小，来确定该过程所需的吞吐量。随各模式提供的博客引用详细介绍了使用该模式的策略、实施和限制。有关更多信息，请参阅 [Cost-effective bulk processing with Amazon DynamoDB](https://aws.amazon.com/blogs/database/cost-effective-bulk-processing-with-amazon-dynamodb/)。

在对活动 DynamoDB 表执行批量更新时，可以采取多种方法。哪种方法合适取决于多种因素，例如 ACID 和/或幂等性等要求、要更新的项目数量以及对 API 的熟悉程度等。此处非常重要的一点是要权衡成本与时间，上文讨论的大多数方法都提供了选项，可对更新作业使用的吞吐量限制速率。