Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.

# Operazioni in blocco efficienti
<a name="BestPractices_EfficientBulkOperations"></a>

**Quando usare questo modello**

Questi modelli sono utili per eseguire in modo efficiente aggiornamenti in blocco sugli elementi di DynamoDB.
+ DynamoDB-Shell non è un caso d’uso supportato per la produzione.
+ `TransactWriteItems`: fino a 100 aggiornamenti singoli con o senza condizioni, eseguiti come un pacchetto ACID “tutto o niente” 

  Compromesso: viene consumata una velocità effettiva aggiuntiva, 2 per 1 KB di scrittura. WCUs 
+ PartiQL`BatchExecuteStatement`: fino a 25 aggiornamenti con o senza condizioni

  Compromesso: è necessaria una logica aggiuntiva per distribuire le richieste in batch da 25.
+ AWS Step Functions — operazioni di massa a velocità limitata per gli sviluppatori che hanno dimestichezza con. AWS Lambda

  Compromesso: il tempo di esecuzione è inversamente proporzionale al limite di velocità. Limitazione data dal timeout massimo della funzione Lambda. La funzionalità prevede che le modifiche ai dati che si verificano tra la lettura e la scrittura possano essere sovrascritte. Per ulteriori informazioni, consulta [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 e Amazon EMR: operazioni di massa a velocità limitata con parallelismo gestito. Per le applicazioni o gli aggiornamenti non sensibili al fattore temporale, queste opzioni possono essere eseguite in background consumando solo una piccola percentuale del throughput. Entrambi i servizi utilizzano il emr-dynamodb-connector per eseguire operazioni DynamoDB. Questi servizi eseguono una lettura approfondita seguita da una scrittura approfondita degli elementi aggiornati con un’opzione per limitare la velocità.

  Compromesso: il tempo di esecuzione è inversamente proporzionale al limite di velocità. La funzionalità prevede che le modifiche ai dati che si verificano tra la lettura e la scrittura possano essere sovrascritte. Non è possibile leggere da Global Secondary Indexes (). GSIs Consulta [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: operazioni in blocco a velocità limitata attraverso query di tipo SQL. Puoi leggere da GSIs per una migliore efficienza.

  Compromesso: il tempo di esecuzione è inversamente proporzionale al limite di velocità. Consulta [Rate limited bulk operations in DynamoDB Shell](https://aws.amazon.com/blogs/database/rate-limited-bulk-operations-in-dynamodb-shell/).

## Utilizzo del modello
<a name="BestPractices_EfficientBulkOperations_UsingThePattern"></a>

Gli aggiornamenti in blocco possono avere implicazioni significative in termini di costi, soprattutto se si utilizza la modalità di throughput on demand. Esiste un compromesso tra velocità e costi se si utilizza la modalità di throughput allocato. L’impostazione molto rigorosa del parametro del limite di velocità può portare a tempi di elaborazione molto lunghi. È possibile determinare approssimativamente la velocità di aggiornamento utilizzando la dimensione media dell’elemento e il limite di velocità.

In alternativa, è possibile determinare la quantità di throughput necessaria per il processo in base alla durata prevista del processo di aggiornamento e alla dimensione media degli elementi. I riferimenti del blog condivisi con ogni modello forniscono dettagli sulla strategia, l’implementazione e i limiti dell’utilizzo del modello. Per ulteriori informazioni, consulta [Cost-effective bulk processing with Amazon DynamoDB](https://aws.amazon.com/blogs/database/cost-effective-bulk-processing-with-amazon-dynamodb/).

Esistono diversi approcci per eseguire aggiornamenti in blocco su una tabella DynamoDB attiva. L'approccio adatto dipende da fattori quali i requisiti di and/or idempotenza ACID, il numero di elementi da aggiornare e la familiarità con cui si è in possesso. APIs È importante considerare il rapporto tra costi e tempi: la maggior parte degli approcci sopra descritti prevede un’opzione per limitare il throughput utilizzato dal processo di aggiornamento in blocco.