{"id":83337,"date":"2020-05-30T07:42:48","date_gmt":"2020-05-30T05:42:48","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/k-chemu-mozhet-privesti-oslablenie-urovnya-izolyaczii-tranzakczij-v-bazah-dannyh"},"modified":"2020-05-30T07:42:48","modified_gmt":"2020-05-30T05:42:48","slug":"k-chemu-mozhet-privesti-oslablenie-urovnya-izolyaczii-tranzakczij-v-bazah-dannyh","status":"publish","type":"post","link":"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/k-chemu-mozhet-privesti-oslablenie-urovnya-izolyaczii-tranzakczij-v-bazah-dannyh","title":{"rendered":"A cosa pu\u00f2 portare l'indebolimento del livello di isolamento delle transazioni nei database","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Ciao a tutti. Sono Vladislav Rodin. Attualmente sono il responsabile del corso \"Architettura ad alta capacit\u00e0 di carico\" in OTUS e insegno corsi sull'architettura del software.
\n<\/i>
\nOltre 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 \"PostgreSQL\"<\/a><\/noindex>, al quale attualmente \u00e8 aperta l'iscrizione.<\/i><\/b><\/p>\n

\"A
\n<\/p>\n

Introduzione<\/h2>\n

\nIn L'ultima volta<\/a><\/noindex> 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\u00e0 ACID. Oggi parleremo in dettaglio della lettera I (isolamento)<\/b> di questo acronimo.
\n<\/a><\/noindex><\/p>\n

Isolamento<\/h2>\n

\nL'isolamento affronta il problema dell'accesso ai dati in un ambiente concorrente, fornendo di fatto protezione contro le condizioni di competizione. Idealmente, l'isolamento implica la serializzazione, cio\u00e8 una propriet\u00e0 che garantisce che il risultato delle transazioni eseguite in parallelo sia lo stesso di quello che si otterrebbe se fossero eseguite in sequenza. Il principale problema di questa propriet\u00e0 \u00e8 che \u00e8 molto difficile da garantire tecnicamente e, di conseguenza, influisce notevolmente sulle prestazioni del sistema. Proprio per questo motivo, l'isolamento viene spesso allentato, accettando il rischio di alcune anomalie, di cui si parler\u00e0 di seguito. La possibilit\u00e0 di insorgenza di tali anomalie caratterizza il livello di isolamento delle transazioni.<\/p>\n

Le anomalie pi\u00f9 note sono: dirty read, non-repeatable read, phantom read, ma in realt\u00e0 ce ne sono altre 5: dirty write, cursor lost update, lost update, read skew, write skew.<\/p>\n

Dirty write<\/h2>\n

\nLa sostanza dell'anomalia sta nel fatto che le transazioni possono sovrascrivere dati non confermati.<\/p>\n

\"A
\n
\nQuesta anomalia \u00e8 pericolosa non solo perch\u00e9 i dati possono entrare in conflitto dopo il commit di entrambe le transazioni (come mostrato nell'immagine), ma anche perch\u00e9 viene compromessa l'atomicit\u00e0: poich\u00e9 consentiamo di sovrascrivere dati non confermati, non \u00e8 chiaro come ripristinare una transazione senza toccare l'altra. <\/p>\n

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. <\/p>\n

Dirty read<\/h2>\n

\nLa lettura sporca significa leggere dati non confermati. <\/p>\n

\"A
\n
\nI problemi sorgono quando \u00e8 necessario intraprendere azioni o prendere decisioni basate su un campione.<\/p>\n

Per correggere un'anomalia si pu\u00f2 applicare un blocco in lettura, ma questo avr\u00e0 un impatto significativo sulle prestazioni. \u00c8 molto pi\u00f9 semplice dire che, per il rollback di una transazione, lo stato originale dei dati (prima dell'inizio della scrittura) deve necessariamente essere conservato nel sistema. Perch\u00e9 non leggerlo da l\u00ec? \u00c8 piuttosto economico, quindi la maggior parte dei database disabilita la lettura sporca per impostazione predefinita. <\/p>\n

Aggiornamento perso<\/h2>\n

\nL'aggiornamento perso significa aggiornamenti persi, e la traduzione riflette abbastanza accuratamente la natura del problema:<\/p>\n

\"A
\n
\nInfatti, il risultato della transazione T2 \u00e8 stato annullato. Questa situazione si risolve tramite blocchi espliciti o impliciti sulle righe. Cio\u00e8, o aggiorniamo semplicemente la riga, e allora si verifica un blocco implicito, oppure eseguiamo select for update<\/b>, causando la generazione di un blocco sulla lettura e sulla scrittura. Fate attenzione che questa operazione \u00e8 piuttosto pericolosa: con la nostra lettura \"innocente\", blocchiamo altre letture. Alcuni database offrono una soluzione pi\u00f9 sicura select for share<\/b>, che permette di leggere i dati, ma non consente di modificarli. <\/p>\n

Aggiornamento del cursore perso<\/h2>\n

\nPer un controllo pi\u00f9 fine, i database possono offrire altri strumenti, come il cursore. Un cursore \u00e8 una struttura che contiene un insieme di righe e consente di iterarvi. declare cursor_name for select_statement<\/b>Il contenuto del cursore \u00e8 descritto dalla select. <\/p>\n

A cosa serve un cursore? Il fatto \u00e8 che alcuni database offrono un blocco su tutte le righe selezionate dalla select (stabilit\u00e0 in lettura), oppure solo sulla riga su cui si trova attualmente il cursore (stabilit\u00e0 del cursore). Con la stabilit\u00e0 del cursore viene effettuato un blocco breve, il che consente di ridurre il numero di blocchi nel caso in cui stiamo iterando su un ampio campione di dati. Perci\u00f2, l'anomalia dell'aggiornamento perso viene evidenziata separatamente per il cursore.<\/p>\n

Lettura non ripetibile<\/h2>\n

\nLa lettura non ripetibile consiste nel fatto che durante l'esecuzione della nostra transazione, 2 letture consecutive della stessa riga porteranno a risultati diversi, poich\u00e9 un'altra transazione \u00e8 intervenuta tra queste due letture, ha modificato i nostri dati ed \u00e8 stata confermata. <\/p>\n

\"A
\n
\nPerch\u00e9 \u00e8 un problema? Immaginate che l'obiettivo della transazione T2 nell'immagine sia di selezionare tutti i prodotti il cui prezzo \u00e8 inferiore a 150 u.e. Qualcun altro ha aggiornato il prezzo a 200 u.e. Cos\u00ec, il filtro impostato non ha funzionato.<\/p>\n

Queste anomalie smettono di verificarsi con l'aggiunta di blocchi a due fasi o utilizzando il meccanismo MVCC, di cui vorrei parlare separatamente. <\/p>\n

Lettura fantasma<\/h2>\n

\nLa lettura fantasma \u00e8 la lettura di dati che sono stati aggiunti da un'altra transazione. <\/p>\n

\"A
\n
\nCome esempio, si pu\u00f2 osservare un'errata selezione del prodotto pi\u00f9 economico quando si verifica questa anomalia. <\/p>\n

Liberarsi dalle letture fantasma \u00e8 gi\u00e0 abbastanza difficile. Un normale blocco non \u00e8 sufficiente, perch\u00e9 non possiamo bloccare ci\u00f2 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.<\/p>\n

Sfasamento di lettura<\/h2>\n

\nLo sfasamento di lettura si verifica quando lavoriamo con pi\u00f9 tabelle, il cui contenuto deve cambiare in modo coordinato. <\/p>\n

Supponiamo di avere tabelle che rappresentano post e le loro metainformazioni:<\/p>\n

\"A
\n
\nUna transazione legge dalle tabelle, un'altra le modifica:<\/p>\n

\"A
\n
\nA seguito dell'esecuzione della transazione T1, il post con title = Good e updated_by = T2, che rappresenta una certa incongruenza. <\/p>\n

In effetti, si tratta di una lettura non ripetibile, ma su pi\u00f9 tabelle.<\/p>\n

Per correggere ci\u00f2, T1 pu\u00f2 mettere dei blocchi su tutte le righe che legger\u00e0, impedendo alla transazione T2 di modificare le informazioni. Nel caso di MVCC, la transazione T2 verr\u00e0 annullata. La protezione da questa anomalia pu\u00f2 diventare importante se utilizziamo dei cursori. <\/p>\n

Sfasamento di scrittura<\/h2>\n

\nQuesta anomalia \u00e8 pi\u00f9 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:<\/p>\n

\"A
\n
\n\"A
\n
\nL'anomalia ha portato al fatto che nessuno dei dottori si presenter\u00e0 a lavoro. Come \u00e8 potuto succedere? Perch\u00e9 la transazione controllava una condizione che pu\u00f2 essere violata da un'altra transazione e a causa dell'isolamento non abbiamo visto questa modifica.<\/p>\n

\u00c8 lo stesso non ripetibile in lettura. Come opzione, le select possono applicare blocchi su queste righe.<\/p>\n

Lo skew in scrittura e lo skew in lettura sono combinazioni delle anomalie precedenti. Possiamo considerare lo skew in scrittura, che \u00e8 sostanzialmente una lettura fantasma. Consideriamo una tabella con i nomi dei dipendenti, il loro stipendio e il progetto su cui lavorano:<\/p>\n

\"A
\n
\n\"A
\n
\nAlla 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. <\/p>\n

La causa del problema \u00e8 esattamente la stessa del phantom reading. <\/p>\n

Conclusioni<\/h2>\n

\nL'indebolimento del livello di isolamento delle transazioni nel database \u00e8 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.<\/p>\n

\nScopri di pi\u00f9 sul corso.
\n<\/a><\/noindex><\/p>\n

Fonte: habr.com<\/a> <\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"

\u0412\u0441\u0435\u043c \u043f\u0440\u0438\u0432\u0435\u0442. \u041d\u0430 \u0441\u0432\u044f\u0437\u0438 \u0412\u043b\u0430\u0434\u0438\u0441\u043b\u0430\u0432 \u0420\u043e\u0434\u0438\u043d. \u0412 \u043d\u0430\u0441\u0442\u043e\u044f\u0449\u0435\u0435 \u0432\u0440\u0435\u043c\u044f \u044f \u044f\u0432\u043b\u044f\u044e\u0441\u044c \u0440\u0443\u043a\u043e\u0432\u043e\u0434\u0438\u0442\u0435\u043b\u0435\u043c \u043a\u0443\u0440\u0441\u0430 \u00ab\u0410\u0440\u0445\u0438\u0442\u0435\u043a\u0442\u043e\u0440 \u0432\u044b\u0441\u043e\u043a\u0438\u0445 \u043d\u0430\u0433\u0440\u0443\u0437\u043e\u043a\u00bb \u0432 OTUS, \u0430 \u0442\u0430\u043a\u0436\u0435 \u043f\u0440\u0435\u043f\u043e\u0434\u0430\u044e \u043d\u0430 \u043a\u0443\u0440\u0441\u0430\u0445, \u043f\u043e\u0441\u0432\u044f\u0449\u0435\u043d\u043d\u044b\u0445 \u0430\u0440\u0445\u0438\u0442\u0435\u043a\u0442\u0443\u0440\u0435 \u041f\u041e. \u041f\u043e\u043c\u0438\u043c\u043e \u043f\u0440\u0435\u043f\u043e\u0434\u0430\u0432\u0430\u043d\u0438\u044f, \u043a\u0430\u043a \u0432\u044b \u043c\u043e\u0433\u043b\u0438 \u0437\u0430\u043c\u0435\u0442\u0438\u0442\u044c, \u044f \u0437\u0430\u043d\u0438\u043c\u0430\u044e\u0441\u044c \u043d\u0430\u043f\u0438\u0441\u0430\u043d\u0438\u0435\u043c \u0430\u0432\u0442\u043e\u0440\u0441\u043a\u043e\u0433\u043e \u043c\u0430\u0442\u0435\u0440\u0438\u0430\u043b\u0430 \u0434\u043b\u044f \u0431\u043b\u043e\u0433\u0430 OTUS \u043d\u0430 \u0445\u0430\u0431\u0440\u0435 \u0438 \u0441\u0435\u0433\u043e\u0434\u043d\u044f\u0448\u043d\u044e\u044e \u0441\u0442\u0430\u0442\u044c\u044e \u0445\u043e\u0447\u0443 \u043f\u0440\u0438\u0443\u0440\u043e\u0447\u0438\u0442\u044c \u043a \u0437\u0430\u043f\u0443\u0441\u043a\u0443 \u043a\u0443\u0440\u0441\u0430 \u00abPostgreSQL\u00bb, \u043d\u0430 \u043a\u043e\u0442\u043e\u0440\u044b\u0439 \u043f\u0440\u044f\u043c\u043e \u0441\u0435\u0439\u0447\u0430\u0441 […]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":83338,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-83337","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t\n\t\n\t\n\t\n\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\n","aioseo_head_json":{"title":"\ud83e\udd47Cosa pu\u00f2 comportare il ridimensionamento del livello di isolamento delle transazioni nei database | ProHoster","description":"Ciao a tutti. Qui \u00e8 Vladislav Rodin.","canonical_url":"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/k-chemu-mozhet-privesti-oslablenie-urovnya-izolyaczii-tranzakczij-v-bazah-dannyh","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"it_IT","og:site_name":"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b","og:type":"article","og:title":"\ud83e\udd47\u041a \u0447\u0435\u043c\u0443 \u043c\u043e\u0436\u0435\u0442 \u043f\u0440\u0438\u0432\u0435\u0441\u0442\u0438 \u043e\u0441\u043b\u0430\u0431\u043b\u0435\u043d\u0438\u0435 \u0443\u0440\u043e\u0432\u043d\u044f \u0438\u0437\u043e\u043b\u044f\u0446\u0438\u0438 \u0442\u0440\u0430\u043d\u0437\u0430\u043a\u0446\u0438\u0439 \u0432 \u0431\u0430\u0437\u0430\u0445 \u0434\u0430\u043d\u043d\u044b\u0445 | ProHoster","og:description":"\u0412\u0441\u0435\u043c \u043f\u0440\u0438\u0432\u0435\u0442. \u041d\u0430 \u0441\u0432\u044f\u0437\u0438 \u0412\u043b\u0430\u0434\u0438\u0441\u043b\u0430\u0432 \u0420\u043e\u0434\u0438\u043d.","og:url":"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/k-chemu-mozhet-privesti-oslablenie-urovnya-izolyaczii-tranzakczij-v-bazah-dannyh","og:image":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:secure_url":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:width":350,"og:image:height":350,"article:published_time":"2020-05-30T05:42:48+00:00","article:modified_time":"2020-05-30T05:42:48+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"83337","title":null,"description":null,"keywords":null,"keyphrases":null,"primary_term":null,"canonical_url":null,"og_title":null,"og_description":null,"og_object_type":"default","og_image_type":"default","og_image_url":null,"og_image_width":null,"og_image_height":null,"og_image_custom_url":null,"og_image_custom_fields":null,"og_video":null,"og_custom_url":null,"og_article_section":null,"og_article_tags":null,"twitter_use_og":false,"twitter_card":"default","twitter_image_type":"default","twitter_image_url":null,"twitter_image_custom_url":null,"twitter_image_custom_fields":null,"twitter_title":null,"twitter_description":null,"schema":{"blockGraphs":[],"customGraphs":[],"default":{"data":{"Article":[],"Course":[],"Dataset":[],"FAQPage":[],"Movie":[],"Person":[],"Product":[],"ProductReview":[],"Car":[],"Recipe":[],"Service":[],"SoftwareApplication":[],"WebPage":[]},"graphName":"","isEnabled":true},"graphs":[]},"schema_type":null,"schema_type_options":null,"pillar_content":false,"robots_default":true,"robots_noindex":false,"robots_noarchive":false,"robots_nosnippet":false,"robots_nofollow":false,"robots_noimageindex":false,"robots_noodp":false,"robots_notranslate":false,"robots_max_snippet":null,"robots_max_videopreview":null,"robots_max_imagepreview":"large","priority":null,"frequency":null,"local_seo":null,"seo_analyzer_scan_date":null,"breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-02-28 15:20:28","updated":"2022-09-28 14:57:58","focus_keyword":null,"additional_keywords":null,"truseo_locale":null},"gt_translate_keys":[{"key":"link","format":"url"}],"_links":{"self":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/posts\/83337","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/comments?post=83337"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/posts\/83337\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/media\/83338"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/media?parent=83337"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/categories?post=83337"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/tags?post=83337"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}