Operazioni batch in DynamoDB: BatchGetItem e BatchWriteItem

Quando devi leggere o scrivere molti item in una volta, lanciare un GetItem o PutItem per item significa un round trip di rete per item — lento e chiacchierone. Le API batch di DynamoDB raggruppano molte operazioni su item in una singola richiesta: BatchGetItem per le letture, BatchWriteItem per le scritture.

Sono un guadagno di throughput e latenza, non una garanzia di consistenza — ed è su quella distinzione che la gente si scotta. Un batch non è una transazione.

Cosa sono le operazioni batch in DynamoDB?

Le operazioni batch di DynamoDB raggruppano molte letture o scritture di item in una singola richiesta: BatchGetItem recupera fino a 100 item, BatchWriteItem esegue put o delete su un massimo di 25, ciascuna con un limite di 16 MB. Risparmiano round trip, non capacità. Cosa fondamentale: un batch non è una transazione — gli item riescono o falliscono in modo indipendente, senza rollback.

• BatchGetItem — recupera fino a 100 item (o 16 MB) su una o più tabelle in una chiamata.
• BatchWriteItem — fino a 25 operazioni di put/delete (o 16 MB) in una chiamata. Niente update — solo put e delete.
• Non atomico. Singoli item possono riuscire mentre altri falliscono. Non c'è rollback.
• Il fallimento parziale è normale. Gli item throttlati tornano in UnprocessedItems / UnprocessedKeys — devi riprovarli tu stesso, con backoff.
• Stesso costo di capacità delle chiamate individuali — il batching risparmia round trip, non unità di capacità.

Il problema: molti item, un round trip

Diciamo che gestisci un help desk. Una dashboard deve caricare 50 ticket per ID per renderizzare una coda; un job notturno archivia 1.000 ticket risolti. Farlo un item alla volta sono 50 (o 1.000) round trip sequenziali — la latenza si accumula e il job arranca.

Il batching li comprime in una manciata di chiamate. La lettura dei 50 ticket diventa un singolo BatchGetItem; il job di archiviazione diventa un flusso di chiamate BatchWriteItem da 25 delete ciascuna. Molti meno round trip, gli stessi dati spostati.

Come funzionano le API batch

BatchGetItem prende un insieme di chiavi primarie (su una o più tabelle) e restituisce gli item corrispondenti. Puoi richiedere letture fortemente coerenti per tabella. Tutto ciò che non è riuscito a leggere — di solito perché la richiesta ha sfiorato un limite di throughput — torna in UnprocessedKeys invece di far fallire l'intera chiamata.

BatchWriteItem prende una lista di operazioni PutRequest / DeleteRequest. Nota cosa manca: non c'è alcun update. Una scrittura batch o sostituisce un intero item (put) o lo rimuove (delete) — per modificare attributi specifici hai comunque bisogno di UpdateItem. Gli item che non è riuscito a scrivere tornano in UnprocessedItems.

Il modello mentale chiave: un batch è un fascio di operazioni indipendenti, ognuna che riesce o fallisce per conto proprio — non un'unica unità tutto-o-niente.

I batch non sono transazioni

È qui la trappola. Se il batch del tuo job di archiviazione colpisce un limite di throughput a metà strada, alcuni ticket vengono cancellati e altri no — e DynamoDB non annulla quelli andati a buon fine. Non c'è rollback, niente isolamento, niente "tutti i 25 o nessuno".

Se ti serve la semantica tutto-o-niente — "sposta il ticket in archiviato e decrementa il contatore dei ticket aperti, oppure nessuna delle due" — quello è TransactWriteItems, non un batch. Le transazioni costano di più (ogni operazione è fatturata doppia) e si fermano a 100 item, ma ti danno l'atomicità che i batch deliberatamente non offrono.

Gestire gli item non elaborati

Un chiamante batch corretto controlla sempre l'insieme non elaborato e lo riprova. DynamoDB restituisce UnprocessedItems/UnprocessedKeys ogni volta che la richiesta nel suo complesso è stata accettata ma alcuni item non hanno potuto essere serviti — di solito throttling transitorio.

Ripresenta solo gli item non elaborati, con backoff esponenziale e jitter. Trattare un batch come fire-and-forget perde silenziosamente delle scritture — il tipo di bug che salta fuori mesi dopo come dati mancanti.

Scritture batch in DynoTable

Stima prima quanto costerà un job di massa con il Calcolatore di prezzi DynamoDB — un batch consuma la stessa capacità delle scritture individuali che raggruppa, solo in meno richieste.

In DynoTable, metti in stage le tue modifiche localmente e le rivedi prima di committarle come scritture batch efficienti — le modifiche di massa su molte righe partono in richieste raggruppate invece di una chiamata API per modifica, con il retry degli item non elaborati gestito per te.

Trappole e prossimi passi

• Riprova sempre UnprocessedItems/UnprocessedKeys con backoff — sono attesi, non eccezionali.
• Nessun rollback sul fallimento parziale. Ti serve atomicità? Usa le transazioni.
• Niente update in una scrittura batch — BatchWriteItem è solo put/delete; ricorri a UpdateItem per modificare gli attributi.
• Attenzione ai limiti per-chiamata — 25 scritture / 100 letture / 16 MB. Pagina i job più grandi; vedi paginazione.

Vuoi eseguire letture e scritture di massa senza scrivere il loop di retry? Scarica DynoTable e modifica le tue tabelle direttamente.