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. Questo processo di valutazione dei conflitti in fase di impegno è anche chiamato aggiudicazione. 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 primo tempo di commit 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 memorizzati nella cache della sessione non è aggiornato. Quando Aurora DSQL rileva che la versione del catalogo è cambiata da quando la sessione ha caricato la cache e che la transazione non può essere ripristinata in modo sicuro alla 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 risposta OC001, incluse le istruzioni DDL come and, nonché
CREATE TABLEle istruzioni and.ALTER TABLEGRANTREVOKEPer ulteriori informazioni, consulta DDL e transazioni distribuite in Aurora DSQL.
Progettate le applicazioni in modo da implementare la logica dei tentativi 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.
Tipi di conflitto di dati
Grazie al meccanismo di controllo della concorrenza Aurora DSQL, le SELECT ... FOR KEY SHARE clausole SELECT ... FOR
UPDATE and producono risultati attraverso il rilevamento ottimistico dei conflitti in fase di commit anziché tramite blocco. In Aurora DSQL, quando una transazione scrive una riga e un'altra la legge con una delle clausole precedenti, potrebbe emergere un conflitto al momento del commit a seconda delle colonne utilizzate dalle transazioni. Le seguenti clausole determinano il modo in cui Aurora DSQL rileva questi conflitti.
Definizione della colonna chiave
Le colonne chiave sono colonne che sono membri di un indice univoco, non parziale e non di espressione. Tutte le altre colonne non sono colonne chiave.
SELECT ... FOR UPDATE-
Dichiara che Aurora DSQL giudica le righe selezionate come se la transazione vi scrivesse. Se viene eseguita un'altra transazione
UPDATE,,DELETESELECT ... FOR UPDATE, oSELECT ... FOR KEY SHAREsulla stessa riga e viene eseguita per prima, la transazione eseguita ha esito negativo e viene generata una risposta.SELECT ... FOR UPDATEOC000Questa clausola è in conflitto con qualsiasi scrittura simultanea sulla riga e con letture simultaneeFOR UPDATE.FOR KEY SHARE SELECT ... FOR KEY SHARE-
Dichiara che la transazione dipende dalle colonne chiave delle righe selezionate. Se un'altra transazione elimina la riga, modifica le relative colonne chiave o viene eseguita
SELECT ... FOR UPDATEe viene eseguita per prima, la transazione eseguita haSELECT ... FOR KEY SHAREesito negativo e viene fornita una risposta.OC000Una combinazione diUPDATEcolonne non chiave non è in conflitto.
Aurora DSQL non supporta le clausole or. NO KEY UPDATE FOR SHARE Tuttavia, DML utilizza implicitamente il meccanismo. NO KEY UPDATE La matrice seguente riepiloga i casi in cui due transazioni simultanee che accedono alla stessa riga entrano in conflitto. An X indica che le due operazioni sono in conflitto: l'ultima transazione eseguita fallisce con una risposta. OC000 Una cella vuota indica che entrambe le transazioni possono essere eseguite.
| Operation | INSERT,DELETE, UPDATE (colonne chiave) o SELECT ... FOR UPDATE |
UPDATE(solo colonne non chiave) |
SELECT ... FOR KEY SHARE |
|---|---|---|---|
INSERT,DELETE, UPDATE (colonne chiave) o SELECT ... FOR UPDATE |
X | X | X |
UPDATE(solo colonne non chiave) |
X | X | |
SELECT ... FOR KEY SHARE |
X |
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.
