Řízení paralelního zpracování: Porovnání verzí

m
Typografie
(přidány nějaké odkazy na jiné wikičlánky)
m (Typografie)
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.
 
=== Hlavní cíle mechanizmů kontroly souběžnosti ===
 
To má řadu výhod, jako
# 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.
# Snižuje se cena komunikace vhodným rozmístěním dat v uzlech.(data, která uzel používá má lokálně k dispozici).
# Větší spolehlivost a tolerance k chybám (zotavení po chybách díky replikám), možnost zálohování počítačů.
 
===== Paralelní zpracování v distribuovaných databázích =====
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í.
6 672

editací