{"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\/sv\/blog\/administrirovanie\/k-chemu-mozhet-privesti-oslablenie-urovnya-izolyaczii-tranzakczij-v-bazah-dannyh","title":{"rendered":"Vad kan en f\u00f6rsvagning av isoleringsniv\u00e5n i databaser leda till?","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Hej alla. Det \u00e4r Vladislav Rodin h\u00e4r. Just nu \u00e4r jag kursledare f\u00f6r kursen \"Arkitekt f\u00f6r h\u00f6g belastning\" p\u00e5 OTUS, och jag undervisar ocks\u00e5 i kurser relaterade till mjukvaruarkitektur.
\n<\/i>
\nF\u00f6rutom undervisning, som ni kanske har m\u00e4rkt, skriver jag originalmaterial f\u00f6r OTUS-bloggen p\u00e5 Habr\u00e9 och dagens artikel vill jag koppla till lanseringen av kursen \"PostgreSQL\"<\/a><\/noindex>, som just nu har \u00f6ppnat f\u00f6r anm\u00e4lningar.<\/i><\/b><\/p>\n

\"Vad
\n<\/p>\n

Introduktion<\/h2>\n

\nI f\u00f6rra g\u00e5ngen<\/a><\/noindex> pratade vi om att transaktioner i databaser tj\u00e4nar tv\u00e5 syften: att s\u00e4kerst\u00e4lla tillf\u00f6rlitlighet och \u00e5tkomst till data i en konkurrensutsatt milj\u00f6. F\u00f6r att dessa syften ska uppfyllas m\u00e5ste en transaktion uppfylla ACID-egenskaperna. Idag kommer vi att diskutera bokstaven I (isolation)<\/b> i denna akronym.
\n<\/a><\/noindex><\/p>\n

Isolering<\/h2>\n

\nIsolering l\u00f6ser problemet med \u00e5tkomst till data i en konkurrensutsatt milj\u00f6, genom att i praktiken erbjuda skydd mot race conditioner. Idealiskt sett inneb\u00e4r isolering serialisering, det vill s\u00e4ga en egenskap som s\u00e4kerst\u00e4ller att resultatet av att transaktioner k\u00f6rs parallellt \u00e4r detsamma som om de utf\u00f6rdes sekventiellt. Huvudproblemet med denna egenskap \u00e4r att den \u00e4r mycket sv\u00e5r att uppn\u00e5 tekniskt och som f\u00f6ljd p\u00e5verkar den systemets prestanda kraftigt. Det \u00e4r just d\u00e4rf\u00f6r som isoleringen ofta f\u00f6rsvagas, med medvetenhet om riskerna f\u00f6r vissa anomalier som kommer att tas upp nedan. M\u00f6jligheten f\u00f6r vissa anomalier \u00e4r just det som k\u00e4nnetecknar niv\u00e5n av transaktionsisolering.<\/p>\n

De mest k\u00e4nda anomalierna \u00e4r: dirty read, non-repeatable read, phantom read, men det finns faktiskt ytterligare 5: dirty write, cursor lost update, lost update, read skew, write skew.<\/p>\n

Dirty write<\/h2>\n

\nEssensen av anomalien \u00e4r att transaktioner kan skriva \u00f6ver ocommenderade data.<\/p>\n

\"Vad
\n
\nDenna anomali \u00e4r farlig inte bara f\u00f6r att data kan krocka efter att b\u00e5da transaktionerna har genomf\u00f6rts (som p\u00e5 bilden), utan ocks\u00e5 f\u00f6r att den bryter atomariteten: eftersom vi till\u00e5ter att skriva \u00f6ver ocommenderade data, \u00e4r det oklart hur man kan rulla tillbaka en transaktion utan att p\u00e5verka den andra. <\/p>\n

Anomalien kan \u00e5tg\u00e4rdas ganska enkelt: genom att s\u00e4tta en l\u00e5s p\u00e5 skrivningen innan skrivningen b\u00f6rjar, f\u00f6rhindrar vi andra transaktioner fr\u00e5n att \u00e4ndra posten tills l\u00e5set har tagits bort. <\/p>\n

Dirty read<\/h2>\n

\nDirty read inneb\u00e4r att l\u00e4sa obekr\u00e4ftade data. <\/p>\n

\"Vad
\n
\nProblem uppst\u00e5r n\u00e4r man beh\u00f6ver fatta beslut eller vidta \u00e5tg\u00e4rder baserat p\u00e5 urvalet.<\/p>\n

F\u00f6r att \u00e5tg\u00e4rda anomalier kan man inf\u00f6ra en l\u00e4sblockering, men det p\u00e5verkar prestandan kraftigt. Det \u00e4r mycket enklare att s\u00e4ga att f\u00f6r rollback av en transaktion m\u00e5ste det ursprungliga tillst\u00e5ndet f\u00f6r datan (f\u00f6re skrivningens b\u00f6rjan) sparas i systemet. Varf\u00f6r inte l\u00e4sa d\u00e4rifr\u00e5n? Det \u00e4r ganska kostnadseffektivt, d\u00e4rf\u00f6r avaktiverar de flesta databaser dirty read som standard. <\/p>\n

Lost update<\/h2>\n

\nLost update inneb\u00e4r f\u00f6rlorade uppdateringar, och \u00f6vers\u00e4ttningen \u00e5terspeglar problemet ganska bra:<\/p>\n

\"Vad
\n
\nFaktiskt har resultatet av transaktionen T2 annullerats. Denna situation kan \u00e5tg\u00e4rdas med explicita eller implicita l\u00e5s av posten. Det vill s\u00e4ga att vi antingen bara uppdaterar posten, vilket resulterar i ett implicerat l\u00e5s, eller s\u00e5 utf\u00f6r vi select for update<\/b>, vilket skapar en l\u00e5sning b\u00e5de f\u00f6r l\u00e4sning och skrivning. Observera att denna operation \u00e4r ganska farlig: med v\u00e5r \"oskyldiga\" l\u00e4sning l\u00e5ser vi andra l\u00e4sningar. Vissa databaser erbjuder en s\u00e4krare select for share<\/b>, som g\u00f6r det m\u00f6jligt att l\u00e4sa data men inte att \u00e4ndra dem. <\/p>\n

Cursor lost update<\/h2>\n

\nF\u00f6r mer i detaljkontroll kan databaser erbjuda andra verktyg, som t.ex. en kurs\u00f6r. En kurs\u00f6r \u00e4r en struktur som inneh\u00e5ller en upps\u00e4ttning f\u00f6r att iterera \u00f6ver rader. declare cursor_name for select_statement<\/b>. Inneh\u00e5llet i en cursor beskrivs med select. <\/p>\n

Vad beh\u00f6vs en cursor till? Faktum \u00e4r att vissa databaser erbjuder blockeringar p\u00e5 alla poster som valts med select (read stability), eller bara p\u00e5 den post d\u00e4r cursorn f\u00f6r n\u00e4rvarande befinner sig (cursor stability). Vid cursor stability genomf\u00f6rs en kort l\u00e5sning, vilket minskar antalet l\u00e5sningar om vi itererar \u00f6ver en stor datam\u00e4ngd. D\u00e4rf\u00f6r behandlas anomaliteter som lost update separat f\u00f6r cursorn.<\/p>\n

Non-repeatable read<\/h2>\n

\nNon-repeatable read inneb\u00e4r att under utf\u00f6randet av v\u00e5r transaktion kommer 2 p\u00e5 varandra f\u00f6ljande l\u00e4sningar av samma post att ge olika resultat, eftersom en annan transaktion har blandat sig mellan dessa tv\u00e5 l\u00e4sningar, \u00e4ndrat v\u00e5ra data och blivit bekr\u00e4ftad. <\/p>\n

\"Vad
\n
\nVarf\u00f6r \u00e4r detta \u00f6verhuvudtaget ett problem? T\u00e4nk dig att m\u00e5let med transaktionen T2 p\u00e5 bilden \u00e4r att v\u00e4lja alla varor vars pris \u00e4r l\u00e4gre \u00e4n 150 enheter. N\u00e5gon annan har uppdaterat priset till 200 enheter. D\u00e4rmed fungerar inte den inst\u00e4llda filtreringen.<\/p>\n

Dessa anomalier slutar uppst\u00e5 vid anv\u00e4ndning av tv\u00e5fasl\u00e5sning eller en MVCC-mekanism, vilket jag skulle vilja diskutera separat. <\/p>\n

Fantoml\u00e4sning<\/h2>\n

\nEn fantoml\u00e4sning kallas de data som har lagts till av en annan transaktion. <\/p>\n

\"Vad
\n
\nSom ett exempel kan vi observera en felaktig urval av den billigaste produkten vid uppkomsten av denna anomali. <\/p>\n

Att bli av med fantoml\u00e4sningar \u00e4r redan tillr\u00e4ckligt sv\u00e5rt. En vanlig l\u00e5sning \u00e4r inte tillr\u00e4cklig, eftersom vi inte kan l\u00e5sa n\u00e5got som \u00e4nnu inte existerar. 2PL-system anv\u00e4nder predikativ l\u00e5sning, medan MVCC-systemet avbryter transaktioner som kan st\u00f6ras av ins\u00e4ttning. B\u00e5de den f\u00f6rsta och den andra mekanismen \u00e4r ganska resurskr\u00e4vande.<\/p>\n

L\u00e4s-skevhet<\/h2>\n

\nL\u00e4s-skevhet uppst\u00e5r n\u00e4r vi arbetar med flera tabeller vars inneh\u00e5ll ska f\u00f6r\u00e4ndras p\u00e5 ett koordinerat s\u00e4tt. <\/p>\n

Anta att vi har tabeller som representerar inl\u00e4gg och deras meta-information:<\/p>\n

\"Vad
\n
\nEn transaktion l\u00e4ser fr\u00e5n tabellerna, en annan \u00e4ndrar dem:<\/p>\n

\"Vad
\n
\nSom resultat av transaktionen T1 har inl\u00e4gget titel = Good, och updated_by = T2, vilket skapar en viss inkonsekvens. <\/p>\n

Detta \u00e4r i sj\u00e4lva verket en icke-repetitiv l\u00e4sning, men med flera tabeller.<\/p>\n

F\u00f6r att \u00e5tg\u00e4rda detta kan T1 s\u00e4tta l\u00e5s p\u00e5 alla rader som den kommer att l\u00e4sa, vilket hindrar transaktionen T2 fr\u00e5n att \u00e4ndra informationen. I fallet med MVCC kommer transaktionen T2 att avbrytas. Skyddet mot denna anomali kan bli viktigt om vi anv\u00e4nder mark\u00f6rer. <\/p>\n

Skriv-skevhet<\/h2>\n

\nDenna anomali \u00e4r ocks\u00e5 l\u00e4ttare att f\u00f6rklara med ett exempel: anta att det i v\u00e5rt system \u00e5tminstone en l\u00e4kare m\u00e5ste vara i tj\u00e4nst, men b\u00e5da l\u00e4karna har beslutat att avbryta sina arbetspass:<\/p>\n

\"Vad
\n
\n\"Vad
\n
\nAnomalien ledde till att ingen av l\u00e4karna kommer att g\u00e5 i tj\u00e4nst. Varf\u00f6r h\u00e4nde det? F\u00f6r att transaktionen kontrollerade ett villkor som kan brytas av en annan transaktion, och p\u00e5 grund av isoleringen s\u00e5g vi inte denna f\u00f6r\u00e4ndring.<\/p>\n

Det \u00e4r samma som non-repeatable read. Som alternativ kan selects inf\u00f6ra blockeringar p\u00e5 dessa poster.<\/p>\n

Write skew och read skew \u00e4r kombinationer av de tidigare anomalierna. Man kan betrakta write skew som i grunden en phantom read. L\u00e5t oss \u00f6verv\u00e4ga en tabell d\u00e4r anst\u00e4lldas namn, deras l\u00f6ner och projektet de arbetar p\u00e5 finns:<\/p>\n

\"Vad
\n
\n\"Vad
\n
\nSom ett resultat f\u00e5r vi f\u00f6ljande bild: varje chef trodde att deras \u00e4ndringar inte skulle leda till budget\u00f6verskridningar, vilket gjorde att de genomf\u00f6rde personal\u00e4ndringar som totalt ledde till \u00f6verskridande av budgeten. <\/p>\n

Orsaken till problemet \u00e4r exakt densamma som vid phantom reading. <\/p>\n

Slutsatser<\/h2>\n

\nAtt s\u00e4nka niv\u00e5n av transaktionsisolering i databasen \u00e4r en kompromiss mellan s\u00e4kerhet och prestanda; valet av denna niv\u00e5 b\u00f6r baseras p\u00e5 potentiella risker f\u00f6r verksamheten vid uppkomsten av s\u00e5dana eller andra anomalier.<\/p>\n

\nL\u00e4s mer om kursen.
\n<\/a><\/noindex><\/p>\n

K\u00e4lla: 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\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\udd47Vad kan leda till s\u00e4nkta niv\u00e5er av transaktionsisolering i databaser | ProHoster","description":"Hej allihopa. Det \u00e4r Vladislav Rodin som kontaktar er.","canonical_url":"https:\/\/prohoster.info\/sv\/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":"sv_SE","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\/sv\/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\/sv\/wp-json\/wp\/v2\/posts\/83337","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/sv\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/sv\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/sv\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/sv\/wp-json\/wp\/v2\/comments?post=83337"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/sv\/wp-json\/wp\/v2\/posts\/83337\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/sv\/wp-json\/wp\/v2\/media\/83338"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/sv\/wp-json\/wp\/v2\/media?parent=83337"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/sv\/wp-json\/wp\/v2\/categories?post=83337"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/sv\/wp-json\/wp\/v2\/tags?post=83337"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}