{"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\/de\/blog\/administrirovanie\/k-chemu-mozhet-privesti-oslablenie-urovnya-izolyaczii-tranzakczij-v-bazah-dannyh","title":{"rendered":"Was kann das Absenken des Isolationsniveaus von Transaktionen in Datenbanken zur Folge haben?","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Hallo zusammen. Hier spricht Wladislaw Rodin. Ich bin zurzeit der Leiter des Kurses \u201eArchitekt f\u00fcr hohe Lasten\u201c bei OTUS und unterrichte auch in Kursen, die sich mit Softwarearchitektur befassen.
\n<\/i>
\nNeben dem Unterrichten schreibe ich, wie Sie vielleicht bemerkt haben, originelle Inhalte f\u00fcr den OTUS-Blog auf Habr, und den heutigen Artikel m\u00f6chte ich an den Start des Kurses \u201ePostgreSQL\u201c<\/a><\/noindex>, f\u00fcr den gerade die Anmeldungen ge\u00f6ffnet sind, ankn\u00fcpfen.<\/i><\/b><\/p>\n

\"Was
\n<\/p>\n

Einf\u00fchrung<\/h2>\n

\nIm letztes Mal<\/a><\/noindex> Wir haben dar\u00fcber gesprochen, dass Transaktionen in Datenbanken zwei Aufgaben l\u00f6sen: Gew\u00e4hrleistung der Fehlertoleranz und Zugriff auf Daten in einer konkurrierenden Umgebung. Um diese Aufgaben vollst\u00e4ndig zu erf\u00fcllen, muss eine Transaktion \u00fcber ACID-Eigenschaften verf\u00fcgen. Heute werden wir ausf\u00fchrlich \u00fcber den Buchstaben I (Isolation)<\/b> in diesem Akronym sprechen.
\n<\/a><\/noindex><\/p>\n

Isolierung<\/h2>\n

\nIsolation l\u00f6st das Problem des Datenzugriffs in einer konkurrierenden Umgebung, indem sie effektiv Schutz vor Race Conditions bietet. Idealerweise bedeutet Isolation Serialisierung, also eine Eigenschaft, die sicherstellt, dass das Ergebnis der gleichzeitigen Ausf\u00fchrung von Transaktionen dasselbe ist, als ob sie nacheinander ausgef\u00fchrt w\u00fcrden. Das Hauptproblem dieser Eigenschaft besteht darin, dass sie technisch sehr schwer zu gew\u00e4hrleisten ist, was sich stark auf die Systemleistung auswirkt. Aus diesem Grund wird die Isolation oft gelockert, indem Risiken f\u00fcr bestimmte Anomalien in Kauf genommen werden, die im Folgenden beschrieben werden. Die M\u00f6glichkeit des Auftretens von Anomalien charakterisiert den Grad der Isolation von Transaktionen.<\/p>\n

Die bekanntesten Anomalien sind: dirty read, non-repeatable read, phantom read, aber es gibt tats\u00e4chlich noch f\u00fcnf weitere: dirty write, cursor lost update, lost update, read skew, write skew.<\/p>\n

Dirty write<\/h2>\n

\nDie Essenz dieser Anomalie besteht darin, dass Transaktionen nicht festgeschriebene Daten \u00fcberschreiben k\u00f6nnen.<\/p>\n

\"Was
\n
\nDiese Anomalie ist gef\u00e4hrlich, nicht nur weil Daten nach dem Commit beider Transaktionen in Konflikt geraten k\u00f6nnen (wie im Bild), sondern auch weil die Atomarit\u00e4t verletzt wird: Wenn wir erlauben, nicht festgeschriebene Daten zu \u00fcberschreiben, ist unklar, wie eine Transaktion zur\u00fcckgesetzt werden kann, ohne die andere zu beeintr\u00e4chtigen. <\/p>\n

Die Anomalie l\u00e4sst sich recht einfach beheben: Wir setzen eine Schreibsperre vor Beginn des Schreibvorgangs, um anderen Transaktionen zu verbieten, die Aufzeichnung zu \u00e4ndern, bis die Sperre aufgehoben wird. <\/p>\n

Dirty read<\/h2>\n

\nDirty read bedeutet das Lesen von nicht festgeschriebenen Daten. <\/p>\n

\"Was
\n
\nProbleme treten auf, wenn auf der Basis einer Stichprobe Handlungen ausgef\u00fchrt oder Entscheidungen getroffen werden m\u00fcssen.<\/p>\n

Um eine Anomalie zu beheben, kann eine Lesesperre gesetzt werden, was jedoch die Leistung erheblich beeintr\u00e4chtigt. Es ist viel einfacher zu sagen, dass f\u00fcr das Rollback einer Transaktion der urspr\u00fcngliche Zustand der Daten (vor dem Beginn des Schreibvorgangs) unbedingt im System gespeichert sein muss. Warum nicht von dort lesen? Das ist ziemlich kosteng\u00fcnstig, weshalb die meisten Datenbanken dirty reads standardm\u00e4\u00dfig ausschlie\u00dfen. <\/p>\n

Verlorenes Update<\/h2>\n

\nVerlorenes Update bedeutet verlorene Aktualisierungen, und die \u00dcbersetzung spiegelt das Kernproblem ziemlich genau wider:<\/p>\n

\"Was
\n
\nTats\u00e4chlich wurde das Ergebnis der Transaktion T2 zur\u00fcckgesetzt. Diese Situation wird durch explizite oder implizite Schreibsperren korrigiert. Das hei\u00dft, entweder aktualisieren wir einfach den Datensatz, wodurch eine implizite Sperre entsteht, oder wir f\u00fchren aus select for update<\/b>, was eine Lese- und Schreibsperre verursacht. Beachten Sie, dass eine solche Operation ziemlich riskant ist: Mit unserem \"unschuldigen\" Lesen sperren wir andere Lesevorg\u00e4nge. Einige Datenbanken bieten eine sicherere select for share<\/b>, die das Lesen von Daten erlaubt, aber \u00c4nderungen nicht gestattet. <\/p>\n

Cursor verlorenes Update<\/h2>\n

\nZum besseren Zugang k\u00f6nnen Datenbanken andere Werkzeuge anbieten, wie zum Beispiel einen Cursor. Ein Cursor ist eine Struktur, die eine Menge von Zeilen enth\u00e4lt und es erm\u00f6glicht, \u00fcber diese zu iterieren. declare cursor_name for select_statement<\/b>. Der Inhalt des Cursors wird durch einen Select-Befehl beschrieben. <\/p>\n

Warum ist ein Cursor notwendig? Der Grund ist, dass einige Datenbanken eine Sperre f\u00fcr alle durch einen Select-Befehl ausgew\u00e4hlten Datens\u00e4tze anbieten (Read Stability) oder nur f\u00fcr den Datensatz, auf dem sich der Cursor momentan befindet (Cursor Stability). Bei Cursor Stability wird eine kurzfristige Sperre gesetzt, was die Anzahl der Sperren verringert, wenn wir uns durch eine gro\u00dfe Datenmenge iterieren. Daher wird die Anomalie des verlorenen Updates f\u00fcr den Cursor separat hervorgehoben.<\/p>\n

Nicht-wiederholbare Lesevorg\u00e4nge<\/h2>\n

\nNicht-wiederholbare Lesevorg\u00e4nge besagen, dass w\u00e4hrend der Ausf\u00fchrung unserer Transaktion 2 aufeinanderfolgende Lesevorg\u00e4nge desselben Datensatzes zu unterschiedlichen Ergebnissen f\u00fchren, weil eine andere Transaktion zwischen diesen beiden Lesevorg\u00e4ngen eingegriffen hat, unsere Daten ge\u00e4ndert hat und festgeschrieben wurde. <\/p>\n

\"Was
\n
\nWarum ist das \u00fcberhaupt ein Problem? Stellen Sie sich vor, das Ziel der Transaktion T2 besteht darin, alle Produkte auszuw\u00e4hlen, deren Preis unter 150 W\u00e4hrungseinheiten liegt. Jemand anderes hat den Preis auf 200 W\u00e4hrungseinheiten aktualisiert. Somit hat der festgelegte Filter nicht funktioniert.<\/p>\n

Diese Anomalien treten nicht mehr auf, wenn man Zwei-Phasen-Sperren hinzuf\u00fcgt oder den MVCC-Mechanismus verwendet, \u00fcber den ich gerne separat sprechen w\u00fcrde. <\/p>\n

Phantomlesung<\/h2>\n

\nEine Phantomlesung bezeichnet das Lesen von Daten, die von einer anderen Transaktion hinzugef\u00fcgt wurden. <\/p>\n

\"Was
\n
\nAls Beispiel kann man feststellen, dass bei Auftreten dieser Anomalie die Auswahl des billigsten Produkts falsch ist. <\/p>\n

Phantomlesungen zu beseitigen ist bereits recht schwierig. Eine einfache Sperre reicht nicht aus, da wir das, was noch nicht existiert, nicht sperren k\u00f6nnen. 2PL-Systeme verwenden pr\u00e4dikative Sperren, w\u00e4hrend die MVCC-Systeme Transaktionen abbrechen, die durch Einf\u00fcgungen beeintr\u00e4chtigt werden k\u00f6nnten. Beide Mechanismen sind recht schwerf\u00e4llig.<\/p>\n

Read Skew<\/h2>\n

\nRead Skew tritt auf, wenn wir mit mehreren Tabellen arbeiten, deren Inhalte konsistent ge\u00e4ndert werden m\u00fcssen. <\/p>\n

Angenommen, wir haben Tabellen, die Posts und deren Metainformationen darstellen:<\/p>\n

\"Was
\n
\nEine Transaktion liest aus den Tabellen, eine andere ver\u00e4ndert sie:<\/p>\n

\"Was
\n
\nIm Ergebnis der Ausf\u00fchrung der Transaktion T1 hat der Post den Titel = Good und updated_by = T2, was eine gewisse Inkonsistenz darstellt. <\/p>\n

Tats\u00e4chlich handelt es sich hierbei um eine nicht wiederholbare Lesung, jedoch in mehreren Tabellen.<\/p>\n

Um dies zu beheben, kann T1 Sperren auf alle Zeilen setzen, die sie lesen wird, was der Transaktion T2 verbietet, Informationen zu \u00e4ndern. Im Falle von MVCC wird die Transaktion T2 abgebrochen. Der Schutz vor dieser Anomalie kann wichtig werden, wenn wir Cursors verwenden. <\/p>\n

Write Skew<\/h2>\n

\nDiese Anomalie l\u00e4sst sich ebenfalls einfacher anhand eines Beispiels erkl\u00e4ren: Angenommen, in unserem System muss mindestens ein Arzt im Dienst sein, doch beide \u00c4rzte haben beschlossen, ihren Dienst abzusagen:<\/p>\n

\"Was
\n
\n\"Was
\n
\nDie Anomalie f\u00fchrte dazu, dass keiner der \u00c4rzte in den Dienst tritt. Wie konnte es dazu kommen? Weil die Transaktion eine Bedingung \u00fcberpr\u00fcfte, die von einer anderen Transaktion verletzt werden kann, und wir aufgrund der Isolation diese \u00c4nderung nicht gesehen haben.<\/p>\n

Das ist dasselbe wie ein Non-Repeatable Read. Als Option k\u00f6nnen Selects Sperren f\u00fcr diese Datens\u00e4tze setzen.<\/p>\n

Write Skew und Read Skew sind Kombinationen der vorherigen Anomalien. Man kann Write Skew betrachten, das im Grunde ein Phantom Read ist. Betrachten wir eine Tabelle, die die Namen von Mitarbeitern, deren Geh\u00e4lter und das Projekt, an dem sie arbeiten, enth\u00e4lt:<\/p>\n

\"Was
\n
\n\"Was
\n
\nInsgesamt ergibt sich folgendes Bild: Jeder Manager dachte, dass seine \u00c4nderung nicht zu einem Budget\u00fcberschreitung f\u00fchren w\u00fcrde, weshalb sie personelle \u00c4nderungen vornahmen, die insgesamt zu einem \u00dcberschuss f\u00fchrten. <\/p>\n

Der Grund f\u00fcr das Auftreten des Problems ist der gleiche wie bei Phantom-Lesungen. <\/p>\n

Das DBMS Tarantool ist ein attraktives, zukunftstr\u00e4chtiges Produkt zur Erstellung von hochbelasteten Anwendungen.<\/h2>\n

\nDie Lockerung des Isolationsniveaus von Transaktionen in einer Datenbank ist ein Kompromiss zwischen Sicherheit und Leistung, und die Wahl dieses Niveaus sollte unter Ber\u00fccksichtigung der potenziellen Risiken f\u00fcr das Unternehmen bei den verschiedenen Anomalien getroffen werden.<\/p>\n

\nWeitere Informationen zum Kurs.
\n<\/a><\/noindex><\/p>\n

Quelle: 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\udd47Welche Auswirkungen kann die Lockerung des Isolationsniveaus von Transaktionen in Datenbanken haben | ProHoster","description":"Hallo zusammen. Hier ist Wladislaw Rodin.","canonical_url":"https:\/\/prohoster.info\/de\/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":"de_DE","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\/de\/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\/de\/wp-json\/wp\/v2\/posts\/83337","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/comments?post=83337"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/posts\/83337\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/media\/83338"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/media?parent=83337"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/categories?post=83337"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/tags?post=83337"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}