Ahoj všichni. Vladislav Rodin je v kontaktu. V současné době jsem vedoucím kurzu pro kurz Architekt s vysokou zátěží na OTUS a také vyučuji kurzy softwarové architektury.
Kromě výuky, jak jste si mohli všimnout, píšu originální materiály pro blog OTUS na Habré a chci se shodovat s dnešním článkem, aby se krylo se zahájením kurzu , do kterého se lze přihlásit právě teď.
úvod
В mluvili jsme o tom, že transakce v databázích slouží k řešení dvou problémů: zajištění odolnosti proti chybám a přístupu k datům v konkurenčním prostředí. Pro plné provedení těchto úkolů musí mít transakce vlastnosti ACID. Dnes budeme mluvit podrobně o dopise já (izolace) v této zkratce.
Izolace
Izolace řeší problém přístupu k datům v konkurenčním prostředí a v podstatě poskytuje ochranu před rasovými podmínkami. V ideálním případě izolace znamená serializaci, což je vlastnost, která zajišťuje, že výsledek paralelního provádění transakcí je stejný, jako kdyby byly prováděny sekvenčně. Hlavním problémem této vlastnosti je, že je velmi obtížné ji technicky zajistit a ve výsledku má významný dopad na výkon systému. Proto je izolace často oslabena, přijímá se rizika určitých anomálií, o kterých bude řeč níže. Možnost výskytu určitých anomálií přesně charakterizuje úroveň transakční izolace.
Nejznámější anomálie jsou: nečisté čtení, neopakovatelné čtení, fantomové čtení, ale ve skutečnosti je jich ještě 5: nečistý zápis, ztracená aktualizace kurzoru, ztracená aktualizace, zkreslení čtení, zkreslení zápisu.
Špinavý zápis
Podstatou anomálie je, že transakce mohou přepsat nepotvrzená data.
Tato anomálie je nebezpečná nejen proto, že data mohou kolidovat po provedení obou transakcí (jako na obrázku), ale také proto, že je narušena atomicita: protože umožňujeme přepsání nepotvrzených dat, není jasné, jak vrátit jednu transakci zpět, aniž by to ovlivnilo jinou. .
Anomálii lze ošetřit celkem jednoduše: před zahájením nahrávání připevníme k záznamu zámek, který zabrání jiným transakcím měnit záznam, dokud zámek neodstraníte.
Špinavé čtení
Nečisté čtení znamená čtení nepotvrzených dat.
Problémy nastávají, když je třeba na základě vzorku učinit kroky nebo rozhodnutí.
Chcete-li anomálii opravit, můžete připojit zámek čtení, což však výrazně ovlivní výkon. Mnohem jednodušší je říci, že pro vrácení transakce musí být počáteční stav dat (před zahájením záznamu) uložen v systému. Proč nečíst odtud? Je to dostatečně levné, že většina databází ve výchozím nastavení odstraňuje nečisté čtení.
Ztracená aktualizace
Lost update znamená ztracené aktualizace a překlad docela přesně odráží podstatu problému:
Ve skutečnosti byl výsledek transakce T2 obrácen. Tuto situaci lze napravit explicitními nebo implicitními zámky zápisu. To znamená, že buď jednoduše aktualizujeme záznam a pak dojde k implicitnímu zámku, nebo provedeme vyberte pro aktualizaci, což způsobí blokování čtení a zápisu. Vezměte prosím na vědomí, že taková operace je poměrně nebezpečná: naším „nevinným“ čtením blokujeme další čtení. Některé databáze nabízejí vyšší zabezpečení vybrat pro sdílení, což umožňuje data číst, ale ne upravovat.
Ztracená aktualizace kurzoru
Pro jemnější ovládání mohou základny nabízet další nástroje, jako je kurzor. Kurzor je struktura, která obsahuje sadu řádků a umožňuje přes ně iterovat. deklarovat název_kurzoru pro příkaz select. Obsah kurzoru je popsán pomocí select.
Proč potřebujete kurzor? Některé databáze totiž nabízejí zámek všech záznamů vybraných selectem (stabilita čtení), nebo pouze záznamu, na kterém se právě nachází kurzor (stabilita kurzoru). Se stabilitou kurzoru je implementován krátký zámek, který nám umožňuje snížit počet zámků, pokud iterujeme přes velký vzorek dat. Proto je anomálie ztracené aktualizace izolována samostatně pro kurzor.
Neopakovatelné čtení
Neopakovatelné čtení znamená, že během provádění naší transakce povedou 2 po sobě jdoucí čtení stejného záznamu k různým výsledkům, protože mezi tyto dvě čtení zasáhla jiná transakce, změnila naše data a byla potvrzena.
Proč je to vůbec problém? Představte si, že cílem transakce T2 na obrázku je vybrat veškeré zboží, jehož cena je nižší než 150 USD. Někdo jiný upravil cenu na 200 $. Nainstalovaný filtr tedy nefungoval.
Tyto anomálie se přestanou vyskytovat při přidání dvoufázových blokování nebo při použití mechanismu MVCC, který bych rád probral samostatně.
Fantomové čtení
Fantom je čtení dat, která byla přidána jinou transakcí.
Jako příklad můžeme pozorovat nesprávný výběr nejlevnějšího produktu při výskytu této anomálie.
Zbavit se fantomového čtení je již poměrně obtížné. Pravidelné blokování nestačí, protože nemůžeme blokovat něco, co ještě neexistuje. Systémy 2PL používají prediktivní zamykání, zatímco systémy MVCC mají plánovač transakcí, který vrací zpět transakce, které by mohly být narušeny vložením. První i druhý mechanismus jsou poměrně těžké.
Číst zkresleně
Ke zkreslení čtení dochází, když pracujeme s více tabulkami, jejichž obsah se musí důsledně měnit.
Řekněme, že máme tabulky představující příspěvky a jejich metainformace:
Jedna transakce čte z tabulek, druhá je upravuje:
V důsledku transakce T1 má příspěvek název = Dobrý a aktualizováno_by = T2, což je určitý druh nekonzistence.
Ve skutečnosti se jedná o neopakovatelné čtení, ale jako součást několika tabulek.
Chcete-li to vyřešit, může T1 umístit zámky na všechny řádky, které bude číst, což zabrání transakci T2 ve změně informací. V případě MVCC bude transakce T2 zrušena. Ochrana proti této anomálii se může stát důležitou, pokud použijeme kurzory.
Pište šikmo
Tuto anomálii lze také snáze vysvětlit na příkladu: předpokládejme, že v našem systému by měl mít službu alespoň jeden lékař, ale oba lékaři se rozhodli svou službu zrušit:
Anomálie znamenala, že žádný z lékařů nebude ve službě. Proč se to stalo? Protože transakce kontrolovala podmínku, která by mohla být porušena jinou transakcí, a kvůli izolaci jsme tuto změnu nezaznamenali.
Toto je stejné neopakovatelné čtení. Alternativně může selecty umístit zámky na tyto záznamy.
Zkreslení zápisu a zkreslení čtení jsou kombinacemi předchozích anomálií. Můžete zvážit zkreslení zápisu, což je v podstatě fantomové čtení. Zvažte tabulku, která obsahuje jména zaměstnanců, jejich platy a projekt, na kterém pracují:
Výsledkem je následující obrázek: každý manažer si myslel, že jeho změna nepovede k překročení rozpočtu, a tak provedl personální změny, které společně vedly k překročení nákladů.
Příčina problému je úplně stejná jako u fantomového čtení.
Závěry
Uvolnění úrovně izolace transakcí v databázi je kompromisem mezi bezpečností a výkonem; k volbě této úrovně by se mělo přistupovat na základě potenciálních rizik pro podnik, pokud se vyskytnou určité anomálie.
Zdroj: www.habr.com