Ciao a tutti. Sono Vladislav Rodin. Attualmente sono il responsabile del corso "Architetto di carichi elevati" in OTUS e insegno anche corsi dedicati all'architettura del software.
Oltre all'insegnamento, come avrete notato, scrivo materiale originale per il blog di OTUS su Habr e l'articolo di oggi è dedicato al lancio del corso , che attualmente è aperto alle iscrizioni.
Introduzione
In Abbiamo discusso del fatto che le transazioni nei database servono a risolvere due compiti: garantire la resistenza ai guasti e l'accesso ai dati in un ambiente concorrente. Per svolgere correttamente questi compiti, una transazione deve avere le proprietà ACID. Oggi parleremo in dettaglio della lettera I (isolamento) in questa abbreviazione.
Isolamento
L'isolamento affronta il problema dell'accesso ai dati in un ambiente concorrente, garantendo effettivamente protezione contro le condizioni di race. Idealmente, l'isolamento implica la serializzazione, ovvero una proprietà che garantisce che il risultato dell'esecuzione delle transazioni in parallelo sia lo stesso di quello che si avrebbe se fossero eseguite in sequenza. Il problema principale di questa proprietà è che è molto difficile da garantire tecnicamente e, di conseguenza, influisce notevolmente sulle prestazioni del sistema. Per questo motivo, l'isolamento è spesso allentato, accettando i rischi di alcune anomalie, di cui si parlerà più avanti. La possibilità di certe anomalie caratterizza il livello di isolamento delle transazioni.
Le anomalie più conosciute sono: dirty read, non-repeatable read, phantom read, ma in realtà ce ne sono altre 5: dirty write, cursor lost update, lost update, read skew, write skew.
Dirty write
L'essenza dell'anomalia è che le transazioni possono sovrascrivere dati non ancora confermati.
Questa anomalia è pericolosa non solo perché i dati possono confliggere dopo il commit di entrambe le transazioni (come nell'immagine), ma anche perché compromette l'atomicità: poiché consentiremo la sovrascrittura dei dati non impegnati, non è chiaro come annullare una transazione senza toccare l'altra.
La soluzione dell'anomalia è abbastanza semplice: mettiamo un blocco sulla scrittura prima dell'inizio della registrazione, vietando ad altre transazioni di modificare la registrazione fino a quando il blocco non viene rimosso.
Dirty read
Dirty read significa la lettura di dati non impegnati.
I problemi sorgono quando, sulla base del campionamento, è necessario eseguire alcune operazioni o prendere decisioni.
Per correggere l'anomalia si può mettere un blocco sulla lettura, ma questo avrà un impatto significativo sulle prestazioni. È molto più semplice affermare che, per il rollback della transazione, lo stato originale dei dati (prima dell'inizio della scrittura) deve essere necessariamente conservato nel sistema. Perché non leggere da lì? È abbastanza economico, quindi la maggior parte dei database disabilita dirty read per impostazione predefinita.
Lost update
Lost update significa aggiornamenti persi, e la traduzione riflette abbastanza accuratamente la natura del problema:
In effetti, il risultato della transazione T2 è stato annullato. Una situazione del genere si corregge tramite blocchi espliciti o impliciti della registrazione. Ciò significa che possiamo semplicemente aggiornare la registrazione, il che provoca un blocco implicito, oppure possiamo eseguire select for update, causando la comparsa di un blocco sia in lettura che in scrittura. È importante notare che questa operazione è abbastanza rischiosa: con la nostra «innocente» lettura, blocchiamo altre letture. Alcuni database offrono un'opzione più sicura, select for share, che consente di leggere i dati, ma non di modificarli.
Cursor lost update
Per un controllo più fine, i database possono offrire altri strumenti, come i cursori. Un cursore è una struttura che contiene un insieme di righe e consente di iterare su di esse. declare cursor_name for select_statement. Il contenuto del cursore è descritto con un select.
A cosa serve il cursore? Il fatto è che alcuni database offrono un blocco su tutte le righe selezionate con il select (stabilità di lettura), oppure solo su quella riga su cui si trova attualmente il cursore (stabilità del cursore). Con la stabilità del cursore si realizza un short lock, il che permette di ridurre il numero di blocchi quando si itera su un grande campione di dati. Pertanto, l'anomalia lost update è evidenziata separatamente per il cursore.
Lettura non ripetibile
La lettura non ripetibile si verifica quando durante l'esecuzione della nostra transazione 2 letture consecutive della stessa riga portano a risultati diversi, perché un'altra transazione è intervenuta tra queste due letture, ha modificato i nostri dati ed è stata committata.
Perché è un problema? Immaginate che l'obiettivo della transazione T2 nell'immagine sia selezionare tutti i prodotti il cui prezzo è inferiore a 150 u.e. Qualcun altro ha aggiornato il prezzo a 200 u.e. Quindi, il filtro impostato non ha funzionato.
Queste anomalie smettono di verificarsi con l'aggiunta di blocchi a due fasi o utilizzando il meccanismo MVCC, di cui vorrei parlare separatamente.
Lettura fantasma
La lettura fantasma si riferisce alla lettura di dati che sono stati aggiunti da un'altra transazione.
Un esempio può essere l'osservazione di una selezione errata del prodotto più economico in presenza di questa anomalia.
Eliminare le letture fantasma è piuttosto difficile. Una semplice blocco non è sufficiente, poiché non possiamo bloccare ciò che non esiste ancora. I sistemi 2PL utilizzano il blocco predicativo, mentre i sistemi MVCC fanno sì che il pianificatore delle transazioni annulli le transazioni che potrebbero essere violate da un'inserzione. Entrambi i meccanismi sono piuttosto onerosi.
Read skew
Il read skew si verifica quando lavoriamo con più tabelle i cui contenuti devono cambiare in modo coerente.
Supponiamo di avere tabelle che rappresentano post e le loro meta-informazioni:
Una transazione legge dalle tabelle, un'altra le modifica:
A seguito dell'esecuzione della transazione T1, il post ha title = Buono, mentre updated_by = T2, cosa che rappresenta una certa incongruenza.
In effetti, si tratta di una lettura non ripetibile, ma all'interno di più tabelle.
Per correggere, T1 può applicare dei blocchi su tutte le righe che leggerà, impedendo così alla transazione T2 di modificare le informazioni. Nel caso di MVCC, la transazione T2 verrà annullata. La protezione da questa anomalia può essere importante se utilizziamo dei cursori.
Scrittura scorretta
Anche questa anomalia è più facile da spiegare con un esempio: supponiamo che nel nostro sistema almeno un dottore debba essere di guardia, ma entrambi i dottori decidono di annullare il loro turno:
L'anomalia ha portato al fatto che nessuno dei dottori andrà di guardia. Come è potuto accadere? Perché la transazione ha verificato una condizione che può essere violata da un'altra transazione, e a causa dell'isolamento non abbiamo visto questa modifica.
È lo stesso non ripetibile lettura. Come alternativa, i selettori possono applicare blocchi su queste registrazioni.
Scrittura scorretta e lettura scorretta sono combinazioni delle anomalie precedenti. Possiamo considerare la scrittura scorretta, che è essenzialmente una lettura fantasma. Consideriamo una tabella che contiene i nomi dei dipendenti, il loro stipendio e il progetto su cui stanno lavorando:
In definitiva, abbiamo il seguente scenario: ogni manager pensava che la propria modifica non avrebbe portato a superare il budget, quindi hanno apportato cambiamenti nel personale che, nel complesso, hanno portato a un disavanzo.
La causa del problema è esattamente la stessa del lettura fantasma.
Conclusioni
L'abbassamento del livello di isolamento delle transazioni nel database è un compromesso tra sicurezza e prestazioni, e la scelta di tale livello deve essere effettuata considerando i potenziali rischi per l'azienda in caso di anomalie.
Fonte: habr.com
