Podcast na Databázové transakce, SQL a architektury

Kapitoly

Všechno, nebo nic

Co je to transakce?

Kouzelné vlastnosti transakcí

Když jedna databáze nestačí

Dvoufázové potvrzení

Problémy se souběhem: Zámky a uváznutí

Jak se vyhnout uváznutí?

Transakce v praxi: SQL

Záchranná síť: Žurnály a zotavení

Shrnutí a rozloučení

Přepis

Kristýna: ...a přesně proto je to celé tak geniální! Buď se provede všechno, nebo vůbec nic. Žádné polovičaté řešení.

Martin: Počkej, takže když posílám peníze v internetovém bankovnictví, tak ta operace, to je přesně ono? Buď peníze odejdou z mého účtu a přijdou na ten druhý, nebo se prostě nic nestane a peníze mi zůstanou. Nic mezi tím?

Kristýna: Přesně tak! Trefil jsi hřebíček na hlavičku. To je srdce celého konceptu transakcí.

Martin: To je skvělé! Okay, tohle musíme rozebrat od začátku. Posloucháte Studyfi Podcast a dnes se ponoříme do světa databázových transakcí.

Kristýna: Takže, Martine, tvoje analogie s bankou byla perfektní. Transakce je v podstatě skupina operací, které k sobě logicky patří a musí se provést jako jeden celek. Jedna nerozbitná jednotka.

Martin: Jako jeden atom, který nejde dál dělit?

Kristýna: Přesně! A to nás přivádí k první a nejdůležitější vlastnosti transakcí. Říká se jí atomičnost. Představ si, že chceš převést tisíc korun. Co se musí stát?

Martin: No... z mého účtu se musí odečíst tisícovka a na účet kamaráda se musí přičíst tisícovka. To jsou dvě operace.

Kristýna: Správně. A atomičnost zaručuje, že se buď stanou obě, nebo ani jedna. Kdyby systém spadl poté, co se ti peníze odečetly, ale ještě předtím, než se připsaly kamarádovi... to by byl problém, že?

Martin: To by byl velký problém! Ztratil bych peníze a on by je nedostal.

Kristýna: A právě proto je tu transakce. Pokud se jakákoliv její část nepovede, celá transakce se vrátí zpět. Tomu se říká ROLLBACK. Databáze se uvede do stavu, v jakém byla PŘED začátkem transakce. Jako by se to nikdy nestalo.

Martin: Takže transakce je taková pojistka, která udržuje databázi v konzistentním, tedy správném a logickém, stavu. Převede ji z jednoho dobrého stavu do dalšího dobrého stavu.

Kristýna: Přesně. Konzistence je klíčová. Bez ní by v datech byl chaos.

Martin: Dobře, atomičnost chápu. Všechno, nebo nic. Co dál? Jaké další superschopnosti transakce mají?

Kristýna: Superschopnosti, to se mi líbí. Další je izolovaná vratnost, neboli izolace. To znamená, že jedna probíhající transakce nevidí nepořádek, který dělá jiná, souběžně běžící transakce.

Martin: Jak to myslíš, nepořádek?

Kristýna: Představ si, že dvě transakce pracují se stejnými daty. Kdyby jedna viděla do rozpracovaných, ještě nepotvrzených změn té druhé, mohla by pracovat se špatnými, dočasnými daty. Izolace zajistí, že každá transakce má pocit, že je v databázi sama.

Martin: Aha, takže si navzájem nelezou do zelí. A co se stane, když se jedna transakce musí vrátit zpět, tedy udělat ten ROLLBACK? Neovlivní to ty ostatní?

Kristýna: V ideálním světě ne. Ale pokud by jedna transakce pracovala s daty, která jiná transakce změnila a pak vrátila, musela by se vrátit i ta první. Tomu se říká řetězové vrácení nebo dominový efekt. Je to něco, čemu se systémy snaží zabránit.

Martin: Dominový efekt zní... draze.

Kristýna: Může být. Třetí vlastností je pernamentnost, nebo anglicky durability. To je jednoduché – jakmile je transakce úspěšně dokončena a potvrzena příkazem COMMIT, její změny jsou v databázi uloženy natrvalo. Přežijí i výpadek proudu nebo restart serveru.

Martin: Takže COMMIT je to finální razítko: „Hotovo, uloženo navždy.“

Kristýna: Přesně tak. A poslední vlastnost je uspořádatelnost, která je důležitá hlavně u distribuovaných databází. Zjednodušeně říká, že i když běží spousta transakcí najednou a proplétají se, výsledek musí být stejný, jako kdyby se provedly hezky jedna po druhé v nějakém pořadí.

Martin: Zmínila jsi distribuované databáze. To zní jako něco z Hvězdných válek. Co to je?

Kristýna: Je to vlastně docela běžné. Představ si velkou firmu s pobočkami po celém světě. Databáze není na jednom jediném superpočítači, ale je rozdělená na menší části, fragmenty, které jsou uložené na různých serverech, říkáme jim uzly.

Martin: Takže data z Prahy jsou na serveru v Praze a data z New Yorku na serveru v New Yorku?

Kristýna: Přesně. A teď si představ, že chceš udělat operaci, která se týká dat v obou městech. Například přesunout zaměstnance z Prahy do New Yorku. To je globální transakce.

Martin: Protože přesahuje jeden uzel.

Kristýna: Ano. A tato globální transakce se rozpadne na dílčí, lokální transakce. Jedna lokální transakce proběhne v Praze – odebere zaměstnance. Druhá v New Yorku – přidá ho. A musí to celé fungovat atomicky. Buď se povedou obě, nebo ani jedna.

Martin: A kdo to řídí? Musí tam být nějaký šéf, ne?

Kristýna: Samozřejmě. Uzel, ze kterého transakce startuje, se stává primárním uzlem. A tam běží takzvaná primární transakce, která koordinuje všechny ty dílčí části. Je to takový dirigent orchestru.

Martin: A ten dirigent má k ruce nějaké pomocníky?

Kristýna: Má. V každém uzlu je modul řízení transakcí, který analyzuje požadavky, rozděluje práci a pak skládá výsledky dohromady. A pak je tam modul řízení dat, který se stará o samotné čtení a zápis v lokální databázi.

Martin: Dobře, takže máme dirigenta – primární transakci – a orchestr lokálních transakcí. Jak ale dirigent zajistí, že všichni dohrají správně a ve stejný moment? Zvlášť když jsou třeba na druhé straně planety.

Kristýna: Skvělá otázka. Používá se k tomu něco, čemu se říká dvoufázový potvrzovací protokol. Zní to složitě, ale princip je elegantní. Funguje to ve dvou fázích.

Martin: Fáze jedna?

Kristýna: Fáze jedna je fáze hlasování. Primární transakce se zeptá všech dílčích transakcí: „Jste připraveny potvrdit změny? Dokončily jste svou práci a nevidíte žádný problém?“ Každá dílčí transakce provede svou práci, ale změny ještě finálně neuloží. Jen si je připraví a odpoví „Ano, jsem připravena“ nebo „Ne, nastala chyba“.

Martin: Takže si všichni jen připraví tužku nad papír, ale ještě nic nepodepíšou.

Kristýna: Přesně! A teď přichází fáze dvě – fáze rozhodnutí. Pokud VŠECHNY dílčí transakce odpověděly „Ano, jsem připravena“, primární transakce vyšle globální příkaz COMMIT. Teprve tehdy všichni najednou „podepíšou“ a změny trvale uloží.

Martin: A co když i jen jedna jediná odpoví „Ne“? Nebo neodpoví vůbec, protože třeba vypadl server?

Kristýna: Pak primární transakce vyšle globální příkaz ABORT. A všichni, i ti, co byli připraveni, své změny zahodí. Celá operace se vrátí zpět. Je to opravdu buď všichni, nebo nikdo.

Martin: To je docela robustní. Ale co se stane, když se přeruší spojení zrovna v té druhé fázi? Třeba lokální uzel čeká na povel a primární uzel spadne.

Kristýna: To jsou přesně ty nejzáludnější situace. Systémy na to mají mechanismy, jako je časový limit, takzvaný time out. Pokud odpověď nepřijde včas, transakce se preventivně zruší. Řešení těchto výpadků je jedna z nejsložitějších částí databázových systémů.

Martin: Mluvili jsme o tom, že transakce běží izolovaně, jako by byly v databázi samy. Ale ve skutečnosti nejsou. Jak systém zařídí, aby si dvě transakce, které chtějí změnit stejný řádek v tabulce, neskákaly do řeči?

Kristýna: Používá k tomu zámky. Je to jako klíč od zasedačky. Když chce transakce pracovat s nějakým objektem – třeba řádkem v tabulce – musí si ho nejdřív zamknout. Dokud ho neodemkne, nikdo jiný s ním nemůže pracovat.

Martin: To dává smysl. Takže když já chci změnit stav objednávky, zamknu si ji. A když se ji ve stejný moment pokusí změnit někdo jiný, jeho transakce musí počkat, až já skončím a odemknu.

Kristýna: Přesně. Tomu se říká dvoufázový uzamykací protokol. V první fázi si transakce zámky jen pořizuje, a ve druhé fázi je už jen uvolňuje. Ale co myslíš, že se může stát, když si dvě transakce chtějí zamknout více věcí navzájem?

Martin: Hm... Dejme tomu, že transakce A si zamkne objekt 1 a čeká na objekt 2. A transakce B si zamkne objekt 2 a čeká na objekt 1.

Kristýna: A máme tu problém! Každá čeká na tu druhou a ani jedna se nemůže pohnout z místa. Tomuto se říká uváznutí, anglicky deadlock.

Martin: Jako dva lidé, co se potkají v úzké uličce a každý čeká, až ten druhý uhne.

Kristýna: Perfektní přirovnání! A systém to musí umět rozpoznat. Dělá to pomocí takzvaných čekacích grafů. Transakce jsou uzly a šipka od A k B znamená „A čeká na B“. Pokud v tom grafu vznikne kružnice – A čeká na B, B čeká na A – máme uváznutí.

Martin: A co s tím systém udělá? Musí jednoho z těch dvou lidí v uličce odstrčit, že?

Kristýna: Přesně. Jednu z transakcí prostě „zastřelí“. To znamená, že ji přeruší, provede ROLLBACK jejích změn a uvolní její zámky. Tím se kruh přeruší a druhá transakce může pokračovat. Ta zrušená se pak obvykle zkusí provést znovu.

Martin: Takže systém nechá uváznutí stát a pak ho řeší. Nešlo by mu nějak předejít?

Kristýna: Jde. Je to jiná strategie. Místo detekce a řešení se můžeme snažit uváznutí vyhnout. Jednou z populárních metod jsou časová razítka. Každá transakce při svém startu dostane unikátní časové razítko – v podstatě číslo, které říká, kdy začala. Čím menší číslo, tím „starší“ transakce.

Martin: A k čemu je to dobré?

Kristýna: Když dojde ke konfliktu o zámek, systém se podívá na jejich časová razítka a rozhodne se podle předem daných pravidel. Existují dvě hlavní metody: „Wait-Die“ a „Wound-Wait“.

Martin: Počkej-Zemři a Zraň-Čekej? To zní drsně.

Kristýna: Názvy jsou dramatické, ale principy logické. U „Wait-Die“ platí: pokud starší transakce chce zámek, který drží mladší transakce, tak starší čeká (Wait). Ale pokud mladší transakce chce zámek od starší, tak mladší je okamžitě ukončena (Die) a musí to zkusit znovu později.

Martin: Takže mladší ustupují starším. To je slušné.

Kristýna: Přesně tak. A u „Wound-Wait“ je to naopak aktivní ze strany té starší. Pokud starší transakce chce zámek, který drží mladší, tak tu mladší „zraní“ (Wound) – tedy donutí ji k ROLLBACKu – a zámek si vezme. Pokud mladší chce zámek od starší, musí pokorně čekat (Wait).

Martin: V obou případech má starší transakce přednost. Jen se liší, kdo je aktivní. Chápu.

Martin: Dobře, teorii máme. Ale jak to vypadá v praxi? Když píšu kód, jak řeknu databázi: „Hele, teď začíná transakce a tady končí“?

Kristýna: Je to jednodušší, než si myslíš. V jazyce SQL, který se používá pro komunikaci s většinou databází, transakce často začíná automaticky prvním příkazem, který mění data.

Martin: A jak ji ukončím?

Kristýna: Máš dvě možnosti. Pokud všechno proběhlo v pořádku a chceš změny trvale uložit, napíšeš na konec příkaz COMMIT.

Martin: To je to finální razítko, o kterém jsme mluvili.

Kristýna: Ano. A pokud se něco pokazilo nebo chceš z nějakého důvodu všechny změny od začátku transakce zrušit, použiješ příkaz ROLLBACK.

Martin: Takže buď COMMIT, nebo ROLLBACK. Všechno, nebo nic. Zase se k tomu vracíme.

Kristýna: Přesně. Existuje ještě jedna užitečná věc, a to je SAVEPOINT. Během dlouhé transakce si můžeš vytvořit takové záchytné body. Můžeš napsat SAVEPOINT muj_bod;. A když pak uděláš ROLLBACK TO muj_bod;, nevrátí se celá transakce, ale jen změny provedené po tomto bodu.

Martin: To je jako ukládání pozice ve videohře! Když udělám chybu, nemusím začínat úplně od začátku, ale jen od posledního checkpointu.

Kristýna: To je naprosto dokonalá analogie! Přesně tak to funguje. Je ale důležité vědět, že ROLLBACK k savepointu neuvolňuje takzvané žurnály, tedy logovací soubory. Jen úplný ROLLBACK je vyčistí.

Martin: Zmínila jsi žurnály. To jsou ty soubory, kam si databáze zapisuje, co se děje, pro případ výpadku?

Kristýna: Ano. Žurnál, neboli log, je naprosto klíčový pro zotavení. Je to v podstatě deníček, kam si databáze pečlivě zapisuje každý krok každé transakce: kdy začala, jaká data mění – starou i novou hodnotu – a kdy skončila, ať už příkazem COMMIT nebo ABORT.

Martin: Takže když spadne server a pak se znovu nahodí, první co udělá, je, že si přečte tenhle deníček?

Kristýna: Přesně tak. Podívá se do něj a zjistí, které transakce byly v momentě pádu rozpracované. Používá k tomu takzvaný UNDO/REDO algoritmus. Vytvoří si dva seznamy: UNDO list a REDO list.

Martin: Co na těch seznamech je?

Kristýna: Na REDO list dá všechny transakce, které stihly provést COMMIT před pádem, ale jejichž změny se možná ještě nestihly fyzicky zapsat na disk. Tyto transakce systém provede znovu (REDO), aby měl jistotu, že jsou data kompletní.

Martin: A na UNDO list?

Kristýna: Tam přijdou všechny transakce, které v momentě pádu nebyly dokončené. U nich systém vezme všechny jejich provedené změny a vrátí je jednu po druhé zpátky (UNDO). Tím zajistí, že v databázi nezůstane žádná polovičatá, nekonzistentní práce.

Martin: Takže díky žurnálu dokáže systém po katastrofě databázi uklidit a vrátit ji do posledního známého správného stavu. To je fascinující.

Kristýna: Je to základní kámen spolehlivosti databází. Bez toho by to prostě nefungovalo.

Martin: Páni, Kristýno, to byla spousta informací. Zkusme to na závěr proletět. Transakce je skupina operací, která se provede jako jeden celek – buď všechno, nebo nic. Tomu se říká atomičnost.

Kristýna: Správně. Dále musí být izolovaná, aby si souběžné transakce neplezly do cesty. Její výsledky musí být po potvrzení (COMMIT) trvalé, a výsledek souběžného zpracování musí odpovídat nějakému sériovému provedení.

Martin: U distribuovaných databází máme globální transakce, které řídí ty lokální pomocí dvoufázového potvrzení. A aby si transakce nezasahovaly do stejných dat, používají zámky.

Kristýna: Což může vést k uváznutí (deadlocku), které systém buď detekuje a řeší, nebo se mu snaží vyhnout pomocí časových razítek.

Martin: A v SQL všechno řídíme hlavně příkazy COMMIT pro trvalé uložení a ROLLBACK pro zrušení změn. A pro případ katastrofy má databáze žurnál, podle kterého se umí zotavit.

Kristýna: Perfektní shrnutí! Zvládl jsi to na jedničku. Myslím, že teď už je každému jasné, proč jsou transakce tak nepostradatelné.

Martin: Rozhodně. Díky moc, Kristýno, za skvělé vysvětlení. A děkujeme i vám, že jste poslouchali Studyfi Podcast. U dalšího dílu se těšíme na slyšenou!

Kristýna: Na slyšenou!