![]() |
![]() |
Vlastnosti ACID
Již v dobách ranné historie databází v 70. letech bylo krédem databázových systémů, aby transakce nad jednou databází mohly být v uživatelských aplikačních programech prováděny paralelně. Cílem bylo lépe využít spolupráci různých zařízení, jako jsou např. procesor a periferie. Uvažujme 2 transakce s operacemi Tij. Předpokládejme transakce T1 a T2 dané posloupnostmi operací {T11,...,T1n}, resp. {T21,...,T2m}. Stanovené pořadí provádění operací více transakcí v čase nazveme rozvrhem. Obrázek 1 ukazuje několik možností, v jakém pořadí provádět dané operace. Všimněte si různých časů ukončení transakcí, které nejsou ve stejném pořadí jako začátky transakcí; to je způsobeno tím, že skutečný přenos dat na disk probíhal s jistým zpožděním v závislosti na modulu řízení souborů. Čas 1. možnost T11 ... T1n T21 ... T2m 2. možnost T21 .. . T2m T11 ... T1n 3. možnost T21... T11 ... T2k ... T1l ... Obr. 1 Rozvrhy pro provedení transakcí Pro charakterizaci různých přístupů k ke transakcím je vhodné zavést pojem transakčního modelu. Transakční model je obvykle charakterizován strukturou transakce a strukturou objektů, na kterých transakce operuje. Na základě transakčního modelu lze definovat jistá kritéria korektnosti, která např. umožní rozlišit “dobré” rozvrhy od “špatných” rozvrhů. Zatím intuitivně se představme problém na příkladu, kdy jedna transakce v rezervačním systému čte data o počtu rezervací, přestože jiná transakce je zrovna mění. Pak je nekorektnost v tom, že jedna transakce používá stará data, přestože existují nová (ale nepotvrzená k použití ostatními uživateli systému). Struktura objektů Objekty, na kterých operuje transakce jsou (podle zvyšující se složitosti) buď jednoduché objekty jako soubory, stránky, záznamy, nebo objekty jako instance abstraktních datových typů (ADT), složité objekty (jak je dnes nabízí např. objektově orientovaný přístup), a konečně tzv. aktivní objekty. Současné systémy pro zpracování transakcí (SZT) pracují hlavně s jednoduchými objekty, většinou s fyzickými stránkami. Použití záznamu (n-tice) jako jednotky zpracování již může vést k vysoké režii. Podstatné na tomto druhu objektů je, že se nebere v úvahu jejich sémantika. Aktualizace stránky je např. uvažována bez ohledu na to, jaký logický objekt se na ní nachází. Použití ADT znamená použití abstraktních operací svázaných s objekty. Nejde o pouhé operace READ a WRITE. Takovými “vyššími” operacemi mohou být např. INSERT, DELETE UPDATE v SQL, tj. nad relacemi, což vede k víceúrovňovým mechanismům zpracování transakcí. INSERT n-tice do relace znamená jistou aktualizaci fyzické stránky. Kritéria korektnosti musí být aplikována na každé úrovni zvlášť. Složité objekty objektově orientovaných SŘBD představují objekty se strukturou, jejíž komponentou může být opět objekt. To vede k tomu, že transakce na objektu může vyvolat implicitní hnízdění transakcí, tj. volání transakcí na podobjektech. Aktivní (a pasivní) objekty patří tzv. aktivním databázím. V těchto databázích se monitorují události a popisují podmínky, za kterých dochází ke spouštění jistých akcí při výskytu takových událostí. Volání akce znamená volání jisté (hnízděné) transakce. Struktura transakce Přes problematické otázky, jak vůbec klasifikovat přístupy k modelování transakcí, rozlišují se dnes čtyři kategorie transakcí podle zvyšující se složitosti. Jedná se o tzv. ploché transakce, uzavřené hnízděné transakce, otevřené hnízděné transakce a pracovní toky (workflows). Uvážíme 4 možnosti struktury objektů, obdržíme 16 možností - kategorií transakčních modelů, z nichž některé ještě nebyly ani v praxi ani v teorii zkoumány. Ploché transakce splývají vlastně s původním pojmem transakce, tak jak byl vyvinut v polovině 70. let. Tyto transakce mají jednoduchý bod startu (Begin_transaction) a jednoduchý bod ukončení (End_transaction). Většina SZT v databázích se v minulosti zaměřovala právě na tento model použitý na jednoduchých objektech. Tyto systémy používají většinou za kritérium korektnosti uspořádatelnost rozvrhů (bude tématem samostatného dílu Databázové abecedy). Hnízděné transakce zahrnují další transakce se svými body startu a ukončení. Příkladem takové transakce může být objednávka rezervace prostředků pro služební cestu, zahrnující jednak rezervaci letenky, dále hotelu, ale i pronájmu auta po dobu pobytu v hotelu. Rozlišují se uzavřené a otevřené hnízděné transakce. Uzavřené odpovídají klasickému zpracování transakcí v distribuovaných systémech. Potvrzování podtransakcí se děje zdola-nahoru, tj. sémantika podtransakcí přispívá k atomicitě kořenové transakce. Pro tyto modely existují mnohdy kritéria korektnosti, která umožňují poskytnout i částečné výsledky jiným transakcím. Otevřené hnízdění uvolňuje požadavek na atomicitu kořenové transakce. Částečné výsledky mohou být viditelné mimo transakci, která je pořizuje. Tak např. sága je posloupnost transakcí, které mohou být proloženy jinými transakcemi. SŘBD zajišťuje, že všechny transakce v sáze jsou provedeny nebo se rozběhnou kompenzující transakce pro zotavení. Dovoleny jsou pouze dvě úrovně hnízdění a na vnější úrovni není podporována atomicita. Navíc, podtransakce tvořící ságu musí být provedeny sekvenčně. Dnes zřejmě největším problémem SZT jsou tzv. dlouhotrvající transakce. Původní pojem transakce vyvinutý krátkých bankovních operacích (přenosy z účtu na účet, jednoduché aktualizace) již pro některé aplikace nestačí. Představme si cestovní agenturu a již zmíněnou transakci - zajišťování prostředků pro služební cestu zákazníka. Např. po zajištění letenky, je nutné vstoupit do různých externích databází hotelů, případně půjčoven aut. Také získání dílčí letenky může ovlivnit již provedenou rezervaci předchozí letenky, tj. její zrušení. Zajištění kompletní transakce může být dlouhodobé, transakční mechanismus musí odrážet typické způsoby, jakými je prováděn obchod v praxi. Projektování takovýchto transakcí a jejich implementace vedly k pojmu pracovních toků a systémů řízení pracovních toků. Pracovní toky jsou modelovány pomocí aktivit, úkolů, z hlediska transakčního zpracování pomocí uzavřených transakcí. Pojem transakce v těchto systémech doznal značných změn a zobecnění. Uvažujme podrobněji případ, kdy struktura transakce je plochá, přičemž objekty budou ty nejjednodušší možné, tj. nepůjde ani o řádky relací, nýbrž o atributy (položky), bez ohledu na to, jak jsou ve skutečnosti implementovány. Používanými operacemi budou:
Nezáleží-li na použitých proměnných, budeme psát READ(X) a WRITE(X). Všimněme si, že operace OUTPUT(X) se v těchto operacích neuvažuje. Neprovádí se totiž bezprostředně po provedení WRITE. Z toho plyne, zhroutí-li se systém po WRITE(X) před provedením OUTPUT(X), je nová hodnota X ztracena. V souvislosti s pojmem transakce se obvykle hovoří o vlastnostech ACID. Jde o první písmena angl. slov atomicity, consistency, independence (nebo isolation) a durability. Transakce splňující vlastnosti ACID, musí splňovat čtyři dílčí vlastnosti:
Podle Haerdera a Reutera z r. 1983 tyto vlastnosti představují základní princip v transakčním zpracování. Někdy se také hovoří a testu ACID pro transakce. Jde ovšem o vlastnosti, které nejsou nezávislé. Atomicita, jak jsme viděli, znamená buď všechno nebo nic. Transakce buduje větší jednotku zpracování z menších atomických operací. Údržba atomicity transakce se nazývá zotavení z chyb. Jedná se např. o vydání příkazu RALLBACK po chybě dat, po uváznutí apod., nebo provedení jistých akcí po chybě systému. Existuje konzistence individuálních transakcí (viz pojmem transakce) a konzistence databáze pod paralelním voláním transakcí. V prvním případě považuje SZT transakci za konzistentní a spoléhá na kontrolu integritních omezení, která jsou zajišťována jistou částí SŘBD. V druhém případě používá kritéria korektnosti (protokoly), která jsou obsažena v algoritmech provádějících paralelní zpracování. Nezávislost či izolace je vlastnost transakcí, která požaduje, aby transakce vždy viděla konzistentní databázi. Jinými slovy řečeno, běžící transakce nemůže zjevit své výsledky ostatním transakcím, pokud je nepotvrdí. Dalším důvodem pro izolaci souvisí s tzv. dominovým efektem. Problémy s paralelním prováděním transakcí je v reálných systémech totiž nutné kombinovat s problémy týkajícími se zotavení z chyb. Řeší se otázka, které transakce provádět znovu v případě jejich vzájemné závislostí podle sdílených objektů. Např. transakce T, U, V pracují paralelně na objektu Q, přičemž T mění tento objekt. Dostane-li se transakce T do chybného stavu a je zrušena, musí být zrušeny i transakce U a V (měly přečtenou nesprávnou hodnotu objektu Q). Tomuto jevu se říká kaskádové rušení transakcí nebo též dominový efekt. Je zřejmé, že pojem izolace je přímo vztažen ke konzistenci databáze a tedy k paralelnímu zpracování. Trvanlivost znamená, že jakmile transakce vydá potvrzení výsledků, pak výsledky jsou trvalé a nemohou být vymazány z databáze, tj. je dosažena atomicita vzhledem k chybám. Postupem doby se ACID vlastnosti vyvíjely, protože se (zvláště v souvislosti s novými aplikacemi databázové technologie) ukázaly poněkud omezující. Moderní přístupy ke transakcím vlastně znamenají jisté uvolňování omezení, které ACID vlastnosti implikují ve prospěch pružnějšího provozu transakcí. <seznam dílů seriálu> <COMPUTERWORLD> |