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à.
Best practice per l’implementazione del controllo delle versioni in DynamoDB
Nei sistemi distribuiti come DynamoDB, il controllo delle versioni degli elementi mediante il blocco ottimistico previene gli aggiornamenti in conflitto. Monitorando le versioni degli elementi e utilizzando scritture condizionali, le applicazioni possono gestire le modifiche simultanee, garantendo l’integrità dei dati in ambienti ad alta simultaneità.
Il blocco ottimistico è una strategia utilizzata per garantire che le modifiche ai dati vengano applicate correttamente senza conflitti. Invece di bloccare i dati quando vengono letti (come nel caso del blocco pessimistico), il blocco ottimistico verifica se i dati sono cambiati prima di riscriverli. In DynamoDB, ciò si ottiene tramite una forma di controllo delle versioni, in cui ogni elemento include un identificatore che aumenta con ogni aggiornamento. Quando si aggiorna un elemento, l’operazione avrà successo solo se l’identificatore corrisponde a quello previsto dall’applicazione.
Quando usare questo modello
Questo modello è utile nei seguenti scenari:
Più utenti o processi possono tentare di aggiornare lo stesso elemento contemporaneamente.
Garantire l’integrità e la coerenza dei dati è fondamentale.
È necessario evitare il sovraccarico e la complessità della gestione dei blocchi distribuiti.
Gli esempi includono:
Applicazioni di e-commerce in cui i livelli di inventario vengono aggiornati frequentemente.
Piattaforme collaborative in cui più utenti modificano gli stessi dati.
Sistemi finanziari in cui i record delle transazioni devono rimanere coerenti.
Compromessi
Sebbene il blocco ottimistico e i controlli condizionali forniscano una solida integrità dei dati, presentano i seguenti compromessi:
- Conflitti di simultaneità
In ambienti caratterizzati da un elevato tasso di simultaneità, aumenta la probabilità che si verifichino conflitti, con conseguenti potenziali ripetizioni dei tentativi e costi di scrittura.
- Complessità dell’implementazione
-
L’aggiunta del controllo delle versioni agli elementi e la gestione dei controlli condizionali possono aggiungere complessità alla logica dell’applicazione.
- Sovraccarico di archiviazione aggiuntivo
-
L’archiviazione dei numeri di versione per ogni elemento aumenta leggermente i requisiti di archiviazione.
Progettazione dei modelli
Per implementare questo modello, lo schema DynamoDB deve includere un attributo version per ogni elemento. Ecco un semplice schema di progettazione:
Chiave di partizione: un identificatore univoco per ogni elemento (es.
ItemId).Attributi:
ItemId: l’identificatore univoco per l’elemento.Version: un numero intero che rappresenta il numero di versione dell’elemento.QuantityLeft: l’inventario rimanente dell’elemento.
Quando un elemento viene creato per la prima volta, l’attributo Version è impostato su 1. A ogni aggiornamento, il numero di versione aumenta di 1.
Utilizzo del modello
Per implementare questo modello, segui questa procedura nel flusso dell’applicazione:
La versione corrente dell’elemento.
Recupera l’elemento corrente da DynamoDB e leggi il numero di versione.
def get_document(item_id): response = table.get_item(Key={'ItemID': item_id}) return response['Item'] document = get_document('Bananas') current_version = document['Version']Incrementa il numero di versione nella logica dell’applicazione. Questa sarà la versione prevista per l’aggiornamento.
new_version = current_version + 1Tentativo di aggiornare l’elemento utilizzando un’espressione condizionale per garantire che il numero di versione corrisponda.
def update_document(item_id, qty_bought, current_version): try: response = table.update_item( Key={'ItemID': item_id}, UpdateExpression="set #qty = :qty, Version = :v", ConditionExpression="Version = :expected_v", ExpressionAttributeNames={ '#qty': 'QuantityLeft' }, ExpressionAttributeValues={ ':qty': qty_bought, ':v': current_version + 1, ':expected_v': current_version }, ReturnValues="UPDATED_NEW" ) return response except ClientError as e: if e.response['Error']['Code'] == 'ConditionalCheckFailedException': print("Update failed due to version conflict.") else: print("Unexpected error: %s" % e) return None update_document('Bananas', 2, new_version)Se l'aggiornamento ha esito positivo, il prezzo QuantityLeft per l'articolo verrà ridotto di 2.
Gestisci i conflitti se si verificano.
Se si verifica un conflitto (ad esempio, un altro processo ha aggiornato l’elemento dall’ultima lettura), gestiscilo in modo appropriato, ad esempio effettuando una ripetizione del tentativo per l’operazione o avvisando l’utente.
Ciò richiederà una lettura aggiuntiva dell’elemento per ogni ripetizione di tentativo, pertanto limita il numero totale di ripetizioni di tentativi consentite prima di interrompere definitivamente il ciclo di richieste.
def update_document_with_retry(item_id, new_data, retries=3): for attempt in range(retries): document = get_document(item_id) current_version = document['Version'] result = update_document(item_id, qty_bought, current_version) if result is not None: print("Update succeeded.") return result else: print(f"Retrying update... ({attempt + 1}/{retries})") print("Update failed after maximum retries.") return None update_document_with_retry('Bananas', 2)L’implementazione del controllo delle versioni degli elementi utilizzando DynamoDB con blocco ottimistico e controlli condizionali è un modello efficace per garantire l’integrità dei dati nelle applicazioni distribuite. Sebbene introduca una certa complessità e potenziali compromessi in termini di prestazioni, è inestimabile in scenari che richiedono un solido controllo della simultaneità. Progettando attentamente lo schema e implementando i controlli necessari nella logica dell’applicazione, è possibile gestire efficacemente gli aggiornamenti simultanei e mantenere la coerenza dei dati.
Ulteriori linee guida e strategie su come implementare il controllo delle versioni dei dati DynamoDB sono disponibili sul blog sui database AWS
.