{"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\/da\/blog\/administrirovanie\/k-chemu-mozhet-privesti-oslablenie-urovnya-izolyaczii-tranzakczij-v-bazah-dannyh","title":{"rendered":"Hvad kan det f\u00f8re til, hvis niveauet af isolering af transaktioner i databaser sv\u00e6kkes?","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Hej alle sammen. Det er \u0412\u043b\u0430\u0434\u0438\u0441\u043b\u0430\u0432 \u0420\u043e\u0434\u0438\u043d her. I \u00f8jeblikket er jeg leder af kurset \"Arkitekt for h\u00f8jtydende systemer\" hos OTUS, samt underviser i kurser, der omhandler softwarearkitektur.
\n<\/i>
\nUdover undervisningen, som I m\u00e5ske har bem\u00e6rket, skriver jeg originalt indhold til OTUS-bloggen p\u00e5 Habr, og dagens artikel vil jeg dedikere til lanceringen af kurset \u00abPostgreSQL\u00bb<\/a><\/noindex>, som i \u00f8jeblikket er \u00e5bent for tilmelding.<\/i><\/b><\/p>\n

\"Hvad
\n<\/p>\n

Introduktion<\/h2>\n

\nI sidste gang<\/a><\/noindex> Vi har talt om, at transaktioner i databaser tjener til at l\u00f8se to opgaver: at sikre fejlmodstand og at give adgang til data i en konkurrencepr\u00e6get milj\u00f8. For at disse opgaver kan udf\u00f8res korrekt, skal en transaktion have ACID-egenskaber. I dag vil vi tale grundigt om bogstavet I (isolation)<\/b> i denne forkortelse.
\n<\/a><\/noindex><\/p>\n

Isolation<\/h2>\n

\nIsolering l\u00f8ser problemet med datatilgang i en konkurrencepr\u00e6get milj\u00f8 ved effektivt at give beskyttelse mod race conditions. I ideelle forhold betyder isolering serialisering, hvilket er en egenskab, der sikrer, at resultatet af udf\u00f8relsen af transaktioner parallelt er det samme som hvis de blev udf\u00f8rt sekventielt. Hovedproblemet med denne egenskab er, at den er meget sv\u00e6r at sikre teknisk og har derfor en stor indvirkning p\u00e5 systemets ydeevne. Derfor bliver isolering ofte lempet, idet man accepterer risici for visse anomalier, som vil blive n\u00e6vnt nedenfor. Muligheden for forekomsten af forskellige anomalier karakteriserer netop niveauet af transaktionsisolering.<\/p>\n

De mest kendte anomalier er: dirty read, non-repeatable read, phantom read, men der er faktisk 5 mere: dirty write, cursor lost update, lost update, read skew, write skew.<\/p>\n

Dirty write<\/h2>\n

\nKernen i anomalien er, at transaktioner kan overskrive ikke-committerede data.<\/p>\n

\"Hvad
\n
\nDenne anomalie er ikke kun farlig, fordi data kan konflikte efter commit af begge transaktioner (som p\u00e5 billedet), men ogs\u00e5 fordi den bryder atomariteten: da vi tillader at overskrive ikke-committerede data, er det uklart, hvordan vi kan rulle en transaktion tilbage uden at ber\u00f8re en anden. <\/p>\n

Anomalien behandles ret enkelt: vi s\u00e6tter en l\u00e5s p\u00e5 skrivning f\u00f8r vi begynder at skrive for at forhindre andre transaktioner i at \u00e6ndre posten, indtil l\u00e5sen er fjernet. <\/p>\n

Dirty read<\/h2>\n

\nDirty read betyder at l\u00e6se uforpligtede data. <\/p>\n

\"Hvad
\n
\nProblemer opst\u00e5r, n\u00e5r der skal tr\u00e6ffes beslutninger eller gennemf\u00f8res handlinger baseret p\u00e5 denne sampling.<\/p>\n

For at rette en anomali kan man p\u00e5f\u00f8re en l\u00e6seblokade, men dette vil have en stor negativ indvirkning p\u00e5 ydeevnen. Det er meget nemmere at sige, at for rollback af transaktionen skal den oprindelige tilstand af dataene (f\u00f8r skrivningen begyndte) n\u00f8dvendigvis v\u00e6re gemt i systemet. Hvorfor ikke l\u00e6se derfra? Dette er relativt billigt, s\u00e5 de fleste databaser fjerner dirty read som standard. <\/p>\n

Lost update<\/h2>\n

\nLost update betyder tabte opdateringer, og overs\u00e6ttelsen afspejler ganske pr\u00e6cist essensen af problemet:<\/p>\n

\"Hvad
\n
\nFaktisk blev resultatet af transaktionen T2 annulleret. S\u00e5dan en situation kan rettes med eksplicitte eller implicitte l\u00e5sninger af posten. Det vil sige, at vi enten blot opdaterer posten, hvilket medf\u00f8rer en implicit l\u00e5sning, eller vi udf\u00f8rer select for update<\/b>, hvilket skaber en l\u00e5sning p\u00e5 l\u00e6sning og skrivning. Bem\u00e6rk, at denne handling er ret farlig: med vores \"uskyldige\" l\u00e6sning l\u00e5ser vi andre l\u00e6sninger. Nogle databaser tilbyder en mere sikker select for share<\/b>, som tillader l\u00e6sning af data, men forhindrer \u00e6ndringer. <\/p>\n

Cursor lost update<\/h2>\n

\nFor mere fin kontrol kan databaser tilbyde andre v\u00e6rkt\u00f8jer, s\u00e5som en kursus. En kursus er en struktur, der indeholder et s\u00e6t r\u00e6kker og muligg\u00f8r iteration over dem. declare cursor_name for select_statement<\/b>. Indholdet af cursoren beskrives af select. <\/p>\n

Hvad er form\u00e5let med en cursor? Problemet er, at nogle databaser tilbyder blokering p\u00e5 alle poster, der v\u00e6lges af select (read stability), eller kun p\u00e5 den post, hvor cursoren i \u00f8jeblikket befinder sig (cursor stability). Ved cursor stability anvendes en kort l\u00e5s, hvilket reducerer antallet af l\u00e5se, n\u00e5r vi itererer over et stort datas\u00e6t. Derfor fremh\u00e6ves anomalien lost update for cursoren separat.<\/p>\n

Non-repeatable read<\/h2>\n

\nNon-repeatable read indeb\u00e6rer, at under udf\u00f8relsen af vores transaktion vil 2 p\u00e5 hinanden f\u00f8lgende l\u00e6sninger af den samme post f\u00f8re til forskellige resultater, fordi en anden transaktion har grebet ind mellem disse to l\u00e6sninger, \u00e6ndret vores data og er blevet committet. <\/p>\n

\"Hvad
\n
\nHvorfor er det overhovedet et problem? Forestil dig, at m\u00e5let for transaktionen T2 p\u00e5 billedet er at v\u00e6lge alle varer, hvis pris er mindre end 150 enheder. Nogen har \u00e6ndret prisen til 200 enheder. P\u00e5 denne m\u00e5de virker den indstillede filter ikke.<\/p>\n

Disse anomalier stopper med at opst\u00e5 ved at tilf\u00f8je to-fase l\u00e5sning eller ved at bruge MVCC-mekanismen, som jeg gerne vil tale om separat. <\/p>\n

Phantom read<\/h2>\n

\nEn phantom-l\u00e6sning kaldes det, n\u00e5r data l\u00e6ses, som er blevet tilf\u00f8jet af en anden transaktion. <\/p>\n

\"Hvad
\n
\nSom et eksempel kan vi observere en forkert udv\u00e6lgelse af den billigste vare ved forekomsten af denne anomali. <\/p>\n

At slippe af med phantom-l\u00e6sninger er allerede ganske sv\u00e6rt. Almindelig l\u00e5sning er ikke nok, for vi kan ikke l\u00e5se det, der endnu ikke findes. 2PL-systemer bruger predikativ l\u00e5sning, mens MVCC-systemer lader transaktionsplanl\u00e6ggeren annullere transaktioner, der kan blive forstyrret af en indtastning. Begge mekanismer er ret tunge.<\/p>\n

Read skew<\/h2>\n

\nRead skew opst\u00e5r, n\u00e5r vi arbejder med flere tabeller, hvis indhold skal \u00e6ndre sig konsekvent. <\/p>\n

Lad os antage, at der er tabeller, der repr\u00e6senterer indl\u00e6g og deres metadata:<\/p>\n

\"Hvad
\n
\n\u00c9n transaktion l\u00e6ser fra tabellerne, mens en anden \u00e6ndrer dem:<\/p>\n

\"Hvad
\n
\nSom et resultat af udf\u00f8relsen af transaktionen T1 har indl\u00e6gget title = Good, og updated_by = T2, hvilket er en form for uoverensstemmelse. <\/p>\n

Faktisk er dette en non-repeatable read, men inden for flere tabeller.<\/p>\n

For at rette op p\u00e5 dette kan T1 l\u00e6gge l\u00e5se p\u00e5 alle de r\u00e6kker, den vil l\u00e6se, hvilket forhindrer transaktionen T2 i at \u00e6ndre informationen. I tilf\u00e6lde af MVCC vil transaktionen T2 blive annulleret. Beskyttelse mod denne anomali kan blive vigtig, hvis vi bruger mark\u00f8rer. <\/p>\n

Write skew<\/h2>\n

\nDenne anomali er ogs\u00e5 lettere at forklare med et eksempel: lad os antage, at der i vores system skal v\u00e6re mindst \u00e9n l\u00e6ge p\u00e5 vagt, men begge l\u00e6ger besluttede at aflyse deres vagt:<\/p>\n

\"Hvad
\n
\n\"Hvad
\n
\nAnomalien f\u00f8rte til, at ingen af l\u00e6gerne vil m\u00f8de p\u00e5 vagt. Hvordan skete det? Fordi transaktionen kontrollerede en betingelse, der kan blive overtr\u00e5dt af en anden transaktion, og p\u00e5 grund af isolation s\u00e5 vi ikke denne \u00e6ndring.<\/p>\n

Det er det samme som non-repeatable read. Som en mulighed kan select l\u00e5se disse poster.<\/p>\n

Write skew og read skew er kombinationer af de tidligere anomalier. Vi kan overveje write skew, som i bund og grund er phantom read. Lad os se p\u00e5 en tabel, der indeholder medarbejdernes navne, deres l\u00f8n og det projekt, de arbejder p\u00e5:<\/p>\n

\"Hvad
\n
\n\"Hvad
\n
\nResultatet er, at vi f\u00e5r f\u00f8lgende billede: hver leder troede, at hans \u00e6ndring ikke ville f\u00f8re til overskridelse af budgettet, s\u00e5 de lavede personale\u00e6ndringer, der i alt f\u00f8rte til overskridelse. <\/p>\n

\u00c5rsagen til problemet er den samme som ved phantom reads. <\/p>\n

Konklusioner<\/h2>\n

\nNeds\u00e6ttelse af niveauet for transaktionsisolering i databasen er en afvejning mellem sikkerhed og ydeevne, og valget af dette niveau b\u00f8r overvejes ud fra de potentielle risici for virksomheden ved opst\u00e5en af forskellige anomalier.<\/p>\n

\nF\u00e5 mere at vide om kurset.
\n<\/a><\/noindex><\/p>\n

Kilde: 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\udd47Hvad kan det f\u00f8re til, n\u00e5r niveauet for transaktionsisolering i databaser bliver s\u00e6nket | ProHoster","description":"Hej alle sammen. Det er Vladislav Rodin.","canonical_url":"https:\/\/prohoster.info\/da\/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":"da_DK","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\/da\/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\/da\/wp-json\/wp\/v2\/posts\/83337","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/comments?post=83337"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/posts\/83337\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/media\/83338"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/media?parent=83337"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/categories?post=83337"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/tags?post=83337"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}