Řízení paralelního zpracování

V aplikacích se používá pojem transakce, což je skupina operací prováděných nad databází. Transakce musí splňovat vlastnosti ACID:

• Atomicity (nedělitelnost) – transakce se tváří jako jeden celek, tedy je vykonána celá, nebo vůbec
• Consistency (konzistence) – transakce může měnit databázi pouze z jednoho konzistentního stavu do druhého konzistentního stavu
• Isolation (izolace) – transakce je izolovaná od probíhajících změn (jsou viditelné pouze potvrzené (commited) změny), tj. dílčí efekty transakce nejsou viditelné ostatním
• Durability (trvanlivost) – změny v databázi provedené potvrzenou transakcí musí být trvanlivé

Proč vlastně kontrola souběžnosti transakcí? V případě kdy běží několik transakcí současně, může se stát, že tyto transakce mění tentýž databázový záznam. Pokud by tento souběžný běh transakcí nebyl kontrolován, mohl by nastat problém, jakým je nekonzistentní databáze. Proto v další části popíšeme tři problémy, které mohou nastat při nekontrolovaném běhu souběžných transakcí.

Tento problém nastane v případě, kdy dvě transakce přistupující ke stejnému záznamu v databázi a po jejich ukončení je hodnota v záznamu nesprávná.

Ten nastane v případě, kdy jedna transakce mění záznam v databázi a poté skončí chybou. Ke změněnému záznamu přistupuje jiná transakce dřív, než dojde k vrácení původní hodnoty.

Dalším problémem, který může nastat při nekontrolovaném spouštění souběžných transakcí je, pokud jedna transakce počítá součet hodnot a během tohoto výpočtu druhá transakce provádí změny některých těchto hodnot používaných ve výpočtu transakce první. Funkce může počítat s některými hodnotami před tím, než jsou změněny a s některými až po změně, tedy výsledek funkce není správný.

Protokoly kontroly souběžnosti se používají k omezení spouštění souběžných transakcí v centralizovaném databázovém systému a v distribuovaném pouze k serializovatelnému spouštění.

Protokoly kontroly souběžnosti se dělí na dvě kategorie:

• pesimistické
• optimistické

U těchto protokolů dochází ke kontrole před tím, než je databázová operace provedena. Tedy předchází nekonzistencím zamítnutím potenciálních neserializovatelných spouštění a zajištěním, že výsledek potvrzených transakcí musí být zaznamenán do databáze nebo anulován.

Příkladem tohoto protokolu je komerčně široce používaný Dvoufázový uzamykací protokol a dále Uspořádání podle časových razítek.

U těchto protokolů nedochází ke kontrolám v době běhu transakce, a tedy dovolují neserializovatené spouštění. Prováděné změny nejsou hned aplikovány přímo v databázi, ale v lokání paměti. Na konci běhu transakce validační fáze zkontroluje, zda změny prováděné transakcí nejsou v rozporu se serializovatelností. Pokud ne, transakce se potvrdí a změny se promítnou do databáze, jinak je ukončena a spuštěna později. Tedy transakce s detekovanými anomáliemi jsou ukončeny během validační fáze před tím, než je výsledek transakce zviditelněn.

Existuje mnoho metod řízení souběžnosti, tyto metody mají mnoho variant a v některých případech se mohou i překrývat a kombinovat.

• Zamykání – Jedna z nejzákladnějších technik pro řízení běhu souběžných transakcí je založená na zamykání databázového záznamu. Zámek je proměnná asociovaná s datovým záznamem, která vyjadřuje status záznamu s ohledem na možné operace, která mohou být nad záznamem použity. Pro zamykání je možné použít několik typů zámků.

• Časová razítka (Time Stamps) – Další technikou pro řízení souběžného běhu transakcí a zajištění serializovatelnosti transakcí je používání časových razítek. Časové razítko je jedinečný identifikátor, který je přiřazen transakci. Typicky je časovým razítkem hodnota, která odpovídá pořadí spuštění transakce v systému, nebo čas nastartování transakce.

Jiné hlavní typy kontroly shodnosti, které jsou využívány ve spojení s výše uvedenými metodami jsou:

• Multiversion concurrency kontrol – Dalším protokolem pro řízení konkurenčního běhu transakcí, který může také používat koncept časových razítek, udržuje staré hodnoty dat, když jsou tato data měněna. Tento způsob je znám jako Multiversion concurrency control., protože je udržováno několik verzí hodnot dat. Když transakce požaduje přístup k záznamu, časové razítko transakce je porovnáno s časovými razítky různých verzí záznamu. Příslušná hodnota je vybrána, aby byla udržena serializovatelnost právě spuštěného rozvrhu, pokud je možná.

• Timestamp ordering (uspořádání podle časových razítek) – Tato metoda je založena na uspořádání transakcí podle časových razítek. Rozvrh, ve kterém transakce se účastní, je pak serializovatelný a ekvivalentní sériový rozvrh má transakce uspořádány podle časových razítek. Na rozdíl od dvoufázového zamykání, kde je rozvrh serializovatelný tím, že je ekvivalentní nějakému sériovému rozvrhu, který povoluje zamykání, je u uspořádání časových razítek rozvrh ekvivalentní konkrétnímu sériovému uspořádání odpovídajícímu uspořádání podle časových razítek.

Za prvé je nutné u každé transakce udržovat integritu pravidel, zatímco transakce běží souběžně a tím i integritu celého systému. Dále je potřeba dosahovat potřebného výkonu. Další subjekty, které mohou mít vliv na řízení souběžnosti jsou obnova a replikace.

Úroveň sériovosti zabraňuje všem interferencím mezi transakcemi stejným způsobem, jako by transakce byly prováděny postupně a nikoliv souběžně. Ostatní transakce sice mohou číst data ze zpracovávaných tabulek, ale nemohou je měnit ani přidávat nové údaje. Z důvodu značného blokování ostatních transakcí je vhodné používat tuto úroveň izolace pouze v nezbytných případech (např. přecenění skladu, účetní uzávěrka). Různé databázové platformy mohou pro jednotlivé izolační úrovně používat odlišné názvy (nebo i stejné ale v jiném významu), případně nemusí podporovat všechny úrovně definované standardem, a lišit se může i dopad jednotlivých úrovní na propustnost transakcí. Je tedy vždy nezbytné prostudovat dokumentaci konkrétního produktu.

Poznámka: Zatím co v oblasti systémů termín obnovitelnost, může odkazovat na schopnost systému obnovit se ze stavu selhání nebo z nesprávného/zakázaného stavu, v rámci řízení souběžnosti databázových systémů tento termín získal specifický význam. V každém SŘBD jsou moduly řízeni souběžného zpracování a zotaveni po poruše, které každému uživateli poskytuji data v konzistentním stavu databáze (vyhovuji všem integritním omezením ve schématu databáze), i když se stejnými daty paralelně pracuje několik uživatelů nebo došlo k poruše či chybě v softwaru, hardwaru, výpadku napájení atd..

Transakce je posloupnost akci nebo specifikace operací (jako jsou čteni a zápis dat, výpočty), které se buď provedou všechny, nebo se neprovedou vůbec. Z hlediska aplikace je to logická i programová jednotka práce, odpovídající nějakému procesu v realitě. Př.: Převod peněz z jednoho učtu na jiný při platbě faktury. Její provádění je zabezpečeno a řízeno tak, že jsou splněny následující podmínky. Při čtení potřebných dat musí byt databáze konzistentní, během operaci transakce je dočasně i v nekonzistentním stavu, ale nakonec při potvrzeni transakce musí byt databáze opět konzistentní. Po výpadku se databáze uvede do stavu na počátku transakce. Aby systém mohl splnit tyto úkoly, udržuje vlastními prostředky historii změn dat v přiměřeném časovém intervalu v žurnálu (log file).

Technické možnosti komunikačních systémů a vzájemného propojování počítačů umožňují spojovat i původně samostatně pracující počítače do distribuovaných systémů. Speciálně u Distribuovaných databázových systémů (DDBS) se s komunikační technologií spojí databáze. Obecná charakteristika systémů:

• Tvoří je množina uzlů (míst), propojených komunikačními kanály
• Každý uzel je autonomní SŘBD, ve všech službách se nespoléhá na centrální uzel
• Uživatel nic neví o síťové struktuře systému, ale systém umožní transparentně zpřístupnit data z libovolného uzlu a opačně zpracovává vlastní data pro distribuované dotazy ostatních. Práce jednoho uzlu nenarušuje celý systém, který nepřetržitě pracuje.
• Nezávislost na hardware, operačním systému, síti i SŘBD.

To má řadu výhod, jako

1. Vysoká efektivita zpracování a racionalizace provozu – data jsou umístěna v místech, kde jsou nejčastěji využívána, vyšší výkonnost – zátěž zpracování je díky paralelismu rozdělena na více počítačů, větší dostupnost – možnost sdílení společných informačních fondů, DDBS se snadno škáluje – rozšíření konfigurace.
2. Snižuje se cena komunikace vhodným rozmístěním dat v uzlech.(data, která uzel používá má lokálně k dispozici).
3. Větší spolehlivost a tolerance k chybám (zotavení po chybách díky replikám), možnost zálohování počítačů.

Ale i nevýhod

1. Větší složitost – návrhu databáze, katalogu dat a jeho správy, transakčního zpracování s problémy uváznutí, optimalizaci dotazů, územní distribucí dat, šíření aktualizace při replikaci, heterogennost dat na jednotlivých uzlech vede k transformacím, komunikace v počítačových sítích – minimalizace počtu a velikost zpráv, výpadky.
2. Obtížnější dosazení bezpečnosti a utajení.
3. Distribuce řízení.
4. Relativní nedostatek standardů, nástrojů a zkušeností.

Jsou to komplikované a vzájemně propojené problémy a dosavadní distribuované báze jsou prozatím jen unikátními řešeními. Dosud neexistuje obecný model či návod pro jejich tvorbu. Jednotné řízení distribuované báze může být realizováno různými formami na různém stupni centralizace řízení. Důležitou vlastností DDBS je to, že přes rozložení dat do jednotlivých uzlů sítě se jeví celá distribuovaná báze uživateli tak, jako by byla lokální. Distribuce je uživateli skryta a z hlediska jeho potřeb není podstatná. Celá distribuovaná báze dat je popsána v globálním schématu DDBS. To je popis báze nezávislý na distribuci dat a stejný pro všechny uživatele ve všech uzlech sítě. Nejčastěji je globální schéma popsáno pomocí relačního modelu dat.

Zajišťování atomického charakteru transakcí v distribuované bázi je řádově složitější, než u lokálních sítí, protože možné poruchy jsou mnohem složitější. V centralizovaných DDBS řídí pořadí vykonávání operací jediný plánovač umístěný v centru DDBS. protože plánovač má kontrolu nad všemi daty v DDBS, mohou se bez problémů použít typy plánovačů pro klasické SŘBD. Připomeňme, že každá transakce může číst a měnit hodnoty objektů v libovolných lokálních bázích dat. Proto případné zrušení transakce, například při distribuovaném uváznutí, je spojeno s většími problémy. Zrušená transakce musí vrátit původní hodnoty objektům, které již změnila. V distribuované bázi to může být zdlouhavá a nákladná operace, proto budou výhodnější takové plánovače, které pracují bez rušení transakcí. U plánovačů pracujících s časovými razítky je nutno sladit lokální hodiny – tak, aby časová razítka byla navzájem různá, i když pocházejí z různých uzlů. V případě decentralizovaných DDBS jsou plánovače v každém lokálním SŘBD. I v decentralizovaných DDBS je možno použít typy plánovačů z klasických SŘBD. Při zamykání objektů zamyká a odemyká Každý lokální plánovač objekty ve své bázi. Problémem je ale kontrola korektního dodržování dvoufázového protokolu zamykání. Řešením může být pozdržení odemknutí všech objektů zamknutých pro transakci, dokud transakce neskončí a pak vyslat všem plánovačům zprávu o skončení transakce. Pak je možno objekty uvolnit. Hojně využívanou možností je použití protokolu s dvoufázovým potvrzením. Předpokladem je autonomní činnost uzlů s použitím lokálních žurnálů pro případné použití operací ROLLBACK. Jeden z uzlů převezme roli koordinátora a určuje, kdy je transakce potvrzena nebo odmítnuta a navrácena do výchozího stavu. Komunikace probíhá prostřednictvím zasílání zpráv mezi koordinátorem a ostatními uzly. V první fázi koordinátor pošle všem zúčastněným uzlům zprávu příprava na potvrzení T. Každý autonomní uzel se rozhodne, zda T potvrdí, nebo odmítne svou část T. Pokud potvrdí commit např. < Ready T>, nemůže již přejít do stavu abort. Jinak pošle zprávu < Do not commit T> . Druhá fáze začíná po získání všech odpovědí koordinátorem. Pokud odpovědi nedojdou v odhadnutém čase, předpokládá se zamítnutí. Koordinátor pošle zprávu < Commit T> nebo < Abort T> na všechny zúčastněné uzly. Následně uzly provedou požadovanou akci a informují koordinátora o provedení operace. V decentralizovaném systému se těžko zjišťuje uváznutí, to nemůže detekovat žádný lokální plánovač. Proto je výhodné uváznutím předcházet, např. použitím plánovačů pracujících s časovými razítky, kde k uváznutí nedochází.