Transazioni Amazon DynamoDB: come funzionano - Amazon DynamoDB
TransactWriteItemsTransactGetItemsLivelli di isolamentoGestione dei conflitti nelle transazioniTransazioni in DAXGestione della capacitàBest practiceUtilizzo di tabelle transazionali con tabelle globali APIsTransazioni e libreria del client

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à.

Transazioni Amazon DynamoDB: come funzionano

Con le transazioni Amazon DynamoDB, puoi raggruppare più azioni e inviarle come singola all-or-nothing TransactWriteItems operazione. TransactGetItems Le sezioni seguenti descrivono API le operazioni, la gestione della capacità, le best practice e altri dettagli sull'utilizzo delle operazioni transazionali in DynamoDB.

TransactWriteItems API

TransactWriteItemsè un'operazione di scrittura sincrona e idempotente che raggruppa fino a 100 azioni di scrittura in un'unica operazione. all-or-nothing Queste azioni possono indirizzare fino a 100 elementi distinti in una o più tabelle DynamoDB all'interno dello AWS stesso account e nella stessa regione. La dimensione aggregata degli elementi nella transazione non può superare i 4 MB. Le operazioni vengono completate in modo atomico, in maniera tale che abbiano tutte esito positivo oppure abbiano tutte esito negativo.

Nota

  • Un'operazione TransactWriteItems differisce da un'operazione BatchWriteItem nel fatto che tutte le operazioni che contiene devono essere completate con successo, altrimenti non viene apportata alcuna modifica. Con un'operazione BatchWriteItem, è possibile che solo alcune azioni nel batch abbiano esito positivo, contrariamente alle altre.

  • Le transazioni non possono essere eseguite utilizzando gli indici.

Non è possibile fare riferimento allo stesso item con diverse operazioni all'interno della stessa transazione. Ad esempio, non è possibile eseguire un'operazione ConditionCheck e Update per lo stesso item nella stessa transazione.

È possibile aggiungere uno dei seguenti tipi di operazioni a una transazione:

  • Put: avvia un'operazione PutItem per creare un nuovo elemento o sostituire un vecchio elemento con uno nuovo, in base a condizioni o senza specificare alcuna condizione.

  • Update: avvia un'operazione UpdateItem per modificare gli attributi di un elemento esistente o aggiungere un nuovo elemento alla tabella se non è già presente. Utilizza questa operazione per aggiungere, eliminare o aggiornare attributi su un item esistente in base a condizioni o senza una condizione.

  • Delete: avvia un'operazione DeleteItem per eliminare un singolo elemento in una tabella identificata dalla chiave primaria.

  • ConditionCheck: verifica che un elemento esista o controlla la condizione di attributi specifici dell'elemento.

Una volta completata una transazione, le modifiche apportate all'interno di tale transazione vengono propagate agli indici secondari globali (GSIs), ai flussi e ai backup. Poiché la propagazione non è immediata o istantanea, se una tabella viene ripristinata da backup (RestoreTableFromBackup) o esportata in un punto temporale () durante la propagazione, potrebbe contenere alcune ma non tutte le modifiche apportate durante una transazione recente. ExportTableToPointInTime

Idempotenza

È possibile includere un token client quando si effettua una chiamata TransactWriteItems per garantire che la richiesta sia idempotente. Rendere le transazioni idempotenti impedisce errori nelle applicazioni se la stessa operazione viene inviata più volte a causa di un timeout della connessione o altri problemi di connettività.

Se la chiamata TransactWriteItems originale è andata a buon fine, allora le successive chiamate TransactWriteItems con lo stesso token client hanno esito positivo senza apportare alcuna modifica. Se viene impostato il parametro ReturnConsumedCapacity, la chiamata TransactWriteItems iniziale restituisce il numero di unità di capacità in scrittura consumate mentre venivano apportate le modifiche. Le successive chiamate TransactWriteItems con lo stesso token client restituiscono il numero di unità di capacità in lettura consumate durante la lettura dell'item.

Considerazioni importanti sull'idempotenza

  • Un token client è valido per 10 minuti dopo il termine della richiesta che lo utilizza. Dopo 10 minuti, qualsiasi richiesta che utilizza lo stesso token client viene trattata come una nuova richiesta. Lo stesso token client non deve essere riutilizzato per la stessa richiesta dopo 10 minuti.

  • Se si ripete la richiesta con lo stesso token client all'interno della finestra di idempotenza di 10 minuti, ma vengono modificati altri parametri, DynamoDB restituisce un'eccezione IdempotentParameterMismatch.

Gestione degli errori per scrittura

Le transazioni di scrittura non hanno esito positivo nelle seguenti circostanze:

  • Quando una condizione in una delle espressioni di condizione non viene soddisfatta.

  • Quando un errore di convalida della transazione si verifica in quanto un'operazione all'interno della stessa operazione TransactWriteItems mira allo stesso item.

  • Quando una richiesta TransactWriteItems è in conflitto con un'operazione TransactWriteItems in corso su uno o più item nella richiesta TransactWriteItems. In questo caso, la richiesta ha esito negativo con una TransactionCanceledException.

  • Quando la capacità assegnata è insufficiente per il completamento della transazione.

  • Quando la dimensione di un elemento diventa troppo grande (superiore a 400 KB) o un indice secondario locale (LSI) diventa troppo grande o si verifica un errore di convalida simile a causa delle modifiche apportate dalla transazione.

  • Quando è presente un errore utente, come un formato di dati invalido.

Per ulteriori informazioni sulla gestione dei conflitti con le operazioni TransactWriteItems, consulta Gestione dei conflitti nelle transazioni in DynamoDB.

TransactGetItems API

TransactGetItems è un'operazione di lettura sincrona che raggruppa fino a 100 operazioni Get. Queste azioni possono indirizzare fino a 100 elementi distinti in una o più tabelle DynamoDB all'interno dello stesso account e della AWS stessa regione. La dimensione aggregata degli elementi nella transazione non può superare i 4 MB.

Le operazioni Get vengono eseguite in modo atomico, in maniera tale che abbiano tutte esito positivo oppure abbiano tutte esito negativo.

  • Get: avvia un'operazione GetItem per recuperare un set di attributi dell'elemento con la chiave primaria specificata. Se non viene trovato un item corrispondente, Get non restituisce dati.

Gestione degli errori per lettura

Le transazioni di lettura non hanno esito positivo nelle seguenti circostanze:

  • Quando una richiesta TransactGetItems è in conflitto con un'operazione TransactWriteItems in corso su uno o più item nella richiesta TransactGetItems. In questo caso, la richiesta ha esito negativo con una TransactionCanceledException.

  • Quando la capacità assegnata è insufficiente per il completamento della transazione.

  • Quando è presente un errore utente, come un formato di dati invalido.

Per ulteriori informazioni sulla gestione dei conflitti con le operazioni TransactGetItems, consulta Gestione dei conflitti nelle transazioni in DynamoDB.

Livelli di isolamento per le transazioni DynamoDB

I livelli di isolamento delle operazioni transazionali (TransactWriteItems o TransactGetItems) e di altre operazioni sono:

SERIALIZABLE

L'isolamento serializzabile garantisce che i risultati di diverse operazioni simultanee siano le stesse, come se nessuna operazione avesse inizio prima che l'ultima fosse finita.

L'isolamento serializzabile è presente tra i seguenti tipi di operazione:

  • Tra una qualsiasi operazione transazionale e una qualsiasi operazione di scrittura standard (PutItem, UpdateItem o DeleteItem).

  • Tra una qualsiasi operazione transazionale e una qualsiasi operazione di lettura standard (GetItem).

  • Tra un'operazione TransactWriteItems e un'operazione TransactGetItems.

Sebbene esista un isolamento serializzabile tra le operazioni transazionali e ogni singola scrittura standard in un'BatchWriteItemoperazione, non esiste un isolamento serializzabile tra la transazione e l'operazione come unità. BatchWriteItem

Allo stesso modo, il livello di isolamento tra un'operazione transazionale e un GetItems individuale in un'operazione BatchGetItem è serializzabile. Tuttavia, il livello di isolamento tra la transazione e l'operazione BatchGetItemcome unità è read-committed.

Una singola richiesta GetItem è serializzabile rispetto a una richiesta TransactWriteItems in uno dei due modi seguenti, prima o dopo la richiesta TransactWriteItems. Più richieste GetItem, rispetto alle chiavi in una richiesta TransactWriteItemssimultanea, possono essere eseguite in qualsiasi ordine, e quindi i risultati sono letti–commessi.

Ad esempio, se le richieste GetItem per l'elemento A e l'elemento B vengono eseguite contemporaneamente a una richiesta TransactWriteItems che modifica sia l'elemento A che l'elemento B, esistono quattro possibilità:

  • Entrambe le richieste GetItem vengono eseguite prima della richiesta TransactWriteItems.

  • Entrambe le richieste GetItem vengono eseguite dopo la richiesta TransactWriteItems.

  • La richiesta GetItem per l'elemento A viene eseguita prima della richiesta TransactWriteItems. Per l'elemento B, GetItem viene eseguito dopo TransactWriteItems.

  • La richiesta GetItem per l'elemento B viene eseguita prima della richiesta TransactWriteItems. Per l'elemento A, GetItem viene eseguito dopo TransactWriteItems.

È necessario utilizzare TransactGetItems se si preferisce un livello di isolamento serializzabile per più richieste. GetItem

Se viene effettuata una lettura non transazionale su più articoli che facevano parte della stessa richiesta di scrittura della transazione in corso, è possibile che tu sia in grado di leggere il nuovo stato di alcuni articoli e il vecchio stato degli altri elementi. Potrai leggere il nuovo stato di tutti gli elementi che facevano parte della richiesta di scrittura della transazione solo quando riceverai una risposta corretta per la scrittura transazionale.

READ-COMMITTED

L'isolamento Read-committed garantisce che le operazioni di lettura restituiscano sempre valori sottoposti a commit per un elemento: la lettura non presenterà mai una vista dell'elemento che rappresenta uno stato di una scrittura transazionale terminata con un errore. L'isolamento read-committed non impedisce le modifiche dell'item immediatamente dopo l'operazione di lettura.

Il livello di isolamento è read-committed tra una qualsiasi operazione transazionale e una qualsiasi operazione di lettura che coinvolga diverse letture standard (BatchGetItem, Query o Scan). Se una scrittura transazionale aggiorna un elemento durante un'operazione BatchGetItem, Query o Scan, la fase successiva dell'operazione di lettura restituisce il nuovo valore sottoposto a commit, con ConsistentRead) o eventualmente un valore sottoposto a commit precedente (letture a consistenza finale).

Riepilogo dell'operazione

Per riassumere, la seguente tabella mostra i livelli di isolamento tra un'operazione transazionale (TransactWriteItems o TransactGetItems) e altre operazioni.

Operazione Livello di isolamento

DeleteItem

Serializzabile

PutItem

Serializzabile

UpdateItem

Serializzabile

GetItem

Serializzabile

BatchGetItem

Read-committed*

BatchWriteItem

NOTSerializzabile*

Query

Read-committed

Scan

Read-committed

Altra operazione transazionale

Serializzabile

I livelli contrassegnati da un asterisco (*) si applicano all'operazione come un'unità. Tuttavia, le singole operazioni all'interno di tali operazioni hanno un livello di isolamento serializzabile.

Gestione dei conflitti nelle transazioni in DynamoDB

Un conflitto transazionale si può verificare durante richieste simultanee a livello di voci su una singola voce all'interno di una transazione. I conflitti tra transazioni possono verificarsi nei seguenti scenari:

  • Una richiesta PutItem,UpdateItem e DeleteItem per una voce è in conflitto con una richiesta TransactWriteItems continua che include la stessa voce.

  • Una voce all'interno di una richiesta TransactWriteItems è parte di un'altra richiesta TransactWriteItems continua.

  • Una voce all'interno di una richiesta TransactGetItems è parte di una richiesta continua TransactWriteItems, BatchWriteItem, PutItem, UpdateItem o DeleteItem.

Nota

  • Quando una richiesta PutItem, UpdateItem o DeleteItem viene rifiutata, la richiesta dà esito negativo con un TransactionConflictException.

  • Se una richiesta a livello di voce all'interno di TransactWriteItems o TransactGetItems viene rifiutata, la richiesta dà esito negativo con TransactionCanceledException. Se la richiesta fallisce, AWS SDKs non riprovare.

    Se si utilizza il AWS SDK for Java, l'eccezione contiene l'elenco di CancellationReasons, ordinato in base all'elenco di elementi nel parametro di TransactItems richiesta. Per altre lingue, una rappresentazione della stringa dell'elenco è inclusa nel messaggio di errore dell'eccezione.

  • Quando un'operazione TransactWriteItems o TransactGetItems in corso è in conflitto con una richiesta GetItem simultanea, entrambe le operazione possono avere esito positivo.

La TransactionConflict CloudWatch metrica viene incrementata per ogni richiesta a livello di elemento non riuscita.

Utilizzo delle transazioni in APIs DynamoDB Accelerator () DAX

TransactWriteItemse TransactGetItems sono entrambi supportati in DynamoDB Accelerator DAX () con gli stessi livelli di isolamento di DynamoDB.

TransactWriteItemsscrive. DAX DAXpassa una TransactWriteItems chiamata a DynamoDB e restituisce la risposta. Per popolare la cache dopo la scrittura, DAX chiamate TransactGetItems in background per ogni elemento dell'TransactWriteItemsoperazione, il che consuma unità di capacità di lettura aggiuntive. Per ulteriori informazioni, consulta Gestione della capacità per le transazioni. Questa funzionalità consente di mantenere la logica dell'applicazione semplice e di utilizzarla sia DAX per le operazioni transazionali che per quelle non transazionali.

TransactGetItemsle chiamate vengono passate DAX senza che gli elementi vengano memorizzati nella cache locale. Si tratta dello stesso comportamento di un read-in fortemente coerente. APIs DAX

Gestione della capacità per le transazioni

Non è previsto alcun costo aggiuntivo per abilitare le transazioni per le tabelle DynamoDB. Si paga solo per le letture o le scritture che fanno parte della transazione. DynamoDB esegue due letture o scritture sottostanti per ciascun elemento nella transazione: uno per preparare la transazione uno per eseguire il commit della transazione. Le due operazioni di lettura/scrittura sottostanti sono visibili nelle metriche di Amazon CloudWatch .

Pianifica le letture e le scritture aggiuntive richieste da Transactional APIs quando fornisci capacità alle tue tabelle. Ad esempio, si supponga che l'applicazione esegua una transazione al secondo e che ciascuna transazione scriva nella tabella tre elementi da 500 byte. Ogni articolo richiede due unità di capacità di scrittura (WCUs): una per preparare la transazione e l'altra per confermare la transazione. Pertanto, è necessario assegnarne sei WCUs alla tabella.

Se stavi usando DynamoDB Accelerator DAX () nell'esempio precedente, dovresti utilizzare anche due unità di capacità di lettura RCUs () per ogni elemento della chiamata. TransactWriteItems Quindi è necessario aggiungere altre sei unità RCUs alla tabella.

Analogamente, se l'applicazione esegue una transazione di lettura al secondo e ogni transazione legge tre elementi da 500 byte della tabella, è necessario fornire sei unità di capacità di lettura (RCUs) alla tabella. La lettura di ogni elemento richiede due elementiRCUs: uno per preparare la transazione e uno per confermare la transazione.

Inoltre, SDK il comportamento predefinito consiste nel ritentare le transazioni in caso di TransactionInProgressException eccezione. Pianifica le unità di capacità di lettura aggiuntive (RCUs) utilizzate da questi nuovi tentativi. Lo stesso vale qualora si ritentino le transazioni nel proprio codice utilizzandone uno ClientRequestToken.

Best practice per le transazioni

Durante l'utilizzo delle transazioni DynamoDB, considerare le seguenti best practice suggerite.

  • Abilita il dimensionamento automatico o assicurati di aver effettuato il provisioning di una capacità di throughput sufficiente da eseguire le due operazioni di lettura o scrittura per ogni item della transazione.

  • Se non utilizzi un valore AWS fornitoSDK, includi un ClientRequestToken attributo quando effettui una TransactWriteItems chiamata per assicurarti che la richiesta sia idempotente.

  • Non raggruppare le operazioni in una transazione qualora non sia necessario. Ad esempio, se una singola transazione con 10 operazioni può essere suddivisa in diverse transazioni senza compromettere la correttezza dell'applicazione, si raccomanda di frazionare la transazione. Le transazioni più semplici migliorano il throughput e hanno maggiori probabilità di successo.

  • Diverse transazioni che aggiornano gli stessi item simultaneamente possono causare conflitti che annullano le transazioni. Per minimizzare tali conflitti, si consiglia di utilizzare le seguenti best practice DynamoDB per la modellazione dei dati.

  • Se un set di attributi viene spesso aggiornato tra più item come parte di una transazione singola, considera di raggruppare gli attributi in un singolo item per ridurre l'ambito della transazione.

  • Evita l'uso di transazioni per l'inserimento di dati in blocco. Per le scritture in blocco, è consigliabile utilizzare BatchWriteItem.

Utilizzo di tabelle transazionali con tabelle globali APIs

Le operazioni contenute in una transazione DynamoDB sono garantite solo nella regione in cui la transazione è stata originariamente eseguita. La transazionalità non viene preservata quando le modifiche applicate all'interno di una transazione vengono replicate tra regioni in repliche di tabelle globali.

DynamoDB Transactions e la libreria client delle transazioni AWSLabs

Le transazioni DynamoDB forniscono un sostituto più economico, robusto e performante della libreria client delle transazioni. AWSLabs Ti suggeriamo di aggiornare le tue applicazioni per utilizzare la transazione nativa lato server. APIs