Ciao a tutti. Sono Vladislav Rodin. Attualmente sono il responsabile del corso "Architettura ad alta capacità di carico" in OTUS e insegno corsi sull'architettura del software.
Oltre all'insegnamento, come avrete notato, mi dedico anche alla scrittura di contenuti originali per il blog di OTUS su Habr, e l'articolo di oggi vuole essere dedicato al lancio del corso , al quale attualmente è aperta l'iscrizione.
Introduzione
In abbiamo discusso del fatto che le transazioni nei database servono a risolvere due compiti: garantire la tolleranza ai guasti e l'accesso ai dati in un ambiente concorrente. Per svolgere adeguatamente questi compiti, una transazione deve possedere le proprietà ACID. Oggi parleremo in dettaglio della lettera I (isolamento) di questo acronimo.
Isolamento
L'isolamento risolve il problema dell'accesso ai dati in un ambiente concorrente, fornendo effettivamente protezione contro le condizioni di gara. In un'ideale condizione, l'isolamento significa serializzazione, cioè la proprietà che garantisce che il risultato dell'esecuzione di transazioni in parallelo sia lo stesso di quello che si otterrebbe se venissero eseguite in modo sequenziale. Il problema principale di questa proprietà è che è molto difficile da garantire tecnicamente, e di conseguenza colpisce fortemente le prestazioni del sistema. È per questo che l'isolamento viene spesso indebolito, accettando i rischi di emergere di alcune anomalie, di cui parleremo più avanti. La possibilità di insorgenza di tali anomalie caratterizza proprio il livello di isolamento delle transazioni.
Le anomalie più note 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
La sostanza dell'anomalia sta nel fatto che le transazioni possono sovrascrivere dati non confermati.
Questa anomalia è pericolosa non solo perché i dati possono entrare in conflitto dopo il commit di entrambe le transazioni (come mostrato nell'immagine), ma anche perché viene compromessa l'atomicità: poiché consentiamo di sovrascrivere dati non confermati, non è chiaro come ripristinare una transazione senza toccare l'altra.
L'anomalia si risolve abbastanza facilmente: si imposta un blocco in scrittura prima dell'inizio della registrazione, impedendo ad altre transazioni di modificare la registrazione fino a quando il blocco non viene rimosso.
Dirty read
La lettura sporca significa leggere dati non confermati.
I problemi sorgono quando è necessario intraprendere azioni o prendere decisioni basate su un campione.
Per correggere l'anomalia, è possibile impostare un blocco sulla lettura, ma questo influisce notevolmente sulle prestazioni. È molto più semplice dire che per il rollback di una transazione, lo stato originale dei dati (prima dell'inizio della scrittura) deve essere necessariamente conservato nel sistema. Perché non leggere da lì? È piuttosto economico, quindi la maggior parte dei database disabilita la lettura sporca di default.
Aggiornamento perso
L'aggiornamento perso significa aggiornamenti persi, e la traduzione riflette abbastanza accuratamente la natura del problema:
Infatti, il risultato della transazione T2 è stato annullato. Questa situazione si risolve tramite blocchi espliciti o impliciti sulle righe. Cioè, o aggiorniamo semplicemente la riga, e allora si verifica un blocco implicito, oppure eseguiamo select for update, causando la generazione di un blocco sulla lettura e sulla scrittura. Fate attenzione che questa operazione è piuttosto pericolosa: con la nostra lettura "innocente", blocchiamo altre letture. Alcuni database offrono una soluzione più sicura select for share, che permette di leggere i dati, ma non consente di modificarli.
Aggiornamento del cursore perso
Per un controllo più fine, i database possono offrire altri strumenti, come il cursore. Un cursore è una struttura che contiene un insieme di righe e consente di iterarvi. declare cursor_name for select_statement. Il contenuto del cursore è descritto dalla select.
A cosa serve un cursore? Il fatto è che alcuni database offrono un blocco su tutte le righe selezionate dalla select (stabilità di lettura), oppure solo sulla riga su cui si trova attualmente il cursore (stabilità del cursore). Con la stabilità del cursore si esegue un blocco temporaneo, che riduce il numero di blocchi nel caso in cui stiamo iterando su un grande campione di dati. Pertanto, l'anomalia dell'aggiornamento perso è evidenziata separatamente per il cursore.
Lettura non ripetibile
La lettura non ripetibile consiste nel fatto che durante l'esecuzione della nostra transazione, 2 letture consecutive della stessa riga porteranno a risultati diversi, poiché un'altra transazione è intervenuta tra queste due letture, ha modificato i nostri dati ed è stata confermata.
Perché è un problema? Immaginate che l'obiettivo della transazione T2 nell'immagine sia di selezionare tutti i prodotti il cui prezzo è inferiore a 150 u.e. Qualcun altro ha aggiornato il prezzo a 200 u.e. Così, 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 è la lettura di dati che sono stati aggiunti da un'altra transazione.
Come esempio, si può osservare un'errata selezione del prodotto più economico quando si verifica questa anomalia.
Liberarsi dalle letture fantasma è già abbastanza difficile. Un normale blocco non è sufficiente, perché non possiamo bloccare ciò che non esiste ancora. I sistemi 2PL utilizzano bloccaggi predicativi, mentre i sistemi MVCC fanno annullare le transazioni dal pianificatore delle transazioni che potrebbero essere violate dall'inserimento. Entrambi i meccanismi sono piuttosto pesanti.
Sfasamento di lettura
Lo sfasamento di lettura si verifica quando lavoriamo con più tabelle, il cui contenuto deve cambiare in modo coordinato.
Supponiamo di avere tabelle che rappresentano post e le loro metainformazioni:
Una transazione legge dalle tabelle, un'altra le modifica:
A seguito dell'esecuzione della transazione T1, il post con title = Good e updated_by = T2, che rappresenta una certa incongruenza.
In effetti, si tratta di una lettura non ripetibile, ma su più tabelle.
Per correggere ciò, T1 può mettere dei blocchi su tutte le righe che leggerà, impedendo alla transazione T2 di modificare le informazioni. Nel caso di MVCC, la transazione T2 verrà annullata. La protezione da questa anomalia può diventare importante se utilizziamo dei cursori.
Sfasamento di scrittura
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 si presenterà a lavoro. Come è potuto succedere? Perché la transazione controllava una condizione che può essere violata da un'altra transazione e a causa dell'isolamento non abbiamo visto questa modifica.
È la stessa lettura non ripetibile. Come alternativa, le selezioni possono mettere blocchi su queste registrazioni.
Scrittura skew e read skew sono combinazioni delle anomalie precedenti. Possiamo considerare il write skew, che è essenzialmente un phantom read. Consideriamo una tabella che contiene i nomi dei dipendenti, il loro stipendio e il progetto su cui stanno lavorando:
Alla fine, abbiamo il seguente quadro: ogni manager pensava che la propria modifica non avrebbe comportato sforamenti di budget, quindi hanno apportato modifiche al personale che, nella somma, hanno portato a un eccesso di spesa.
La causa del problema è esattamente la stessa del phantom reading.
Conclusioni
L'indebolimento del livello di isolamento delle transazioni nel database è un compromesso tra sicurezza e prestazioni; la scelta di questo livello dovrebbe essere basata sui potenziali rischi per l'azienda in caso di insorgere di specifiche anomalie.
Fonte: habr.com
