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 seguenti sezioni descrivono le operazioni delle API, la gestione della capacità, le best practice e altri dettagli sulle operazioni transazionali in DynamoDB.
**Topics**
+ [TransactWriteItems API](#transaction-apis-txwriteitems)
+ [TransactGetItems API](#transaction-apis-txgetitems)
+ [Livelli di isolamento per le transazioni DynamoDB](#transaction-isolation)
+ [Gestione dei conflitti nelle transazioni in DynamoDB](#transaction-conflict-handling)
+ [Utilizzo delle transazioni in APIs DynamoDB Accelerator (DAX)](#transaction-apis-dax)
+ [Gestione della capacità per le transazioni](#transaction-capacity-handling)
+ [Best practice per le transazioni](#transaction-best-practices)
+ [Utilizzo di tabelle transazionali con tabelle globali APIs](#transaction-integration)
+ [DynamoDB Transactions e la libreria client delle transazioni AWSLabs](#transaction-vs-library)
## 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.
Quando una transazione viene completata in DynamoDB, le sue modifiche iniziano a propagarsi agli indici secondari globali (), ai flussi e ai backupGSIs. Questa propagazione avviene gradualmente: i record dei flussi della stessa transazione potrebbero apparire in momenti diversi e potrebbero risultare interleaved con i record di altre transazioni. I consumer dei flussi non dovrebbero presumere l’atomicità delle transazioni o garanzie d’ordine.
Per garantire un'istantanea atomica degli elementi modificati in una transazione, utilizza l'operazione per leggere tutti gli elementi pertinenti insieme. TransactGetItems Questa operazione fornisce una visione coerente dei dati, garantendo la visualizzazione di tutte le modifiche rispetto a una transazione completata o di nessuna.
Poiché la propagazione non è immediata, se una tabella viene ripristinata da backup ([RestoreTableFromBackup](https://docs.aws.amazon.com/amazondynamodb/latest/APIReference/API_RestoreTableFromBackup.html)) o esportata in un punto temporale ([ExportTableToPointInTime](https://docs.aws.amazon.com/amazondynamodb/latest/APIReference/API_ExportTableToPointInTime.html)) durante la propagazione, può contenere solo alcune delle modifiche apportate durante una transazione recente.
### 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 item diventa eccessiva (superiore a 400 KB), un indice secondario locale (LSI) diventa eccessivo 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](#transaction-conflict-handling).
## 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](#transaction-conflict-handling).
## Livelli di isolamento per le transazioni DynamoDB
I livelli di isolamento delle operazioni transazionali (`TransactWriteItems` o `TransactGetItems`) e di altre operazioni sono:
### SERIALIZZABILI
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`.
Nonostante l’isolamento serializzabile sia presente tra le operazioni transazionali e ogni singola scrittura standard in un’operazione `BatchWriteItem`, l’isolamento serializzabile non è presente tra la transazione e l’operazione `BatchWriteItem` come un’unità.
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 `BatchGetItem`come 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 `TransactWriteItems`simultanea, 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`.
Sarebbe opportuno utilizzare `TransactGetItems` se si preferisce un livello di isolamento serializzabile per più richieste `GetItem`.
Se viene effettuata una lettura non transazionale su più elementi che facevano parte della stessa richiesta di scrittura della transazione in corso, è possibile che si sia in grado di leggere il nuovo stato di alcuni elementi e il vecchio stato degli altri elementi. Sarà possibile leggere il nuovo stato di tutti gli elementi che facevano parte della richiesta di scrittura della transazione solo quando si riceverà una risposta positiva per la scrittura transazionale, a indicare che la transazione è stata completata.
Una volta completata con successo la transazione e ricevuta una risposta, le successive operazioni di lettura *a coerenza finale* possono comunque restituire il vecchio stato per un breve periodo a causa di un modello di consistenza finale di DynamoDB. Per garantire la lettura della maggior parte up-to-date dei dati subito dopo una transazione, è necessario utilizzare letture [*fortemente coerenti*](HowItWorks.ReadConsistency.md#HowItWorks.ReadConsistency.Strongly) `ConsistentRead` impostando su true.
### 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.
| Operation | Livello di isolamento |
| --- | --- |
| `DeleteItem` | *Serializzabile* |
| `PutItem` | *Serializzabile* |
| `UpdateItem` | *Serializzabile* |
| `GetItem` | *Serializzabile* |
| `BatchGetItem` | *Read-committed*\$1 |
| `BatchWriteItem` | *NON serializzabile*\$1 |
| `Query` | *Read-committed* |
| `Scan` | *Read-committed* |
| Altra operazione transazionale | *Serializzabile* |
I livelli contrassegnati da un asterisco (\$1) 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 riprovarla.
Se si utilizza il AWS SDK per Java, l'eccezione contiene l'elenco di [CancellationReasons](https://docs.aws.amazon.com/amazondynamodb/latest/APIReference/API_CancellationReason.html), 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](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/metrics-dimensions.html) viene incrementata per ogni richiesta a livello di elemento non riuscita.
## Utilizzo delle transazioni in APIs DynamoDB Accelerator (DAX)
`TransactWriteItems` e `TransactGetItems` sono entrambi supportati in DynamoDB Accelerator (DAX) con gli stessi livelli di isolamento di DynamoDB.
`TransactWriteItems` scrive tramite DAX. DAX passa una chiamata `TransactWriteItems` a DynamoDB e restituisce la risposta. Per popolare la cache dopo la scrittura, DAX chiama `TransactGetItems` in background per ogni elemento nell'operazione `TransactWriteItems`che consuma unità di capacità di lettura aggiuntive. Per ulteriori informazioni, consulta [Gestione della capacità per le transazioni](#transaction-capacity-handling). Questa funzionalità consente di mantenere la logica dell'applicazione semplice e di utilizzare DAX per operazioni sia transazionali che non transazionali.
Le chiamate `TransactGetItems` vengono passate tramite DAX senza che gli elementi vengano memorizzati nella cache in locale. Si tratta dello stesso comportamento utilizzato per una lettura fortemente coerente in DAX. APIs
## 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 read/write operazioni sottostanti sono visibili nelle CloudWatch metriche di Amazon.
Pianifica le letture e le scritture aggiuntive richieste da Transactional APIs per fornire capacità alle 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 nell'esempio precedente si utilizzava DynamoDB Accelerator (DAX), si utilizzerebbero anche due unità di capacità di lettura RCUs () per ogni elemento della chiamata. `TransactWriteItems` Quindi è necessario aggiungere altre RCUs sei unità 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 elementi RCUs: uno per preparare la transazione e uno per confermare la transazione.
Inoltre, il comportamento dell'SDK predefinito prevede di ritentare le transazioni in caso di un'eccezione `TransactionInProgressException`. 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 SDK AWS fornito, 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 transazionali forniscono garanzie di atomicità, coerenza, isolamento e durabilità (ACID) solo all'interno della AWS regione in cui è stata richiamata l'API di scrittura. Le transazioni non sono supportate tra le Regioni nelle tabelle globali. Ad esempio, supponi di avere una tabella globale con repliche nelle Regioni Stati Uniti orientali (Ohio) e Stati Uniti occidentali (Oregon) e di eseguire un'operazione `TransactWriteItems` nella Regione Stati Uniti orientali (Virginia settentrionale). In questo caso, è possibile osservare transazioni parzialmente completate nella Regione degli Stati Uniti occidentali (Oregon) mentre le modifiche vengono replicate. Le modifiche vengono replicate in altre Regioni solo dopo essere state confermate nella Regione di origine.
## 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](https://github.com/awslabs) Ti suggeriamo di aggiornare le tue applicazioni per utilizzare la transazione nativa lato server. APIs