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à.
Controllo della concorrenza in Aurora DSQL
La concorrenza consente a più sessioni di accedere e modificare i dati contemporaneamente senza compromettere l’integrità e la coerenza dei dati. Aurora DSQL offre la compatibilità con PostgreSQL implementando al contempo un meccanismo di controllo della concorrenza moderno e senza blocchi. Mantiene la piena conformità ACID attraverso l’isolamento degli snapshot, garantendo la coerenza e l’affidabilità dei dati.
Un vantaggio chiave di Aurora DSQL è la sua architettura priva di blocchi, che elimina i comuni colli di bottiglia nelle prestazioni del database. Aurora DSQL impedisce che le transazioni lente blocchino altre operazioni ed elimina il rischio di deadlock. Questo approccio rende Aurora DSQL particolarmente utile per applicazioni ad alto throughput, in cui le prestazioni e la scalabilità sono fondamentali.
Risposte di controllo della concorrenza
Aurora DSQL utilizza il controllo ottimistico della concorrenza (OCC), che funziona in modo diverso dai tradizionali sistemi basati su blocchi. Invece di utilizzare i blocchi, OCC valuta i conflitti al momento del commit. Quando Aurora DSQL rileva un conflitto, restituisce un errore di serializzazione PostgreSQL con codice SQLSTATE. 40001 Il messaggio di risposta include un codice OCC che identifica il tipo di conflitto:
- OC000 — Conflitto di dati
-
Due transazioni hanno tentato di modificare la stessa riga. La transazione con il tempo di commit più breve ha esito positivo e la transazione in conflitto riceve la risposta: OC000
ERROR: change conflicts with another transaction (OC000) (SQLSTATE 40001) - OC001 — Conflitto di schema
-
Il catalogo degli schemi della sessione memorizzato nella cache non è aggiornato. Quando Aurora DSQL rileva che la versione del catalogo è cambiata da quando la sessione ha caricato la cache e la transazione non può basarsi in modo sicuro sulla versione corrente, la transazione riceve la risposta: OC001
ERROR: schema has been updated by another transaction (OC001) (SQLSTATE 40001)Qualsiasi operazione che modifica il catalogo degli schemi può causare una OC001 risposta, incluse le istruzioni DDL come
CREATE TABLEand e le istruzioni andALTER TABLE.GRANTREVOKEPer ulteriori informazioni, consulta DDL e transazioni distribuite in Aurora DSQL.
Progetta le tue applicazioni per implementare la logica di ripetizione per gestire queste risposte. Il modello di progettazione ideale è idempotente e consente di ripetere la transazione come primo rimedio, quando possibile. La logica consigliata è simile alla logica abort and retry in una situazione di timeout o deadlock di PostgreSQL standard. Tuttavia, OCC richiede che le applicazioni applichino questa logica più frequentemente.
Linee guida per l’ottimizzazione delle prestazioni delle transazioni
Per ottimizzare le prestazioni, è opportuno ridurre al minimo contese elevate su chiavi singole o intervalli di chiavi ridotti. Per raggiungere questo obiettivo, progetta lo schema in modo da distribuire gli aggiornamenti sull’intervallo di chiavi del cluster utilizzando le seguenti linee guida:
-
Scegli una chiave primaria casuale per le tabelle.
-
Evita i modelli che fanno aumentare la contesa sulle singole chiavi. Questo approccio garantisce prestazioni ottimali anche con l’aumento del volume delle transazioni.
