DynamoDB Operazioni batch

Quando devi leggere o scrivere più elementi contemporaneamente, attiva un GetItem o PutItem per articolo significa un viaggio di andata e ritorno in rete per articolo: lento e loquace. Il lotto di DynamoDB API riunisce molte operazioni sugli elementi in una singola richiesta: BatchGetItem per le letture, BatchWriteItem per le scritture.

Sono una vittoria in termini di throughput e latenza, non una garanzia di coerenza - e questo la distinzione è dove le persone vengono bruciate. Un batch non è una transazione.

Cosa sono le operazioni batch DynamoDB?

Le operazioni batch DynamoDB riuniscono molte letture o scritture di elementi in un'unica richiesta: BatchGetItem recupera fino a 100 elementi, BatchWriteItem inserisce o elimina fino a 25, ciascuno limitato a 16 MB. Risparmiano viaggi di andata e ritorno, non capacità. Fondamentalmente, un batch non è una transazione: gli elementi riescono o falliscono in modo indipendente, senza alcun rollback.

• BatchGetItem: recupera fino a 100 elementi (o 16 MB) su una o più tabelle in una chiamata.
• BatchWriteItem: fino a 25 operazioni di inserimento/eliminazione (o 16 MB) in una chiamata. Nessun aggiornamento: solo inserimento ed eliminazione.
• Non atomico. I singoli elementi possono avere successo mentre altri falliscono. Non è previsto alcun rollback.
• Un errore parziale è normale. Gli elementi limitati ritornano in "UnprocessedItems" / "UnprocessedKeys": devi riprovarli tu stesso, con backoff.
• Stesso costo di capacità delle chiamate individuali: il raggruppamento consente di risparmiare viaggi di andata e ritorno, no unità di capacità.

Il problema: tanti oggetti, un solo viaggio di andata e ritorno

Supponiamo che tu gestisca un servizio di supporto. Una dashboard deve caricare 50 ticket per ID per eseguire il rendering di a coda; un lavoro notturno archivia 1.000 ticket risolti. Farlo un elemento alla volta è di 50 (o 1.000) round trip sequenziali: la latenza si accumula e il lavoro esegue la scansione.

Il raggruppamento li comprime in una manciata di chiamate. La lettura di 50 biglietti diventa una singola BatchGetItem; il lavoro di archiviazione diventa un flusso di chiamate BatchWriteItem di 25 elimina ciascuno. Molti meno viaggi di andata e ritorno, si spostavano gli stessi dati.

Come funzionano i batch API

BatchGetItem accetta un set di chiavi primarie (su una o più tabelle) e restituisce gli articoli corrispondenti. È possibile richiedere letture fortemente coerenti per tabella. Qualunque cosa non è stato possibile leggere, in genere perché la richiesta ha superato il limite di throughput, ritorna UnprocessedKeys anziché fallire l'intera chiamata.

BatchWriteItem accetta un elenco di operazioni PutRequest / DeleteRequest. Nota cosa manca: non c'è nessun aggiornamento. Una scrittura batch sostituisce un intero elemento (metti) o rimuovilo (elimina) - per modificare attributi specifici di cui hai ancora bisogno UpdateItem. Gli elementi che non è stato possibile scrivere ritornano in UnprocessedItems.

Un batch è un insieme di operazioni indipendenti, ciascuno riuscire o fallire da solo, non un'unità tutto o niente.

I batch non sono transazioni

Questa è la trappola. Se il batch del tuo lavoro di archiviazione raggiunge un limite di throughput a metà, alcuni i ticket vengono eliminati e altri no — e DynamoDB non annulla quelli che ha attraversato. Non c'è alcun rollback, nessun isolamento, nessun "tutti e 25 o nessuno".

Se hai bisogno della semantica tutto o niente: "sposta il ticket in archiviato e decrementa lo sportello dei biglietti aperti, o non fare nessuna delle due cose" - questo è TransactWriteItems, non un batch. Costo delle transazioni in più (ogni operazione viene fatturata il doppio) e il limite è di 100 articoli, ma ti danno il i lotti di atomicità deliberatamente non lo fanno.

Gestione di articoli non elaborati

Un chiamante batch corretto sempre controlla il set non elaborato e riprova. DynamoDB restituisce "UnprocessedItems"/"UnprocessedKeys" ogni volta che la richiesta nel suo insieme lo era accettato ma non è stato possibile pubblicare alcuni elementi, in genere limitazione temporanea.

Invia nuovamente solo gli elementi non elaborati, con backoff e jitter esponenziali. Trattare un batch come "fire-and-forget" elimina silenziosamente le scritture: il tipo di bug che emerge mesi dopo come dati mancanti.

Il batch scrive in DynoTable

Stimare prima quanto costerà un lavoro in blocco con DynamoDB calcolatore dei prezzi — un batch consuma il stessa capacità con cui l'individuo lo scrive in bundle, solo con meno richieste.

In DynoTable, metti in scena le tue modifiche localmente e le rivedi prima di confermarle — le modifiche collettive su più righe vengono inviate come richieste raggruppate anziché come una chiamata API ciascuno. Le eliminazioni in blocco vengono eseguite come scritture in batch, con il nuovo tentativo di elemento non elaborato gestito per te.

Insidie + passaggi successivi

• Riprova sempre UnprocessedItems/UnprocessedKeys con backoff: sono previsto, non eccezionale.
• Nessun rollback in caso di fallimento parziale. Hai bisogno di atomicità? Utilizzare transazioni.
• Nessun aggiornamento in una scrittura batch — BatchWriteItem viene solo inserito/eliminato; raggiungere UpdateItem per modificare gli attributi.
• Attenzione ai limiti per chiamata: 25 scritture/100 letture/16 MB. Superarli fallisce l'intera chiamata con una ValidationException (troppi elementi in BatchGetItem, in BatchWriteItem). Pagina attraverso lavori più grandi; vedere impaginazione.

Vuoi eseguire letture e scritture in blocco senza scrivere il ciclo di tentativi? Scarica DynoTable e modifica direttamente le tue tabelle.

Matematica di andata e ritorno

Le chiamate seriali GetItem pagano latenza per hop. BatchGetItem raggruppa fino a 100 chiavi o 16 MB per richiesta, a seconda del limite raggiunto per primo.

Il costo della capacità è invariato: il batching fa risparmiare tempo e CPU client, no RCU. Per le scritture, 1.000 eliminazioni a 25 per batch equivalgono a 40 chiamate BatchWriteItem invece di 1.000 eliminazioni individuali.

Letture batch altamente coerenti

BatchGetItem accetta ConsistentRead: true per tabella nella mappa delle richieste. Le letture forti costano comunque 2 volte il RCU delle letture eventuali per gli stessi elementi. Miscelazione tabelle coerenti ed eventuali in una chiamata batch vanno bene: ogni voce di tabella porta la propria bandiera.

Suddivisione di lavori di grandi dimensioni

Quando si archiviano 1.000 elementi con una media di 3 KB ciascuno, una singola lettura batch rimane sotto il limite di 100 elementi ma può superare 16 MB (100 × 3 KB = 300 KB — sicuro). Archivio Anche se hai 50 KB di elementi e raggiungi il limite di megabyte di circa 320 elementi per chiamata il limite di conteggio è 100.

La pagina scrive con cicli espliciti:

for each chunk of 25 keys:
  BatchWriteItem
  retry UnprocessedItems with backoff until empty

Il commit graduale di DynoTable raggruppa le scritture idonee e riprova gli elementi non elaborati automaticamente: lo schema che altrimenti scriveresti con un sonno agitato.

Decisione batch o transazione

Genera carichi utili di inserimento/eliminazione dal semplice JSON con Convertitore DynamoDB JSON durante il seeding del batch carichi dagli infissi.

Ispeziona la capacità consumata

Le risposte batch possono includere "ConsumedCapacity" per tabella quando richiesto. Registralo durante i riempimenti: una velocità di accelerazione in aumento si manifesta con l'aumento dei set non elaborati prima che i posti di lavoro si interrompano completamente. Controllo incrociato sostenuto WCU con il calcolatore dei prezzi se i batch vengono eseguiti su a programma.