{"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\/nl\/blog\/administrirovanie\/k-chemu-mozhet-privesti-oslablenie-urovnya-izolyaczii-tranzakczij-v-bazah-dannyh","title":{"rendered":"Wat zijn de gevolgen van het verlagen van het niveau van transactie-isolatie in databases?","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Hallo iedereen. Hier is Vladislav Rodin. Momenteel ben ik de cursusleider van de cursus 'Architect van hoge belasting' bij OTUS en geef ik ook onderwijs in cursussen over softwarearchitectuur.
\n<\/i>
\nNaast het lesgeven, zoals je misschien hebt gemerkt, schrijf ik originele content voor de OTUS-blog op Habr en vandaag wil ik deze articel wijden aan de lancering van de cursus \u00abPostgreSQL\u00bb<\/a><\/noindex>, waarvoor momenteel inschrijvingen open staan.<\/i><\/b><\/p>\n

\"Wat
\n<\/p>\n

Inleiding<\/h2>\n

\nIn de vorige keer<\/a><\/noindex> We hebben gesproken over het feit dat transacties in databases dienen om twee doelen te bereiken: het waarborgen van fouttolerantie en toegang tot gegevens in een concurrerende omgeving. Om deze taken volledig uit te voeren, moet een transactie voldoen aan de ACID-eisen. Vandaag zullen we uitgebreid ingaan op de letter I (isolatie)<\/b> in deze afkorting.
\n<\/a><\/noindex><\/p>\n

Isolatie<\/h2>\n

\nIsolatie lost het probleem van gegevensaccess in een concurrerende omgeving op, en biedt in feite bescherming tegen race conditions. Idealiter betekent isolatie serialisatie, dat wil zeggen een eigenschap die ervoor zorgt dat het resultaat van het gelijktijdig uitvoeren van transacties hetzelfde is als wanneer ze achtereenvolgens zouden worden uitgevoerd. Het belangrijkste probleem met deze eigenschap is dat het technisch moeilijk te garanderen is en als gevolg daarvan zwaar op de prestaties van het systeem drukt. Daarom wordt isolatie vaak verzwakt, met de aanvaarding van de risico's op het ontstaan van bepaalde anomalie\u00ebn, waar later over gesproken zal worden. De mogelijkheid van het ontstaan van bepaalde anomalie\u00ebn karakteriseert precies het niveau van transactie-isolatie.<\/p>\n

De meest bekende anomalie\u00ebn zijn: dirty read, non-repeatable read, phantom read, maar er zijn in feite nog 5 andere: dirty write, cursor lost update, lost update, read skew, write skew.<\/p>\n

Dirty write<\/h2>\n

\nDe kern van de anomalie is dat transacties niet-gecommitteerde gegevens kunnen overschrijven.<\/p>\n

\"Wat
\n
\nDeze anomalie is gevaarlijk omdat niet alleen gegevens na de commit van beide transacties kunnen conflicteren (zoals op de afbeelding), maar ook omdat de atomiciteit wordt geschonden: omdat we toestaan dat niet-gecommitteerde gegevens worden overschreven, is het onduidelijk hoe we \u00e9\u00e9n transactie kunnen terugdraaien zonder de andere aan te tasten. <\/p>\n

De anomalie is vrij eenvoudig te verhelpen: we plaatsen een vergrendeling op de schrijfoperatie voordat we beginnen met schrijven, en verbieden andere transacties om de registratie te wijzigen totdat de vergrendeling is opgeheven. <\/p>\n

Dirty read<\/h2>\n

\nDirty read betekent het lezen van niet-gecommitteerde gegevens. <\/p>\n

\"Wat
\n
\nProblemen ontstaan wanneer op basis van een steekproef bepaalde acties moeten worden ondernomen of beslissingen moeten worden genomen.<\/p>\n

Om de anomalie te corrigeren, kan er een leesklem geplaatst worden, maar dit heeft een grote impact op de prestaties. Het is veel eenvoudiger om te zeggen dat voor de rollback van een transactie de oorspronkelijke toestand van de gegevens (voor de start van de schrijfoperatie) absoluut in het systeem moet worden opgeslagen. Waarom daar niet van lezen? Dit is relatief goedkoop, daarom schakelen de meeste databases dirty reads standaard uit. <\/p>\n

Verloren update<\/h2>\n

\nVerloren update betekent verloren updates, en de vertaling weerspiegelt behoorlijk nauwkeurig de kern van het probleem:<\/p>\n

\"Wat
\n
\nFeitelijk is het resultaat van transactie T2 geannuleerd. Deze situatie wordt gecorrigeerd met expliciete of impliciete recordvergrendelingen. Dit betekent dat we ofwel simpelweg de record bijwerken, wat een impliciete vergrendeling cre\u00ebert, of we voeren select for update<\/b>, waardoor een lees- en schrijfvergrendeling wordt gecre\u00eberd. Let op dat deze operatie behoorlijk riskant is: met onze 'onschuldige' lezing blokkeren we andere lezingen. Sommige databases bieden een veiligere select for share<\/b>, die het mogelijk maakt om gegevens te lezen, maar wijzigingen niet toestaat. <\/p>\n

Verloren update met cursor<\/h2>\n

\nVoor meer verfijnde controle kunnen databases andere hulpmiddelen aanbieden, zoals een cursor. Een cursor is een structuur die een set rijen bevat en waarmee je door deze kunt itereren. declare cursor_name for select_statement<\/b>. De inhoud van de cursor wordt beschreven door de select. <\/p>\n

Waarom is een cursor nodig? Het punt is dat sommige databases een vergrendeling op alle records die door de select zijn geselecteerd aanbieden (read stability), of alleen op het record waar de cursor zich momenteel bevindt (cursor stability). Bij cursor stability wordt er een korte vergrendeling toegepast, wat het aantal vergrendelingen vermindert als we door een grote dataset itereren. Daarom wordt de anomalie van lost update voor de cursor apart benadrukt.<\/p>\n

Niet-herhaalbare lezing<\/h2>\n

\nNiet-herhaalbare lezing betekent dat tijdens het uitvoeren van onze transactie 2 opeenvolgende lezingen van dezelfde record zullen resulteren in verschillende uitkomsten, omdat een andere transactie tussen deze twee lezingen is ingegaan, onze gegevens heeft gewijzigd en is gecommit. <\/p>\n

\"Wat
\n
\nWaarom is dit \u00fcberhaupt een probleem? Stel je voor dat het doel van transactie T2 op de afbeelding is om alle artikelen te selecteren met een prijs van minder dan 150 eenheden. Iemand anders heeft de prijs verhoogd naar 200 eenheden. Daardoor werkt de ingestelde filter niet.<\/p>\n

Deze anomalie\u00ebn stoppen wanneer er tweefasige vergrendelingen worden toegevoegd of wanneer er gebruik wordt gemaakt van het MVCC-mechanisme, waarover we apart willen praten. <\/p>\n

Phantom read<\/h2>\n

\nEen phantom read is een lezing van gegevens die door een andere transactie zijn toegevoegd. <\/p>\n

\"Wat
\n
\nEen voorbeeld hiervan is het incorrect selecteren van het goedkoopste artikel wanneer deze anomalie zich voordoet. <\/p>\n

Het is al behoorlijk moeilijk om van phantom reads af te komen. Gewone vergrendeling is niet voldoende, want we kunnen niet vergrendelen wat er nog niet is. 2PL-systemen maken gebruik van predicatieve vergrendeling, terwijl MVCC-systemen transacties annuleren die mogelijk worden verstoord door invoegen. Zowel de eerste als de tweede mechanismen zijn vrij zwaar.<\/p>\n

Read skew<\/h2>\n

\nRead skew ontstaat wanneer we met meerdere tabellen werken waarvan de inhoud consistent moet veranderen. <\/p>\n

Laten we aannemen dat we tabellen hebben die posts en hun metadata vertegenwoordigen:<\/p>\n

\"Wat
\n
\nDe ene transactie leest uit de tabellen, terwijl de andere ze wijzigt:<\/p>\n

\"Wat
\n
\nAls resultaat van de uitvoering van transactie T1, heeft de post title = Good en updated_by = T2, wat een bepaalde inconsistentie is. <\/p>\n

In feite is dit een non-repeatable read, maar in de context van meerdere tabellen.<\/p>\n

Om dit op te lossen, kan T1 vergrendelingen leggen op alle rijen die ze zal lezen, waardoor transactie T2 de informatie niet kan wijzigen. In het geval van MVCC zal transactie T2 worden geannuleerd. Bescherming tegen deze anomalie kan belangrijk zijn als we cursors gebruiken. <\/p>\n

Write skew<\/h2>\n

\nDeze anomalie is ook eenvoudiger uit te leggen aan de hand van een voorbeeld: stel dat er in ons systeem minimaal \u00e9\u00e9n dokter op dienst moet zijn, maar beide dokters besluiten hun dienst te annuleren:<\/p>\n

\"Wat
\n
\n\"Wat
\n
\nDe anomalie leidde ertoe dat geen enkele dokter op dienst verschijnt. Hoe kwam dit zo? Omdat de transactie een voorwaarde controleerde die door een andere transactie kan worden geschonden, en door isolatie zagen we deze wijziging niet.<\/p>\n

Dit is dezelfde non-repeatable read. In sommige gevallen kunnen selects vergrendelingen op deze records plaatsen.<\/p>\n

Write skew en read skew zijn combinaties van de vorige anomalie\u00ebn. We kunnen write skew beschouwen, dat in wezen een phantom read is. Laten we een tabel bekijken met de namen van werknemers, hun salarissen en het project waaraan ze werken:<\/p>\n

\"Wat
\n
\n\"Wat
\n
\nUiteindelijk krijgen we het volgende beeld: elke manager dacht dat zijn wijziging niet zou leiden tot overschrijding van het budget, daarom maakten zij personeelswijzigingen die in totaal leidden tot overschrijding. <\/p>\n

De oorzaak van het probleem is precies dezelfde als bij phantom reads. <\/p>\n

Conclusies<\/h2>\n

\nHet verlagen van het isolatieniveau van transacties in de database is een compromis tussen beveiliging en prestaties; de keuze voor dit niveau moet worden benaderd op basis van de potenti\u00eble risico's voor het bedrijf bij het optreden van bepaalde anomalie\u00ebn.<\/p>\n

\nMeer informatie over de cursus.
\n<\/a><\/noindex><\/p>\n

Bron: 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\udd47Wat kan het verlagen van het isolatieniveau van transacties in databases betekenen | ProHoster","description":"Hallo allemaal. Dit is Vladislav Rodin.","canonical_url":"https:\/\/prohoster.info\/nl\/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":"nl_NL","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\/nl\/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\/nl\/wp-json\/wp\/v2\/posts\/83337","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/comments?post=83337"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/posts\/83337\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/media\/83338"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/media?parent=83337"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/categories?post=83337"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/tags?post=83337"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}