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à.
Le migliori pratiche per la gestione degli aggiornamenti simultanei in DynamoDB
Nei sistemi distribuiti, più processi o utenti possono tentare di modificare gli stessi dati contemporaneamente. Senza il controllo della concorrenza, queste scritture simultanee possono causare la perdita di aggiornamenti, l'incoerenza dei dati o l'insorgenza di condizioni critiche. DynamoDB offre diversi meccanismi per aiutarti a gestire l'accesso simultaneo e mantenere l'integrità dei dati.
Nota
Le singole operazioni di scrittura, ad esempio, UpdateItem sono atomiche e funzionano sempre sulla versione più recente dell'elemento, indipendentemente dalla concorrenza. Le strategie di blocco sono necessarie quando l'applicazione deve leggere un elemento e poi riscriverlo in base al valore di lettura (un ciclo di lettura-modifica-scrittura), perché un altro processo potrebbe modificare l'elemento tra la lettura e la scrittura.
Esistono due strategie principali per la gestione degli aggiornamenti simultanei:
-
Blocco ottimistico: presuppone che i conflitti siano rari. Consente l'accesso simultaneo e rileva i conflitti in fase di scrittura utilizzando scritture condizionali. Se viene rilevato un conflitto, la scrittura ha esito negativo e l'applicazione può riprovare.
-
Blocco pessimistico: presume che i conflitti siano probabili. Impedisce l'accesso simultaneo acquisendo l'accesso esclusivo a una risorsa prima di modificarla. Gli altri processi devono attendere il rilascio del blocco.
La tabella seguente riassume gli approcci disponibili in DynamoDB:
| Approccio | Meccanismo | Ideale per |
|---|---|---|
| Blocco ottimistico | Attributo di versione + scritture condizionali | Bassa contesa, tentativi poco costosi |
| Blocco pessimistico (transazioni) | TransactWriteItems |
Multi-item atomicità, moderata contesa |
| Blocco pessimistico (lock client) | Tabella di chiusura dedicata con contratto di locazione e battito cardiaco | Long-running flussi di lavoro, coordinamento distribuito |
Scelta di una strategia di controllo della concorrenza
Utilizza le seguenti linee guida per scegliere l'approccio giusto per il tuo carico di lavoro:
- Usa il blocco ottimistico quando:
-
I conflitti sono rari.
Riprovare una scrittura non riuscita è poco costoso.
Stai aggiornando un singolo elemento alla volta.
- Usa le transazioni quando:
-
È necessario aggiornare più elementi in modo atomico.
È necessaria la semantica tutto o niente tra elementi o tabelle.
È necessario combinare i controlli delle condizioni con le scritture in un'unica operazione.
- Usa il lock client quando:
-
È necessario coordinare l'accesso alle risorse esterne attraverso i processi distribuiti.
La sezione critica è di lunga durata e riprovare in caso di conflitto è costoso.
È necessaria la scadenza automatica del blocco per gestire gli errori del processo.
Nota
Se utilizzi tabelle globali DynamoDB, tieni presente che le tabelle globali utilizzano una strategia di riconciliazione «chi scrive vince chi scrive» per gli aggiornamenti simultanei. Il blocco ottimistico con numeri di versione non funziona come previsto in tutte le regioni perché una scrittura in una regione può sovrascrivere una scrittura simultanea in un'altra regione senza un controllo della versione. Progettate l'applicazione in modo da gestire i conflitti a livello di applicazione quando utilizzate tabelle globali.
