UNICORN COLLEGE BAKALÁŘSKÁ PRÁCE

Transkript

1 UNICORN COLLEGE Katedra informačních technologií BAKALÁŘSKÁ PRÁCE Mechanismy konkurenčního přístupu v relačních databázových systémech Autor BP: Martin Vajsar Vedoucí BP: Mgr. Pavel Zeman 2018 Praha

2 UNrconN -cmm Katedra Informadnich technologii Akademichy' rok 2O1 7 / 20 1 I zadani BAKALAFsTE pnace Jm6no a piijmeni: Stud'rjnf program: Studijni obor: l{5zev pr6ce: Martin Vajsar Syst6mov6 inienfrstvi a informatika Informatni technologie Mechanismy konkureniniho plistupu v reladnich datab6zovfch syst6mech cil Reladnf datab6zov6 syst6my jsou velmi rnfznamnou tiidou databdzovjch syst6m0 v enterprise sf6ie. V tomto segmentu je samoziejmfm poiadavkem vet5iny aplikaci moznost konkureneniho plistupu k dat0m, a tojak pii dteni, tak i pii zdpisu dat. Dobr6 porozumeni mechanism0m zajistujlcim konkureneni plistup je nutn6 pro tvorbu spolehlivfch a vfkonnfch aplikaci nad datab6zovfmi syst6my. Cilem bakal5fuk6 pr6ceje provest rozbor problematiky konkurendniho piistupu v relatnich databdzovfch syst6mech, a tojak teoreticky, tak i v konkr6tnich implementacich. V teoretick6 d6sti bude rozebr5na piedeviim relevantni d5st ANSI SQL standardu. Niisledni budou porovn5ny konkr6tni implementace mechanismi konkurendniho plistupu v nekolika vybranfch vfznamnfch rela[nich datab5zovjch syst6mech (napi. Oracle, MS SQL ServeI PostgreSQL). Konkr6tni aspektyjednotlivjch implementaci budou ilustrov6ny na praktickfch ukrizksch. Vzhledem k rostoucimu u-iznamu nerelaenich datab6zovjch syst6mri (tzv.,,nosql datab6ze") budou mechanismy konkurendnlho piistupu pops6ny i pro nekter6 vybran6 NoSQL databiizov6 syst6my. v oblasti NoSQL databiizije cilem pouze z5kladni uvedeni do problematiky, teziste pr6ce z&st6v5 v oblasti reladnich datab5zovjch systdmtr. osnova 0vod 1. KonkurenEni piistup podle ANSI SQL standardu 2. Ziikladni mechanismy lizeni konkureniniho piistupu 2.1. ZamykSni 2.2. Multiversioning 3. Implementace ve vybranfch DB platform6ch 3.1. Oracle 3.2. MS SQL Server 3.3. PostgreSQL 4. Konkurendni piistup v NoSQL databiizich TixEr Piilohy

3 DOPORUdENA LITERATURA BERNSTEIN, Philip, HADZILACOS, Vassos, GOODMAN, Nathan: Concurrency Control and Recovery in Database Systems. Addison Wesley Publishing Company, O stran. ISBN SCIoRE, Edward: Database Design and Implementation. 1. vyd5ni, Wiley, stran. ISBN SIPPU, Seppo, SOISALON-SOININEN, E jas: Transaction Processing: Management ofthe Logical Database and its Underlying Physical Structure (Data-Centric Systems and Applications). Springe[ ISBN KYTE Thomas, KUHN, Darl: Expert Oracle Database Architecture. 3. vyd6ni, Apress, stran. ISBN ISSA, Tomayess, ISAiAS, Pedro: Artificial Intelligence Technologies and the Evolution ofweb vyd6ni, IGI Global, 2O stran. ISBN TIWARI, Shashank: Professional NoSQL. 1. vyd6ni, Wrox, 2O11.3a4 stran. ISBN A Vedouci bakal5isk6 pr5ce: Adresa pracoviste: Pavel Zeman V KapslovnE 2767/2, Praha 3 Datum zadsni bakalsisk6 p16ce: Termin odewd6ni bakalsisk6 prsce: 27.O V Praze dne ,7. doc. Ing. Jan dadil, Ph.D. Rektor Ut* rcorqru -Correcn

4 Čestné prohlášení Prohlašuji, že jsem svou bakalářskou práci na téma Mechanismy konkurenčního přístupu v relačních databázových systémech vypracoval samostatně pod vedením vedoucího bakalářské práce a s použitím výhradně odborné literatury a dalších informačních zdrojů, které jsou v práci citovány a jsou také uvedeny v seznamu literatury a použitých zdrojů. Jako autor této bakalářské práce dále prohlašuji, že v souvislosti s jejím vytvořením jsem neporušil autorská práva třetích osob a jsem si plně vědom následků porušení ustanovení 11 a následujících autorského zákona č. 121/2000 Sb. V... dne (Martin Vajsar)

5 Poděkování Děkuji vedoucímu bakalářské práce Mgr. Pavlu Zemanovi za účinnou metodickou, pedagogickou a odbornou pomoc a další cenné rady při zpracování mé bakalářské práce.

6 Mechanismy konkurenčního přístupu v relačních databázových systémech Concurrency control mechanisms in relational database systems 6

7 Abstrakt Cílem této práce je provedení rozboru problematiky konkurenčního přístupu v relačních databázových systémech, a to i v konkrétních implementacích vybraných RDBM systémů. Okrajově a zejména na teoretické úrovni je tato problematika pojednána i v oblasti vybraných NoSQL databázových systémů. Hlavní náplní práce je nalezení konkrétních databázových operací, jejichž chování se liší v důsledku rozdílné implementace mechanismů konkurenčního přístupu jednotlivých systémů. V práci se podařilo prokázat, že s rostoucí složitostí a náročností implementovaných systémů se vazba na konkrétní použitou databázi stává ve většině případů těsnější. Hlavním přínosem práce je srovnání vybraných RDBM systémů a zhodnocení jejich zaměnitelnosti v rozsáhlých enterprise aplikacích. Klíčová slova: RDBMS, ACID, konkurenční přístup, izolace transakcí, MS SQL Server, MySQL, Oracle, PostgreSQL. Abstract The aim of this study is to analyze the issue of concurrent access in relational database systems, including specific implementations of selected RDBM systems. Marginally, and mostly at the theoretical level, the issue is also discussed in selected NoSQL databases. The main goal is to identify specific database operations whose behavior diverges across implementations due to the differing mechanisms of concurrent access in individual database systems. I was able to show that the dependency on a specific database in most cases grows stronger with the increasing complexity of the implemented enterprise system. The main contribution of this work lies in comparison of selected RDBM systems and evaluation of their interchangeability in large enterprise applications. Keywords: RDBMS, ACID, concurrency control, transaction isolation, MS SQL Server, MySQL, Oracle, PostgreSQL. 7

8 Obsah Úvod 9 1 Konkurenční přístup podle ANSI SQL standardu 11 2 Základní mechanismy řízení konkurenčního přístupu Teorie serializovatelnosti Konzervativní a agresivní protokoly Uzamykací protokol Multiverzní protokoly Implementace ve vybraných DB platformách Historie vývoje mechanismů konkurenčního přístupu MS SQL Server MySQL Oracle PostgreSQL Porovnání vybraných DB platforem Úrovně izolace Explicitní uzamykání Shrnutí Konkurenční přístup v NoSQL databázích Distribuční modely Konzistence operací Stručný popis vybraných platforem Závěr 63 Seznam literatury 64 Seznam obrázků 67 Seznam tabulek 68 Seznam příkladů 69 A Doplňující informace k implementaci databázových systémů 70 A.1 MS SQL Server A.2 Oracle

9 Úvod Relační databázové systémy dnes představují vyspělou, robustní technologii, která od svého vzniku prošla výraznými změnami z hlediska implementace i způsobu užívání. Postupná unifikace a standardizace databází a zejména jazyka SQL obsažená v ANSI standardu umožnila výraznou abstrakci detailů implementace databázových systémů. Databázové drivery zajišťují jednotný přístup k databázím bez ohledu na konkrétní komunikační protokoly a do určité míry skrývají i některé syntaktické odlišnosti, například ve volání uložených procedur. Sofistikovanější nadstavby, jako jsou ORM frameworky, odstiňují uživatele od zbývajících syntaktických odlišností jednotlivých dialektů jazyka SQL i od některých implementačních detailů, které jsou často přenášeny až na aplikační úroveň například generování hodnot primárních klíčů. Významným cílem této abstrakce je dosažení databázové přenositelnosti, kdy aplikace může být provozována nad různými databázovými systémy s minimálními nebo nejlépe žádnými úpravami. Na druhou stranu tento přístup obvykle znemožňuje využití všech funkcionalit i dosažení maximálního možného výkonu cílové databáze. V některých aplikacích, zejména rozsáhlých aplikacích s vysokými nároky na výkon, není tedy možné takový přístup použít. Existuje však řada aplikací, pro které jsou uvedená omezení přijatelnou cenou za dosaženou zaměnitelnost databázových systémů. Bohužel ne všechny implementační detaily jednotlivých databází lze tímto přístupem odstínit. Jeden z mechanismů, který nemůže být rozumným způsobem abstrahován, je mechanismus zajišťující izolaci probíhajících databázových transakcí ve víceuživatelském prostředí. ANSI SQL standard definuje několik různých úrovní izolace, které určují, do jaké míry se mohou v transakci prováděné jedním uživatelem projevovat operace prováděné ve stejnou dobu ostatními uživateli databáze. Konkrétní způsob implementace však předepsán není a různé databázové systémy používají pro dosažení kompatibility se standardem různé prostředky. Jak bude ukázáno v následujících kapitolách, tyto odlišnosti mezi jednotlivými databázovými systémy prostupují skrze všechny úrovně abstrakce a způsobují rozdílné chování aplikace na rozdílných databázových systémech. Závažnost těchto rozdílů se přitom může pohybovat od mírné, kdy se pouze ve větší či menší míře liší výkon aplikace na různých platformách, až po závažné, kdy na některých platformách může dojít k nepřijatelnému snížení výkonu, nebo dokonce k chybné funkci aplikace. Je tedy zřejmé, že pro vývoj aplikací nezávislých na databázi je paradoxně nutné dobře porozumět právě těm mechanismům, od kterých se uživatele snaží jednotlivé frameworky odstínit. Cílem této práce je proto popsat problematiku konkurenčního přístupu (zejména izolace transakcí) a podat přehled konkrétních mechanismů, kterými se zajištění izolace transakcí nejčastěji provádí. Dále jsou popsány implementace těchto mechanismů ve čtyřech databázových platformách (Microsoft SQL Server, MySQL, Oracle a PostgreSQL). Konkrétní mechanismy poskytované jednotlivými databázemi jsou nakonec porovnány z hlediska vzájemné kompatibility. Oblast databázových systémů nicméně prochází rychlým rozvojem. Kromě tradičních relačních databází dnes existují již i poměrně zavedené NoSQL databáze, které 9

10 nejsou založeny na jazyku SQL a relační algebře a nevyužívají ani tradiční transakce, jak je chápe ANSI SQL standard. V závěru práce jsou proto stručně probrány i vybrané mechanismy, kterými je zajištěn konkurenční přístup v NoSQL databázových systémech. 10

11 1 Konkurenční přístup podle ANSI SQL standardu Současný přístup několika uživatelů k databázi je řízen na úrovni transakcí. ANSI standard jazyka SQL (dále ANSI standard) definuje transakci takto: An SQL-transaction (transaction) is a sequence of executions of SQL-statements that is atomic with respect to recovery. That is to say: either the execution result is completely successful, or it has no effect on any SQLschemas or SQL-data [1, s. 27]. Míra vzájemného ovlivňování paralelně probíhajících transakcí se nazývá úroveň izolace (isolation level). ANSI standard vyjmenovává tyto úrovně izolace: read uncommitted, read committed, repeatable read a serializable. Úroveň read uncommitted umožňuje nejvyšší míru ovlivňování. Úroveň serializable naopak žádnou, neboť pro tuto úroveň izolace je vyžadováno, aby výsledný efekt transakcí na stav databáze byl dosažitelný postupným vykonáním identických transakcí v nějakém konkrétním pořadí. Takové uspořádání transakcí je nazýváno sekvenční uspořádání [2, s. 150]. Na konkrétním pořadí sekvenčního uspořádání transakcí nezáleží, důležité je, že alespoň jedno takové uspořádání existuje (viz obr. 1.1). Na jednotlivé transakce úrovně serializable tedy lze nahlížet, jako by byly prováděny v databázi zcela izolovaně od ostatních transakcí. Obrázek 1.1: Sekvenční uspořádání paralelně prováděných transakcí Původní provedení Sekvenční uspořádání D D B A B C A C Zdroj: Vlastní zpracování 11

12 Pro ostatní úrovně izolace ANSI standard vzájemné ovlivňování transakcí připouští. Způsoby vzájemného ovlivňování paralelně probíhajících transakcí jsou popsány pomocí fenoménů, které mohou při použití dané úrovně izolace v probíhající transakci nastat: Dirty read: transakce T 1 přečte řádek, který byl modifikován transakcí T 2, aniž by transakce T 2 provedla COMMIT. Jestliže poté transakce T 2 skončí neúspěšně (ROLLBACK), načetla transakce T 1 řádek, který nebyl nikdy commitován a lze tedy říci, že v určitém smyslu v databázi nikdy neexistoval. Non-repeatable read: transakce T 1 přečte řádek. Transakce T 2 následně tento řádek modifikuje, nebo odstraní a provede COMMIT. Pokud se transakce T 1 pokusí řádek znovu načíst, zjistí, že řádek neexistuje, nebo se jeho hodnoty liší od prvního přečtení. Phantom: transakce T 1 přečte množinu záznamů S, které odpovídají určitým vyhledávacím kritériím. Transakce T 2 následně v databázi vytvoří a commituje záznam nebo záznamy (vložením nových nebo modifikací existujících), které splňují vyhledávací kritéria použitá transakcí T 1. Jestliže transakce T 1 poté opakuje čtení dat s použitím stejných vyhledávacích kritérií, získá množinu řádků odlišnou od množiny S [2, s. 150]. Přípustnost uvedených fenoménů v transakcích pracujících s jednotlivými úrovněmi izolace je uvedena v tabulce 1.1. Tabulka 1.1: Přípustné fenomény jednotlivých úrovní izolace SQL transakcí Úroveň izolace Dirty read Non-repeatable read Phantom Read uncommitted Může nastat Může nastat Může nastat Read committed Nemůže nastat Může nastat Může nastat Repeatable read Nemůže nastat Nemůže nastat Může nastat Serializable Nemůže nastat Nemůže nastat Nemůže nastat Zdroj: [2, s. 150] Tato definice bohužel trpí závažnými nedostatky, jak je diskutováno v [3]. Slovní formulace popisu nežádoucích fenoménů je nepřesná a umožňuje různý výklad. Striktní výklad je založen na výskytu situací popsaných v jednotlivých definicích fenoménů. Široký výklad fenoménu zahrnuje budoucí možný výskyt problematických jevů, ke kterým chování popsané v ANSI definici může potenciálně vést, přestože nejsou v popisu fenoménu explicitně uvedeny. Rozdíly mezi striktní a širokou interpretací fenoménů jsou v [3, s. 2] formálně popsány. Široký výklad fenoménu dirty read například postihuje i situace, kdy transakce T 1 díky přečtení necommitovaných dat získá nekonzistentní obraz databáze, i když transakce T 2 nakonec skončila úspěšně a neprovedla ROLLBACK zmíněný v definici fenoménu. Podobně popis fenoménu Phantom rovněž vůbec nezmiňuje možnost odstranění záznamů, které patřily do množiny S, široký výklad musí tedy zahrnovat i operace DELETE. Právě široký výklad fenoménů byl pravděpodobně autory ANSI standardu zamýšlen, protože poskytuje přesnější definice a vede ke spolehlivějším a lépe definovaným úrovním izolace transakcí. 12

13 Druhým nedostatkem ANSI definic úrovní izolace je, že neobsahují další, dobře definovatelné úrovně izolace, které jsou přitom implementovány v široce rozšířených databázových systémech. S nimi souvisí dodatečné fenomény nedefinované ANSI standardem, jako jsou lost update, read skew nebo write skew. Pomocí nich pak lze definovat úroveň izolace cursor stability, která zabrání fenoménu lost update, nebo úroveň snapshot isolation (SI), která navíc neumožní výskyt read skew ([3, s. 10]). Příčinou těchto opomenutí je zřejmě skutečnost, že definice úrovní izolace byly inspirovány mechanismy založenými na uzamykání záznamů. Autoři se sice snažili zvolit terminologii, která by byla na konkrétní implementaci nezávislá, přesto se jim však nepodařilo vyvarovat se rozličných neduhů z tohoto přístupu vyplývajících. Výše zmíněná úroveň izolace SI (která bude popsána dále v kapitole Snapshot isolation, str. 25) ilustruje poslední, pravděpodobně nejzávažnější problém spojený s ANSI definicemi. Tato úroveň izolace sice vylučuje výskyt fenoménů dirty read, non-repeatable read i phantom (a to i v jejich širokých interpretacích), ale pouhé vyloučení všech těchto jevů samo o sobě nestačí k dosažení serializovatelnosti transakcí. V některých databázích je přitom úroveň izolace SI poskytována právě místo úrovně serializable. Může tak snadno dojít k omylu v tom, jakou úroveň izolace databáze skutečně poskytuje. 13

14 2 Základní mechanismy řízení konkurenčního přístupu Tato kapitola byla zpracována podle [4], není-li uvedeno jinak. Databázové systémy typicky poskytují přístup k databázi prostřednictvím transakcí. V relačních databázových systémech musí transakce splňovat sadu kritérií známých pod akronymem ACID (Atomicity, Consistency, Isolation, Durability): Atomicity: transakce je považována za atomickou, pokud všechny její operace buď vždy uspějí, nebo vždy selžou. Toto kritérium se typicky vztahuje na celkový výsledek transakce po jejím ukončení nebo zrušení. Consistency: pokud se databáze před začátkem transakce nacházela v konzistentním stavu, musí se v konzistentním stavu nacházet i po úspěšném ukončení transakce. Isolation: provádí-li databázový systém více transakcí současně, jednotlivé transakce se nesmí navzájem ovlivňovat. Všechny transakce musí proběhnout tak, aby výsledek byl ekvivalentní situaci, kdy jednotlivé transakce byly provedeny jedna po druhé v nějakém konkrétním pořadí. Durability: jakmile byla transakce úspěšně ukončena, výsledky operací, které provedla, musí být permanentně součástí databáze a nesmí se ztratit ani v případě havárie systému. Jsou-li tato kritéria splněna, databázový systém jako celek se chová korektně - je rezistentní vůči různým selháním a data v něm uložená jsou za běžného provozu chráněna před poškozením. Vzhledem k tomu, že transakce prováděné databázovým systémem jsou poskytovány zvenčí prostřednictvím uživatelů či aplikačních programů, je kritérium konzistence z převážné části zodpovědností autorů těchto transakcí a relační databázové systémy tomuto cíli typicky pouze napomáhají prostřednictvím integritních omezení. Ostatní tři uvedené vlastnosti jsou však plně pod kontrolou databázového systému. Z hlediska konkurenčního přístupu je nejdůležitější vlastností izolace transakcí. Cílem izolace je zajistit, aby každá transakce byla vykonávána (ve smyslu účinku svých operací na databázi) tak, jako kdyby žádná jiná transakce ve stejnou chvíli prováděna nebyla. Databázový systém přitom může operace jednotlivých transakcí provádět v libovolném pořadí nebo dokonce paralelně. Tím je dosaženo jednak vyššího výkonu a propustnosti databázového systému, jednak toho, že krátká transakce nemusí čekat na dokončení již započaté dlouhé transakce. Pokud je každá transakce databázovým systémem vykonávána izolovaně, lze také zcela izolovaně a bez přihlédnutí k jiným transakcím posoudit její korektnost (splnění kritéria konzistence). Ujistíme-li se tedy, že každá transakce prováděná databázovým systémem je korektní, tj. převádí databázi z jednoho konzistentního stavu do druhého, 14

15 je implicitně zajištěno, že databáze zůstane konzistentní bez ohledu na počet a typ paralelně prováděných transakcí. V praktických implementacích je bohužel zajištění úplné izolace problematické, neboť cíl úplné izolace transakcí je v rozporu s cílem vysokého výkonu a propustnosti systému. To přináší velké problémy uživatelům databáze a zejména autorům databázových aplikací, kteří mohou být nuceni se zabývat problémem vzájemného ovlivňování nedokonale izolovaných transakcí. Náročnost tohoto úkolu stoupá velmi rychle s počtem různých typů transakcí používaných v aplikaci. 2.1 Teorie serializovatelnosti Otázkou izolace transakcí se podrobně zabývá teoretická informatika, ve které lze takový požadavek formálně vyjádřit a dále zkoumat. Díky formalizaci problematiky je pak možné rozhodnout, zda konkrétní metody nebo algoritmy splňují nebo nesplňují kritérium izolace, ale také lépe pochopit, jakým způsobem spolu soupeří požadavky na izolaci transakcí (a tedy konzistenci a spolehlivost zpracování dat) na straně jedné a požadavky na co nejvyšší výkon a propustnost systému při souběžném zpracování dat na straně druhé. Úrovně izolace transakcí, které připouštějí nějakou míru vzájemného ovlivňování, lze také formálně popsat. Vzhledem k rozsáhlosti problematiky se však zaměřím pouze na teorii serializovatelnosti, a to zejména na oblasti, které jsou relevantní pro databázové systémy popisované v této práci. Pro formální popis mechanismů řízení konkurenčního přístupu je nutno definovat model databázového systému. Pro účely dalšího výkladu lze databázový systém popsat modelem uvedeným na obrázku 2.1. Obrázek 2.1: Schéma databázového systému T 1 T 2... Manažer transakcí Rozvrhovač transakcí Manažer dat Databáze T n Zdroj: [4, s. 18] Funkce jednotlivých modulů v tomto schématu je určena takto: Manažer transakcí: zajišťuje komunikaci mezi externími systémy a databázovým systémem, přijímá požadavky v rámci jednotlivých transakcí, předzpracovává je a ve formě jednotlivých operací je předkládá rozvrhovači transakcí. Rozvrhovač transakcí (dále scheduler): určuje pořadí, v jakém jsou operace požadované manažerem transakcí prováděny. Manažer dat: zajišťuje samotné provedení operací, tedy čtení nebo zápis dat v databázi. Jednotlivé operace musí být prováděny atomicky. 15

16 Manažer transakcí tedy zajišťuje rozložení transakcí do sledu atomických operací. Operace představuje čtení (READ) nebo zápis (WRITE) jednotlivých datových položek, které lze jednoznačně identifikovat. Dále každá transakce obsahuje právě jednu operaci COMMIT nebo ABORT, a to jako poslední operaci. Pro popis operací prováděných databází použiji zápis o i [x], kde o představuje prováděnou operaci reprezentovanou počátečním písmenem jejího názvu (tedy r, w, c nebo a pro operace READ, WRITE, COMMIT a ABORT), index i identifikuje transakci T i, v rámci které jsou operace prováděny, a x představuje identifikátor datové položky operace čtení nebo zápisu. Pomocí šipek je vyjádřeno pořadí provádění jednotlivých operací. Následující zápis tedy představuje transakci T 1, která přečte z databáze položku x, následně zapíše položku y a skončí příkazem COMMIT: T 1 : r 1 [x] w 1 [y] c 1 V případě souběhu transakcí volí scheduler určité konkrétní pořadí provádění operací jednotlivých transakcí. Takové konkrétní uspořádání nazýváme historie (též transakční rozvrh). Historie realizovaná databázovým systémem může obsahovat i transakce, které byly nakonec zrušeny. Uspořádání operací v rámci historie musí vždy respektovat uspořádání operací uvnitř jednotlivých transakcí. Speciálním případem historie je sériová historie, ve které jsou všechny operace každé transakce vykonány před (nebo po) všech operacích každé jiné transakce v historii. Je zjevné, že v případě sériové historie je kritérium izolace transakcí beze zbytku splněno. Operace mohou být v rámci historie prováděny i paralelně, za předpokladu, že se nejedná o konfliktní operace. Dvě operace jsou konfliktní, pokud obě zpracovávají stejnou datovou položku a alespoň jedna z nich je WRITE. Pořadí provádění konfliktních operací v rámci historie musí být vždy jednoznačně určeno (lze snadno nahlédnout, že kdyby tomu tak nebylo, nebyl by výsledný efekt vykonání určité historie definován; máme-li dvě transakce, které obě zapisují hodnotu do položky x, závisí výsledná hodnota položky x na tom, která z transakcí byla efektivně vykonána jako poslední). Dvě různé historie Ha H lze prohlásit za ekvivalentní, pokud obě historie obsahují shodné transakce složené ze shodných operací, a vzájemné pořadí každé dvojice konfliktních operací obsažených v nezrušených transakcích je totožné. Historii H potom označíme za serializovatelnou, 1 pokud existuje nějaká sériová historie H s, která je ekvivalentní historii H. Pro zjištění, zda je daná historie H serializovatelná, je nutné vytvořit serializační graf SG(H). Serializační graf je orientovaný graf, jehož vrcholy jsou tvořeny jednotlivými transakcemi náležejícími do H, a hrany jsou všechny dvojice uzlů T i T j takové, že i j a jedna z operací náležejících do T i předchází a koliduje s některou z operací náležejících do T j v historii H (jedna hrana v serializačním grafu může představovat jednu nebo více konfliktních operací mezi dvěma transakcemi). Historie H je serializovatelná, pokud je serializační graf SG(H) acyklický. 2 Z hlediska dodržení kritérií ACID databázového systému jsou významné další vlastnosti historií provádění databázových transakcí. Tyto vlastnosti jsou nezávislé na tom, zda je historie serializovatelná či nikoliv. Je-li historie zotavitelná, znamená to, že v případě zrušení dosud neukončené transakce dokáže databázový systém zajistit zrušení 1 V české literatuře se pro tuto vlastnost používá také termín uspořádatelnost. 2 Sériovou historii H s ekvivalentní H lze v tomto případě získat topologickým uspořádáním SG(H). Ekvivalentních sériových historií může být více, například pokud neexistují žádné konfliktní operace v H, je ekvivalentní sériovou historií každá permutace jednotlivých transakcí obsažených v H. 16

17 všech jejích efektů, a to jak na data spravovaná databázovým systémem, tak i na ostatní dosud aktivní transakce. Uvažujme tuto historii obsahující transakce T 1 a T 2 : H 1 : w 1 [x] r 2 [x] a 1 Transakce T 1 tedy zapsala hodnotu datové položky x, která byla následně přečtena transakcí T 2. Poté došlo ke zrušení transakce T 1. Historie H 1 je zotavitelná, a to tak, že transakce T 2 bude systémem zrušena; 3 žádným jiným způsobem nelze zabránit tomu, aby operace r 2 [x] nebyla ovlivněna transakcí T 1. Uvažujme nyní tuto historii: H 2 : w 1 [x] r 2 [x] w 2 [y] c 2 Historie H 2 není zotavitelná pokud by transakce T 1 měla být nyní zrušena, její efekt na transakci T 2 již zrušen být nemůže, transakce je již commitována. Scheduler tedy nesmí připustit, aby byl tento sled operací vykonán. Lze toho docílit tak, že databáze neprovede commit transakce T, dokud není proveden commit všech transakcí, jejichž výstupy transakce T přečetla. Silnější vlastností databázového systému je bezkaskádovost (někdy též zabezpečenost proti kaskádovému rušení). V předchozích odstavcích byla popsána situace, kdy zrušení transakce T 1 vedlo ke zrušení transakce T 2. Tím ovšem řetězec rušení končit nemusí, na transakci T 2 může být závislá jedna nebo více dalších transakcí, jejichž počet je v principu neomezený. Takové situace jsou nežádoucí a schedulery jim obvykle předcházejí. Bezkaskádovost je zajištěna tak, že scheduler neumožní čtení dat zapsaných aktivní transakcí, dokud tato transakce není ukončena. Poslední vlastnost, kterou databázové systémy typicky splňují, je striktnost. Uvažujme tuto historii: H 3 : w 1 [x] w 2 [x] w 3 [x] a předpokládejme, že transakce T 3 je zrušena. V této situaci je nutné vrátit hodnotu položky x do stavu, ve kterém by měla být, pokud transakce T 3 vůbec neproběhla, tedy na hodnotu zapsanou transakcí T 2. Bude-li nyní zrušena i transakce T 2, bude nutné obnovit hodnotu x zapsanou transakcí T 1. Přestože teoreticky lze databázový systém navrhnout tak, aby vždy dokázal nalézt správnou hodnotu všech položek pro obnovu při zrušení kterékoliv transakce, v praxi je správa všech potřebných informací problematická. Schedulery tomuto problému předcházejí tak, že zápis hodnoty položky v transakci je pozdržen do doby, dokud všechny transakce, které tuto položku modifikovaly dříve, nejsou buď ukončeny nebo zrušeny. Striktní je pak takový systém, který neumožní ani čtení, ani zápis dat zapsaných jinou dosud aktivní transakcí. Diagram vzájemného vztahu množin striktních, bezkaskádových, zotavitelných a serializovatelných historií je znázorněn na obrázku Konzervativní a agresivní protokoly Schedulery používají různé soubory pravidel protokoly pro dosažení striktních a serializovatelných historií. Konkrétní protokol specifikuje, jakým způsobem scheduler zpracuje operace přicházející v rámci jednotlivých transakcí. V úvahu připadají tyto možnosti: 3 Jak bude uvedeno níže, zrušení některé transakce pro dosažení serializovatelnosti je jedna ze strategií, které schedulery v praxi skutečně využívají. 17

18 Obrázek 2.2: Vztahy mezi třídami historií databázových operací Všechny historie Serializovatelné Zotavitelné Bezkaskádové Striktní Sériové Zdroj: [4, s. 36] operaci ihned provést, provádění operace odložit na vhodnější dobu, operaci (a tím i celou transakci, která provedení operace požaduje) odmítnout. Jednotlivé protokoly obvykle jednu nebo dvě z těchto možností preferují. Podle těchto preferencí lze protokoly zhruba klasifikovat jako konzervativní nebo agresivní. Agresivní protokoly se snaží vyhnout odkládání operací a pokouší se je ihned provést. Tím se však připravují o možnost přeuspořádat jednotlivé operace a může tak vzniknout situace, ve které je pro dosažení serializovatelnosti nutné některé operace požadované transakcí (a tím i transakci jako takovou) odmítnout. Konzervativní protokoly se naopak snaží vyhnout rušení transakcí. Operace, která by mohla způsobit konflikt, je odložena do doby, než hrozba vzniku konfliktu pomine (tj. dokud transakce, která provedla konfliktní operaci, není ukončena). Extrémním příkladem konzervativní strategie je protokol, který odkládá všechny příchozí operace až na jednu transakci. Po dokončení takové transakce je vybrána další, jejíž operace jsou provedeny. Výsledkem tohoto přístupu je sériová historie transakcí (a záruka, že tento protokol nikdy nezpůsobí odmítnutí transakce), ovšem za cenu úplné ztráty paralelismu ve vykonávání transakcí. V praktických implementacích se agresivní protokoly nevyhnou odkládání některých operací, a podobně konzervativní protokoly musí v některých případech odmítnout provedení konfliktních transakcí. 18

19 2.3 Uzamykací protokol Uzamykací protokol je příkladem konzervativního protokolu, který pro vhodné uspořádání operací využívá uzamykání dat. Každá datová položka má přiřazen zámek, který musí být transakcí T získán předtím, než transakce přistoupí k datové položce. Protože transakce přistupují k datům pomocí různých operací (čtení nebo zápis dat), alokují se i zámky zvlášť pro čtení dat a pro zápis dat. Zámky pro čtení dat bývají obvykle označovány jako sdílené a zámky pro zápis dat jako exkluzivní. Je tomu tak proto, že operace READ dvou transakcí nejsou v konfliktu; sdílený zámek nad stejnou datovou položkou tedy může získat více transakcí najednou. Exkluzivní zámek může naopak vlastnit pouze jedna transakce, a to tehdy, pokud žádná jiná transakce nevlastní žádný typ zámku (exkluzivní ani sdílený) nad stejnou položkou. Pokud je zámek požadovaný transakcí T v konfliktu se zámkem vlastněným jinou transakcí, musí transakce T počkat, než je zámek opět uvolněn. Je také zřejmé, že transakce musí zámek chránící datovou položku držet nejméně po dobu, po kterou probíhají operace (čtení nebo zápisu) nad dotyčnou datovou položkou. Dvoufázové uzamykání Pravidla uzamykání popsaná výše zajišťují korektní čtení i zápis jednotlivých položek v konkurenčním prostředí, ale nikoliv serializovatelnost historie transakcí. Předpokládejme tuto historii operací, při níž jsou zámky alokovány pouze po dobu provádění operace čtení nebo zápisu jedné položky: H 4 : w 1 [x] w 2 [x] w 2 [y] w 1 [y] Transakce T 1 zapisuje položku x dříve než transakce T 2, ale položku y později než T 2. V serializačním grafu tedy existuje cyklus obsahující právě transakce T 1 a T 2. Tomuto problému lze snadno předejít aplikací dalšího pravidla pro alokaci zámků: jakmile transakce uvolní kterýkoliv z ní přidělených zámků, nesmí již získat žádný další zámek na žádné datové položce. Při dodržení tohoto pravidla je zajištěno, že všechny dvojice konfliktních operací mezi dvěma transakcemi zde (w 1 [x], w 2 [x]) a (w 1 [y], w 2 [y]) jsou provedeny vždy ve stejném pořadí. Intuitivně lze nahlédnout, že serializační graf je v důsledku toho vždy acyklický a výsledná historie je tedy serializovatelná. 4 V důsledku tohoto pravidla je každá transakce přirozeně rozdělena do dvou fází: do fáze uzamykání, kdy může získávat nové zámky, a do fáze odemykání, kdy jsou zámky naopak uvolňovány (odtud pochází i název dvoufázové uzamykání ). Striktní dvoufázové uzamykání Ve výše popsaném protokolu dvoufázového uzamykání jsou zámky uvolňovány ve fázi odemykání v průběhu transakce. Pokud v této době jiná transakce získá zámek pro čtení nebo zápis položky, která byla modifikována transakcí T, může v rozporu s požadavky na striktnost k této položce přistupovat (číst nebo zapisovat), aniž by transakce T skončila. Řešením je uvolnění všech zámků získaných transakcí současně s operací COMMIT nebo ABORT. Celá transakce je tak vlastně fází uzamykání a fáze odemykání je degenerovaná na 4 Pro formální důkaz odkazuji na [4, s. 53] 19

20 Obrázek 2.3: Základní protokol dvoufázového uzamykání fáze uzamykání fáze odemykání transakce commit Zdroj: Vlastní zpracování okamžik ukončení transakce. (Tento přístup je zřejmě snazší i z hlediska implementace, neboť scheduler nemusí řešit otázku, zda se aktuálně prováděná transakce nachází ve fázi uzamykání nebo odemykání.) Historie produkované striktním dvoufázovým uzamykáním jsou tedy jak serializovatelné, tak i striktní. Obrázek 2.4: Striktní protokol dvoufázového uzamykání transakce Zdroj: Vlastní zpracování commit Uváznutí Protokoly dvoufázového uzamykání musí obvykle řešit problém uváznutí (deadlock). K uváznutí dochází, pokud dvě různé transakce vlastní zámky nad dvěma různými datovými položkami a obě požadují uzamčení datové položky vlastněné druhou transakcí. Uváznutí nelze vyřešit bez zrušení jedné z dotčených transakcí, teprve poté jsou její zámky uvolněny a mohou tak být k dispozici pro druhou transakci. Toto je jediná situace, kdy protokol dvoufázového uzamykání způsobí zrušení transakce. Aby scheduler mohl korektně vyřešit problém uváznutí, musí být schopen jeho vznik detekovat. Nejčastěji se využívá detekce cyklů ve waits-for grafu. Uzly grafu jsou tvořeny 20

21 transakcemi, a mezi dvěma uzly T i a T j existuje orientovaná hrana T i T j, pokud transakce T i čeká na uvolnění některého ze zámků vlastněných transakcí T j. Cyklus v tomto grafu může obsahovat dvě nebo více transakcí, přičemž jedna transakce může být součástí více než jednoho cyklu. Druhým problémem je volba transakce, která bude při řešení uváznutí zrušena. Mezi kritéria výběru patří například: Počet cyklů ve waits-for grafu, kterých je transakce součástí: zrušením transakce se vyřeší všechna uváznutí, na kterých rušená transakce participuje. Objem práce, který transakce již vykonala: tato práce bude ztracena, a pokud transakce bude provedena znovu, bude muset být znovu vykonána. Do objemu ztracené práce je nutné započítat také odstranění změn provedených rušenou transakcí. Počet zrušení transakce: pokud databázový systém dokáže sledovat, kolikrát již transakce byla zrušena, je vhodné snažit se předejít opakovanému rušení téže transakce. Víceúrovňová granularita uzamykání Databáze využívající uzamykací protokol musí být připraveny spravovat velké množství zámků. To samozřejmě klade velké nároky na efektivní správu zámků: databázový systém musí umět zámky snadno alokovat a uvolňovat a v případě uvolnění některého ze zámků rychle identifikovat operace, které na uvolnění zámku čekají. Pro snížení počtu spravovaných zámků se proto zámky přidělují s různou úrovní granularity: místo uzamykání jednotlivých záznamů lze uzamykat celé stránky, tabulky nebo dokonce tabulkové prostory. Ačkoliv intuitivně by se mohlo zdát, že použití hrubší granularity přidělování zámků povede ke snížení propustnosti systému, není tomu nezbytně tak. Použití jemnější granularity sice vede k nižší pravděpodobnosti konfliktu na jeden požadavek na uzamčení, ale na druhou stranu vede k potřebě alokovat více zámků, takže celkový počet konfliktů na transakci může být vyšší. Obecně je vztah mezi granularitou a celkovou propustností systému zobrazen na obrázku 2.5; faktory a předpoklady, které vedou k uvedenému tvaru křivky, jsou popsány v [4, s ]. Databázový systém většinou dopředu neví, zda daná transakce bude alokovat velké množství zámků, 5 a proto obvykle začíná transakci přidělovat zámky s nejjemnější granularitou (na úrovni záznamů). V případě, že transakce požaduje velké množství zámků, začne databázový systém přidělovat zámky s méně jemným rozlišením. Tento mechanismus se nazývá eskalace zámků. Přestože se databázové systémy snaží problematiku uzamykání a eskalace zámků řešit efektivně a uživatele databáze od této problematiky odstínit, patří eskalace zámků mezi nežádoucí jevy z hlediska autorů databázových aplikací, neboť může způsobit uváznutí, nebo alespoň snížení míry propustnosti i mezi transakcemi, které přistupují k disjunktním datovým sadám. 5 Do jisté míry lze předpovědět množství alokovaných zámků alespoň na úrovni SQL dotazů, protože typicky je konkrétní postup provádění dotazu (tzv. plán) znám ještě před zahájením zpracování dotazu. 21

22 Obrázek 2.5: Obecná křivka granularity Propustnost 0 Hrubá granularita Jemná granularita Zdroj: [4, s. 93] Problém fantomu a predikátové zámky Až dosud byly uvažovány pouze operace čtení a zápisu. Alokování zámků pro tyto operace je poměrně přímočaré, protože vždy existuje konkrétní datová položka, ke které lze zámek přiřadit. Tento přístup bohužel přestává být dostatečný ve chvíli, kdy začneme uvažovat i operace vkládání (INSERT) a odstraňování (DELETE). Problém nastane v situaci, kdy transakce T 1 přečte nějakou množinu datových položek z databáze, a poté transakce T 2 vloží nové datové položky, které by správně měly být transakcí T 1 přečteny (tj. splňují podmínku, kterou transakce T 1 použila pro vyhledání a přečtení datových položek). Pro ilustraci předpokládejme databázi se dvěma tabulkami: tabulkou Účty, která pro každý účet obsahuje číslo účtu, pobočku, která účet vede, a stav účtu, a tabulkou Aktiva, která obsahuje celkovou bilanci (součet stavů) všech účtů vedených bankou v dané pobočce. Počáteční stav databáze je uveden v tabulce 2.1. Tabulka 2.1: Bankovní databáze Účty Účet Pobočka Stav 339 Brno Ostrava Ostrava 1550 Aktiva Pobočka Bilance Brno 750 Ostrava 3858 Zdroj: [4, s. 64] Nad touto databází budou provedeny dvě transakce: Transakce T 1 přečte všechny účty vedené pobočkou v Ostravě, sečte jejich stav a porovná jej s celkovou bilancí uve- 22

23 denou v tabulce Aktiva. Transakce T 2 přidá nový účet vedený v téže pobočce a upraví odpovídajícím způsobem tabulku Aktiva. Jednotlivé příkazy transakcí by mohly být při využití dvoufázového uzamykání vykonány například takto: Read 1 (Účty[339], Účty[914], Účty[22]); Insert 2 (Účty[99, Ostrava, 50]); Read 2 (Aktiva[Ostrava]); /* Přečte hodnotu 3858 */ W rite 2 (Aktiva[Ostrava, 3908]); Read 1 (Aktiva[Ostrava]); /* Přečte hodnotu 3908 */ Transakce T 1 přečetla (a uzamkla sdíleným zámkem) záznamy účtů 339, 914 a 22, ale při přístupu k tabulce Aktiva získala bilanci, která již zahrnuje účet 99 přidaný transakcí T 2. Pokud by celá transakce T 1 proběhla před T 2, získala by hodnotu Bilance z tabulky Aktiva rovnou Pokud by transakce T 1 proběhla až po T 2, dozvěděla by se i o existenci účtu 99. Ani jedna z těchto situací ovšem nenastala, a výše uvedený sled operací tedy není serializovatelný. Problém představuje záznam 99 v tabulce Účty. Při přístupu do tabulky Účty jej transakce T 1 nenajde. Později jej však záznam v tabulce Aktiva již zohledňuje. Takový objevující se a mizící záznam se nazývá fantom. Pro zabránění vzniku fantomů je nezbytné rozšířit databázový systém o možnost uzamknout i záznamy, které v databázi fyzicky neexistují, ale splňují podmínku vyjádřenou nějakým predikátem. Dva predikátové zámky by pak byly v konfliktu, pokud by mohl existovat alespoň jeden záznam, který by oběma predikátům vyhovoval. V našem příkladu by transakce T 1 alokovala predikátový zámek vyjádřený podmínkou Účty.P obočka = Ostrava, a tím by zabránila vložení nového záznamu do tabulky Účty transakcí T 2. Implementace predikátových zámků je však problematická, neboť obecná detekce kolize dvou libovolně složitých predikátů může být velmi nákladná. Databázové systémy místo toho v praxi často používají uzamykání na úrovni indexů, pomocí kterých lze vzniku fantomů rovněž zabránit. 6 Pokud nad tabulkou vhodný index není vytvořen, nebo jej nelze z nějakého důvodu použít, musí být uzamčena přímo celá tabulka. Další úrovně izolace Protokol dvoufázového uzamykání lze poměrně snadno oslabit tak, aby bylo dosaženo i ostatních úrovní izolace definovaných ANSI standardem. Alokace exkluzivních zámků pro operace čtení zůstává ve všech úrovních izolace stejná (uzamčení trvá až do konce transakce), rozdíly však nastávají při alokaci sdílených zámků pro čtení dat. Požadavky na uzamykání při provádění operací čtení na různých úrovních izolace transakcí jsou uvedeny v tabulce 2.2. Sloupec Datové položky popisuje požadavky na sdílené uzamykání jednotlivých přečtených datových položek. Sloupec Predikáty pak specifikuje požadavky na alokaci predikátových zámků (typicky realizovanou prostřednictvím indexů, jak bylo uvedeno výše). Požadavky na uzamykání mohou být následující: 6 Sdílené zámky jsou navzájem kompatibilní, proto není nikdy nutné jejich kolizi testovat. Alokace exkluzivních zámků je spojena s operacemi zápisu, a ty musí obecně aktualizovat i indexy nad tabulkami, proto detekce kolize mezi sdílenými zámky alokovanými nad indexy a exkluzivními zámky nepřináší významnou dodatečnou režii. 23

24 Tabulka 2.2: Operace čtení při různých úrovních izolace Sdílené zámky Úroveň izolace Datové položky Predikáty Read uncommitted Žádné Žádné Read committed Krátkodobé Krátkodobé Repeatable read Dlouhodobé Krátkodobé Serializable Dlouhodobé Dlouhodobé Zdroj: [3, s. 4] Žádné: při provádění operace čtení neprobíhá žádné uzamykání. Krátkodobé: zámek je alokován pouze po dobu provádění operace čtení, potom je opět uvolněn. Tím je samozřejmě porušeno pravidlo dvoufázového uzamykání, a transakce využívající takovou úroveň izolace tedy obecně nejsou serializovatelné. Dlouhodobé: zámek je alokován od okamžiku přístupu k položce až do konce transakce [3, s. 4]. 2.4 Multiverzní protokoly Dalším typem protokolů, které nejsou založeny primárně na uzamykání dat, jsou multiverzní protokoly, v literatuře též označované jako multiversion concurrency control (MVCC). V těchto protokolech každý zápis datové položky x vytvoří novou kopii (verzi) x. Při realizaci operací čtení se databázový systém rozhoduje nejen o tom, kdy bude operace provedena, ale i o tom, jakou verzi položky má operace zpracovat. Zásadní výhodou tohoto přístupu je, že databázový systém nemusí odmítat operace čtení, které přišly na řadu příliš pozdě. Za normálních okolností by systém musel odmítnout operaci čtení v případě, že požadovaná položka byla mezitím přepsána jinou transakcí. V multiverzním systému nejsou staré verze položek přepsány, ale jsou vytvořeny nové verze, takže původní verze položky je i nadále k dispozici pro čtení jinými transakcemi. Databázový systém navíc musí staré verze dat stejně uchovávat, aby byl vždy schopen provést zrušení transakce, která selhala. Jejich použití pro účely multiverzního mechanismu nemusí znamenat významné zvýšení složitosti databázového systému. Multiverzní systém musí samozřejmě nějakým způsobem odstraňovat zastaralá data, to jest verze položek příslušející zrušeným nebo velmi starým transakcím. Z hlediska uživatelů je multiverzní systém obvykle transparentní, existence různých verzí je před databázovými klienty skryta. 7 7 Některé systémy však uživatelům přístup ke starým verzím dat nějakým způsobem poskytují (viz např. Flashback a Total Recall, str. 72 v příloze A). 24

25 Snapshot isolation 8 Ačkoliv teoreticky byly popsány různé multiverzní protokoly, v praktických implementacích se osvědčily zejména protokoly založené na snapshotech. Transakce prováděné v protokolu SI čtou data z databáze prostřednictvím snapshotu (pohledu) obsahujícího právě ta data, která v databázi existovala k nějakému pevně zvolenému okamžiku (Start-Timestamp, typicky k okamžiku zahájení transakce). V tomto pohledu jsou přítomna pouze data transakcí, které již byly úspěšně ukončeny (příkazem COMMIT), a zápisy provedené samotnou aktuální transakcí. Změny provedené jinými dosud neukončenými transakcemi nejsou v tomto pohledu vůbec přítomné, a scheduler tak nemusí koordinovat operace čtení s operacemi zápisu, neboť ty nikdy nepřistupují k identické verzi datové položky operace zápisu v MVCC systémech vždy vytváří novou verzi položky. Sdílené zámky chránící operace čtení dat tedy nejsou vůbec potřebné a nejsou ani alokovány, operace čtení a operace zápisu se tedy neblokují. Operace čtení však může zcela selhat, pokud v databázi již nejsou data potřebná pro rekonstrukci snapshotu, což typicky vede k odmítnutí transakce schedulerem. Zápisy prováděné transakcemi jsou obvykle řízeny principem First committer wins. V okamžiku, kdy je transakce T 1 připravena provést COMMIT, je vygenerován Commit- -Timestamp, časová značka, která je větší než jakýkoliv jiný existující Start-Timestamp nebo Commit-Timestamp. Je-li v tuto chvíli zjištěno, že systémem byla provedena jiná transakce T 2, která modifikovala stejná data jako transakce T 1, a commitovala v období aktivity T 1 (tj. mezi okamžiky Start-Timestamp a Commit-Timestamp), je transakce T 1 zrušena. V opačném případě je commit potvrzen. Alternativou je řešení First writer wins, kdy databázový systém využívá uzamykání pro operace zápisu. Transakce T 1, která zámek úspěšně alokovala, položku skutečně změní. Konfliktní transakce T 2 při pokusu o alokaci zámku čeká. Pokud T 1 skončí úspěšně, je transakce T 2 zrušena, v opačném případě (zrušení T 1 ) je uvolněný zámek poskytnut transakci T 2, která jej alokuje a zapíše novou hodnotu položky. Výsledek je stejný jako v případě přístupu First committer wins: pouze jedna z překrývajících se transakcí může změnit hodnotu konkrétní datové položky. Vzhledem k použití zámků může samozřejmě v tomto případě dojít k uváznutí transakcí, které je řešeno schedulerem obdobně jako v případě protokolu dvoufázového uzamykání. Skutečnost, že operace čtení a zápisu dat nejsou v protokolu SI konfliktní, je zjevně jeho velmi silnou stránkou, zejména v situacích, kdy jsou vykonávány dlouhé transakce orientované převážně na čtení dat současně s velkým množstvím krátkých zapisujících transakcí. Naopak velkou slabinou protokolu je, že neprodukuje serializovatelné historie. Je to dáno tím, že operace čtení jsou de facto prováděny v jiném časovém okamžiku než operace zápisu. Zkreslení zápisu Zajímavým problémem je klasifikace úrovně izolace mechanismu SI podle ANSI standardu diskutovaného v kapitole 1. Žádný z fenoménů dirty read, non-repeatable read ani phantom definovaných tímto standardem totiž při použití SI nemůže nastat. 9 Veškeré 8 Tato podkapitola byla zpracována podle [3, 5, 6]. 9 Při výkladu ANSI standardu založeném na výskytu fenoménů tak lze prohlásit mechanismus SI za splňující úroveň izolace serializable. Někteří dodavatelé databázových systémů tak, bezpochyby i z marketingových důvodů, skutečně činí. 25

26 operace čtení totiž přistupují ke snapshotu obsahujícímu pouze data již commitovaných transakcí, což vylučuje fenomén dirty read, a opakované čtení dat ze statického pohledu musí vždy přečíst stejné hodnoty, což vylučuje zbývající dva fenomény. Protokol SI však porušuje serializovatelnost transakčních historií anomálií, která není ANSI standardem popsána, a která se nazývá zkreslení zápisu (write skew). Uvažujme tuto historii, která může být produktem SI protokolu: H 5 : r 1 [x] r 1 [y] r 2 [x] r 2 [y] w 1 [x] w 2 [y] c 1 c 2 Uvedená historie není serializovatelná v důsledku opačného uspořádání transakcí v konfliktních párech operací (r 2 [x], w 1 [x]) a (r 1 [y], w 2 [y]): v serializačním grafu SG(H 4 ) se vyskytuje jak hrana T 1 T 2, tak i hrana T 2 T 1, a tedy i cyklus. Zkreslení zápisu lze ilustrovat na tomto příkladu: předpokládejme, že x a y jsou datové položky reprezentující dva bankovní účty manželského páru, s omezením, že za všech okolností musí platit podmínka x + y > 0 (jeden nebo druhý účet lze přečerpat, ale celkový zůstatek musí zůstat kladný). Počáteční stav účtů je x = 70 a y = 80. Transakce T 1 přečte tyto hodnoty x a y a sníží zůstatek na účtu x o 100, což je přípustné, neboť celkový zůstatek i po této změně zůstává kladný. Transakce T 2 současně přečte stejné původní hodnoty x a y a sníží y rovněž o 100, neboť i z jejího pohledu je požadovaná podmínka splněna. Samostatně tedy obě transakce integritní omezení dodržely, ale výsledný stav po commitu obou transakcí je nepovolený (x + y = 50). Mechanismus First committer wins tomuto problému nezabránil, protože byly modifikovány dvě různé položky, každá za mylného předpokladu, že druhá z nich zůstala nezměněna. Anomálie read-only transakce Mnohem překvapivějším zjištěním však je, že i transakce, které provádějí pouze operace čtení (dále read-only transakce), mohou být SI schedulerem provedeny neserializovatelně. Intuitivně se zdá, že takový problém nemůže nastat, protože každá transakce čte data ze statického pohledu, který reflektuje pouze commitované, korektně provedené transakce (pomineme-li nyní problém zkreslení zápisu). Následující příklad však ukazuje, že použití snapshotů není pro zajištění serializovatelnosti read-only transakcí dostačující. Předpokládejme, že x a y jsou datové položky reprezentující kreditní a debetní účet téže osoby, na počátku s nulovými zůstatky. Z kreditního účtu lze vybírat peníze, ale pokud je následně celkový zůstatek nižší než vybíraná částka, je výběr zatížen jednorázovým poplatkem. Nad účty proběhnou operace vykonané v rámci tří transakcí: transakce T 1 uloží částku 20 na debetní účet y, transakce T 2 vybere 10 z kreditního účtu x včetně poplatku za přečerpání účtu, a konečně read-only transakce T 3 pouze přečte zůstatky obou účtů. Provedení transakcí by mohlo být vykonáno touto historií: 10 H 6 : r 2 [x 0, 0] r 2 [y 0, 0] r 1 [y 0, 0] w 1 [y 1, 20] c 1 r 3 [x 0, 0] r 3 [y 1, 20] c 3 w 2 [x 2, 11] c 2 Anomálií je v tomto případě skutečnost, že transakce T 3 přečte hodnoty x = 0 a y = 20, zatímco finální hodnoty jsou x = 11 a y = 20. Tato situace nemůže v žádném sériovém 10 Způsob zápisu historií transakcí je zde rozšířen tak, aby postihl existenci různých verzí datových položek. Index u položky označuje transakci, která položku zapsala; položky, které v dané historii nebyly žádnou transakcí modifikovány a mají tedy výchozí hodnotu, jsou označeny indexem 0. Navíc je u operací čtení a zápisu uvedena přečtená, resp. zapsaná hodnota. 26

27 uspořádání transakcí nastat: pokud by zůstatek x byl zvýšen o 20 předtím, než došlo k výběru z účtu y, poplatek za přečerpání by nemohl být účtován a výsledný celkový zůstatek by byl 10, nikoliv 9. Klient, který by věděl, že očekává příchozí platbu ve výši 20 a chtěl se ujistit, zda výběr 10 nebyl zpoplatněn, by se na základě výpisu poskytnutého transakcí T 3 právem domníval, že poplatek je účtován neoprávněně. Problematická je také právě transakce T 3 ; jsou-li první dvě transakce provedeny SI schedulerem samostatně, je výsledná historie vždy serializovatelná (zkreslení zápisu zde na rozdíl od předchozího příkladu nehrozí, protože transakce T 1 nečte položku x). Příčina anomálie tkví v tom, že transakce T 3 viděla výsledek transakce T 1, ale nikoliv výsledek transakce T 2, přičemž T 2 výstup T 1 neviděla. Pokud by totiž T 2 viděla výsledek transakce T 1, nebyl by účtován poplatek za přečerpání účtu a v serializovatelné historii by T 2 byla zařazena až za obě transakce T 1 i T 3. Popsaný problém se nazývá anomálie read-only transakce (read-only transaction anomaly). I v tomto případě lze serializovatelnost historie ověřit na základě neexistence cyklu v multiverzním serializačním grafu (MVSG), který představuje rozšíření serializačního grafu pro multiverzní systém. Vytvoření serializačních grafů historií produkovaných SI schedulerem je popsáno například v [6, s. 20:6]. Serializable snapshot isolation Oba uvedené nedostatky protokolu SI, tedy zkreslení zápisu a anomálii read-only transakcí, napravuje protokol serializable snapshot isolation (SSI). V tomto protokolu je potenciální výskyt těchto anomálií detekován a pokud k některé z nich dojde, je konfliktní transakce zrušena. V praxi však nelze detekci konfliktních transakcí realizovat hledáním cyklů v multiverzním serializačním grafu, protože tato operace je výpočetně příliš náročná. Prohledávaný MVSG by totiž musel zahrnovat jak všechny aktivní transakce, tak i všechny minulé úspěšně ukončené transakce, které se s alespoň jednou aktivní transakcí překrývaly. Tím by se staly velmi problematické zejména dlouhé read-only transakce, které jsou jinak SI schedulery velmi efektivně vykonávány. Místo tohoto přístupu se používá detekce výskytu tzv. nebezpečných struktur (dangerous structures), které byly popsány v [7, s. 514]. Zde bylo ukázáno, že každý cyklus v MVSG musí mít alespoň jednu nebezpečnou strukturu, která se skládá ze tří sousedících transakcí. Opačná implikace však neplatí, tedy výskyt nebezpečné struktury neznamená, že MVSG obsahuje cyklus. Je-li SSI schedulerem nebezpečná struktura detekována, některá z transakcí v ní obsažených je zrušena. Může se tedy stát, že SSI zruší transakci zbytečně, nicméně pravděpodobnost této události je malá ([6, s. 20:6-20:7 a 20:11]). Vznik nebezpečné struktury je způsoben konfliktem operací čtení a zápisu mezi různými transakcemi, a proto musí SSI scheduler, na rozdíl od SI verze, sledovat i všechny operace čtení. V praxi je tento požadavek nejčastěji realizován pomocí zvláštní kategorie predikátových zámků, označované obvykle SIREAD (tj. SI read), a to zejména z toho důvodu, že databázové systémy typicky obecnou podporu uzamykání již obsahují. SIREAD zámky však neslouží ke koordinaci přístupu (tj. neblokují ani ostatní SIREAD zámky, ani případné sdílené nebo exkluzivní zámky na stejné položce), ale pouze k detekci nebezpečných struktur ([6, s. 20:12]). 27

28 3 Implementace ve vybraných DB platformách Problematika konkurenčního přístupu může být v případě konkrétních implementací poměrně komplikovaná. Jak bude demonstrováno v této a následující kapitole, při vývoji databázových aplikací, pro které je vysoká míra izolace transakcí nezbytná, je vyžadováno poměrně podrobné porozumění mechanismům používaných databázových systémů. Proto budou v této kapitole příslušné mechanismy vybraných databázových platforem popsány. Popis vychází zejména z dostupné dokumentace a technické literatury, ale v některých případech jsou některé vlastnosti těchto systémů odvozovány na základě provedených testů. Konkrétní verze databázových systémů, které jsou předmětem této práce a na kterých byly prováděny výše zmíněné testy, jsou uvedeny v tabulce 3.1. Tabulka 3.1: Verze popisovaných databázových systémů Databázový systém Verze Microsoft SQL Server 2017 MySQL (InnoDB) 8.0 Oracle PostgreSQL Zdroj: Vlastní zpracování 3.1 Historie vývoje mechanismů konkurenčního přístupu Všechny databázové systémy popisované v této práci prošly během své existence významným rozvojem, a to i z hlediska mechanismů konkurenčního přístupu. Podobně se vyvíjel i samotný ANSI standard, v některých případech až v reakci na existující implementace, jindy naopak s předstihem udával směr dalšího rozvoje. Stručný přehled této historie, zaměřený právě na aspekty konkurenčního přístupu, je podán v následujících odstavcích a na obrázku 3.1. MS SQL Server První verze tohoto databázového systému označená SQL Server 1.0 vznikla v roce 1989 ve spolupráci společností Microsoft a Sybase. Byla určena pro systém OS/2. Systém byl od začátku založen na uzamykání záznamů a v průběhu času byl migrován do prostředí Windows. Významná byla verze SQL Server 6.5 z roku 1996, která dosáhla kompatibility s ANSI standardem. Zásadní zvrat z hlediska 28

29 Obrázek 3.1: Historie vývoje databázových platforem MS SQL Server MySQL Oracle PostgreSQL 1979 Pouze SQL 1981 Transakce 1984 MVCC SQL OS/2 Zámky řádků SQL Dvoufázový commit SQL Windows NT ISAM MVCC/SI Zámky tabulek 1999 MVCC/SI SQL: Flashback query 2003 MVCC/SI (dostupný) SQL: MVCC/SI 2007 Total recall SQL: MVCC/SI (výchozí) MVCC/SSI SQL:2011 Zdroj: Vlastní zpracování 29

30 mechanismů konkurenčního přístupu přinesla verze SQL Server 2005, ve které byl implementován mechanismus MVCC i databázové snapshoty (viz Databázový snapshot, str. 70 v příloze A). Zásadní změny v mechanismech konkurenčního přístupu od té doby již nenastaly [8]. MySQL Databáze MySQL byla vytvořena švédskou společností AB v roce 1994, a o rok později byla vydána jako open source projekt [9]. MySQL byl vytvářen s vizí využití storage engines, pluginů řídících organizaci dat samotné databáze. Zpočátku dostupné pluginy (ISAM a jeho nástupce MyISAM ) nepodporovaly transakční operace. 1 V roce 2001 zaznamenala větší rozšíření verze 3.23, zejména díky podpoře replikace. Verze 4.0 vydaná o dva roky později přinesla InnoDB, storage engine podporující transakce, která však prozatím nebyla výchozí možností serveru. Následující verze, 5.0, je významná ukončením podpory pluginu ISAM, MyISAM však zůstává dostupný dodnes. V roce 2008 přešla společnost MySQL AB do vlastnictví Sun Microsystems a verze 5.1 tak byla vydána pod touto značkou. O dva roky později změnil systém MySQL vlastníka znovu, když byl Sun Microsystems koupen společností Oracle. Verze 5.5 vydaná v této době přinesla mnoho vylepšení existujících funkcionalit, pro nás je ovšem nejvýznamnější skutečnost, že InnoDB se stala defaultním pluginem pro nové instalace [10]. Po akvizici MySQL společností Oracle se i z důvodů obav o budoucnost MySQL jako open source projektu od MySQL odštěpila MariaDB, nezávislý databázový projekt. Přestože další vývoj MariaDB a MySQL vede nevyhnutelně k divergenci mezi těmito projekty, jako svůj hlavní storage engine oba nadále využívají InnoDB. V dalších verzích MySQL, včetně verze 8.0 vydané v roce 2018, již k dalším zásadním posunům v oblasti řízení konkurenčního přístupu nedošlo [11]. Oracle První komerčně dostupná verze databáze Oracle byla vydána pod názvem Oracle 2 v roce Umožňovala provádění základních SQL příkazů bez podpory transakcí. Ty byly implementovány v následující verzi Oracle 3 v roce 1981, následované podporou MVCC v Oracle 4 o tři roky později. Další výrazný pokrok nastal v roce 1988, kdy Oracle 6.0 zavedl uzamykání na úrovni řádků bez eskalace pro úroveň izolace read committed (čtení tabulek v úrovni izolace serializable však vyžadovalo uzamčení celé tabulky ve sdíleném režimu) a současně doplnil do mechanismu MVCC podporu B-tree indexů. Řada 7 v letech přinesla mnoho významných změn. Přímo ve verzi 7.0 byla implementována podpora distribuovaných transakcí a dvoufázového commitu. Od verze již úroveň izolace serializable nevyžadovala při čtení tabulky její uzamčení ve sdíleném režimu [12]. V dalších verzích rostl počet nových databázových funkcí ještě rychlejším tempem, ale základní mechanismus konkurenčního přístupu se již neměnil. Až v roce 2001 verze přinesla novou funkcionalitu (Flashback query) založenou na MVCC, která umožňuje přímo pomocí SQL dotazů přistupovat k minulým verzím dat obsažených v UNDO tablespace. Tento koncept byl ve verzi 11gR1 (2007) rozšířen o možnost specifikovat archiv, ve kterém jsou historické verze dat udržovány, a čas, po který je jejich zachování garantováno; rozšíření je nazváno Total recall [13, 14]. 1 Databáze MySQL umožňovala až do verze 5.1 i použití BerkeleyDB, storage engine, která sice byla transakční, ale spravovala data jako key/value store, nikoliv jako relační databázi. 30

31 PostgreSQL Databáze PostgreSQL vznikla pod jménem Postgress v letech 1986 až 1994 na Kalifornské univerzitě v Berkeley jako projekt navazující na databázi Ingress vyvinutou dříve tamtéž (odtud také pochází jméno Postgress, ve významu nástupce Ingress ). Během této doby byla z tohoto projektu odvozena komerční databáze Illustra, jejíž nástupce Informix byl zakoupen a dodnes je provozován firmou IBM. V roce 1995 byl dotazovací jazyk POSTQUEL nahrazen dialektem SQL, a při té příležitosti byl název systému změněn na Postgres95. Následující rok převzala další vývoj systému mezinárodní skupina developerů a naposledy došlo ke změně jména na současný název PostgreSQL. Verze 6.0 vydaná v roce 1997 bývá označována jako počátek moderního systému PostgreSQL [15]. Tato verze stále ještě řešila konkurenční přístup pomocí zamykání tabulek, mechanismus MVCC byl implementován až v roce 1999 ve verzi 6.5. Verze 7.1 vydaná o dva roky později doplnila mechanismus Write Ahead Logging urychlující provádění commitů a umožňující zotavení databáze i v případě poškození primárních datových souborů. Rok 2005 přinesl verzi 8.0 umožňující částečný rollback aktivní transakce pomocí savepoints, a verzi 8.1 podporující distribuované transakce (mechanismus two-phase commit (2PC)). Poslední, zato velmi významnou změnou na poli mechanismů konkurenčního přístupu bylo zavedení SSI ve verzi 9.1 v roce 2011 [16]. 3.2 MS SQL Server Tato kapitola byla zpracována podle [17], není-li uvedeno jinak. Při svém vzniku využívala databáze MS SQL Server (dále jen SQL Server) jako mechanismus izolace transakcí výhradně uzamykání. Proto dodnes poskytuje poměrně bohaté možnosti konfigurace a ladění uzamykacích mechanismů, a samozřejmě možnost explicitního uzamykání záznamů. Uzamykání vyplývající z aktuální úrovně izolace transakcí lze navíc modifikovat pomocí tzv. table hint, doplňujících instrukcí začleněných do textu SQL dotazů. Pro dosažení serializace transakcí jsou dostupné zámky nad indexy (key-range zámky) poskytující funkcionalitu predikátových zámků. Alokované zámky jsou však udržovány v paměti, a SQL Server proto provádí eskalaci zámků podle potřeby. Jedním z častých problémů implementací založených na zámcích je situace, ve které dvě transakce nejprve přečtou stejný řádek, a poté se jej obě pokusí modifikovat. Při přečtení je alokován sdílený zámek, zatímco následný update vede ke konverzi na exkluzivní zámek. V této situaci nastává deadlock, neboť ani jedna transakce nemůže sdílený zámek uvolnit, a žádná rovněž nemůže získat exkluzivní zámek. SQL Server proto definuje další režim uzamčení, nazývaný Update lock. Update zámky jsou kompatibilní se sdílenými zámky, ale kolidují jak s exkluzivními, tak i s update zámky. Transakce, která plánuje nejprve přečíst a následně aktualizovat nějaký řádek, by proto měla řádek při čtení uzamknout v režimu update. To umožní alokaci sdílených zámků transakcemi, které jej budou pouze číst, ale zabrání souběhu s transakcemi, které daný řádek plánují také aktualizovat. Update zámek lze alokovat například s využitím výše zmíněného table hint SELECT... WITH(UPDLOCK). Jednotlivé operace prováděné transakcemi jsou zapisovány do transakčního logu (Transaction log), který slouží jak pro zrušení provedených operací v případě rollbacku, tak i pro zajištění integrity databáze v případě havárie systému nebo poškození primárních datových souborů. Transakční log tedy obsahuje data, která některé jiné databáze systémy ukládají odděleně jako tzv. undo a redo. 31

32 SQL Server poskytuje pro izolaci transakcí i mechanismus MVCC. Rekonstrukce dřívějších verzí dat probíhá na úrovni řádků. SQL Server pro tyto účely nicméně nevyužívá transakční log, ale speciální datové úložiště nazývané version store uložené v systémové databázi tempdb. V něm jsou uloženy všechny dřívější verze řádků. Při aktualizaci dat je v metadatech řádku uložen ukazatel na předchozí verzi ve version store; všechny dostupné verze řádku jsou tak uspořádány do spojového seznamu. Verze jsou označeny sekvenčním číslem transakce (transaction sequence number, XSN), které je přidělováno na začátku transakce [18]. Kapacita version store je ovšem omezená a příkazy v transakcích, které využívají mechanismus MVCC, mohou skončit s chybou při čtení dat způsobenou nedostupností předchozích verzí řádků. SQL Server poskytuje všechny úrovně izolace definované ANSI standardem, tj. read uncommitted, read committed, repeatable read i serializable. Navíc je poskytována úroveň izolace snapshot. Na rozdíl od jiných databázových systému není poskytována podpora pro explicitní označení transakcí jako read-only. Úroveň izolace read uncommitted Na této úrovni izolace mohou nastat všechny fenomény zmiňované ANSI standardem, tedy i fenomén dirty read. V rámci transakce jsou dostupné pro čtení veškerá data zapsaná do databáze, včetně dat necommitovaných transakcí. SQL Server při použití této úrovně izolace nealokuje žádné sdílené zámky, a proto není v principu zaručena ani konzistence přečtených dat. Pokud dojde během provádění příkazu SELECT například k přesunutí řádku na jiné místo, může se stát, že konkrétní řádek bude ve výstupu dotazu chybět, nebo bude naopak zpracován dvakrát. Při čtení položek, které jsou uloženy na více než jedné stránce (např. dostatečně dlouhá hodnota VARCHAR), mohou být přečteny hodnoty jednoho sloupce zachycené uprostřed aktualizace prováděné jinou transakcí, a tedy nekonzistentní (viz [19]). Úroveň izolace read committed Chování SQL Serveru na této úrovni izolace se řídí příznakem READ_COMMITTED_SNAPSHOT. Je-li tento příznak neaktivní (výchozí stav), jsou data po dobu provádění operace čtení uzamčena pomocí sdílených zámků, jak ilustruje příklad 3.1. Při aktivaci příznaku READ_COMMITTED_SNAPSHOT 2 je místo sdílených zámků využíván pro čtení dat mechanismus MVCC, a databáze poskytuje příkazům, které data pouze čtou, snapshot platný k okamžiku zahájení vykonávání dotazu. Při zpracování příkazů modifikujících data probíhá čtení v aktuálním režimu (jsou tedy čtena poslední commitovaná data), jak demonstruje příklad Příznak je nutné nastavit v databázi, která není systémovou databází, například takto: CREATE DATABASE MSSQL; GO USE MSSQL; GO ALTER DATABASE CURRENT SET READ_COMMITTED_SNAPSHOT ON; GO 32

33 Příklad 3.1: SQL Server: sdílené zámky v úrovni izolace read committed Připojení P 1 Připojení P 2 -- Provést v obou připojeních SET IMPLICIT_TRANSACTIONS ON; SET TRANSACTION ISOLATION LEVEL READ COMMITTED; GO CREATE TABLE T(N INT PRIMARY KEY); GO SELECT * FROM T; GO -- Čeká na commit v připojení 2 -- N INSERT INTO T VALUES(1); GO COMMIT; GO Příklad 3.2: SQL Server: snapshot v úrovni izolace read committed Připojení P 1 Připojení P 2 -- Provést v obou připojeních SET IMPLICIT_TRANSACTIONS ON; SET TRANSACTION ISOLATION LEVEL READ COMMITTED; GO CREATE TABLE T2(N INT); INSERT INTO T2 VALUES(1); INSERT INTO T2 VALUES(2); COMMIT; GO UPDATE T2 SET N = N + 1; GO COMMIT; GO DELETE FROM T2 WHERE N = 2; GO -- Čeká na commit v připojení 1 SELECT * FROM T2; GO -- N

34 Úroveň izolace repeatable read Úroveň izolace repeatable read je v SQL Serveru implementována zcela standardně pomocí uzamykání. Při čtení řádků jsou alokovány sdílené zámky držené až do konce transakce. Nejsou však alokovány key-range zámky, což umožňuje výskyt fenoménu phantom. Úroveň izolace snapshot Tato nestandardní úroveň izolace zpřístupňuje transakcím mechanismus SI. Pro jeho využití je nutné nastavit databázový příznak ALLOW_SNAPSHOT_ISOLATION. 3 Všechna data jsou čtena ze snapshotu vytvořeného na začátku transakce. Konflikt mezi transakcemi při zápisu dat je řízen principem First writer wins: transakce, která ze pokouší modifikovat záznam jako druhá, čeká na výsledek konfliktní transakce a pokud ta úspěšně commituje, je čekající transakce zrušena s chybou Msg Snapshot isolation transaction aborted due to update conflict. Databázová aplikace tedy musí být připravena opakovat transakce, které selhaly. Příkazy provádějící aktualizaci dat nicméně i v této úrovni izolace čtou data v aktuálním režimu stejně jako v případě read committed snapshotu (příklad 3.3). Úroveň izolace serializable Úroveň izolace serializable je v SQL Serveru implementována pomocí protokolu striktního dvoufázového uzamykání, včetně využití predikátových zámků ve formě key-range zámků nad indexy. 3.3 MySQL Tato kapitola byla zpracována podle [20, 10], není-li uvedeno jinak. Jak již bylo stručně zmíněno v kapitole o historii databázových systémů, MySQL umožňuje použití různých storage engines, zaměnitelných modulů, které řídí způsob ukládání a správy dat v databázi. Výchozí a nejvíce rozšířenou možností je InnoDB, která je distribuována společně se systémem. Pouze tato engine poskytuje plnohodnotnou implementaci izolací transakcí. 4 Podpora zaměnitelných systémů pro správu dat vede k některým zvláštnostem implementace MySQL, například i v nedistribuovaném prostředí mohou být transakce ukončovány pomocí dvoufázového commitu, pokud se jich účastnily alespoň dva různé storage enginy. Ty navíc mohou implementovat izolace transakcí různým způsobem, což může vést k velmi komplikovanému chování. Nadále bude proto uvažována pouze situace, kdy je pro realizaci transakcí využívána výhradně InnoDB. Určitou zvláštností InnoDB je způsob organizace dat v tabulkách. Ty jsou vždy realizovány formou cluster indexu založeného na primárním klíči (nebyl-li primární klíč 3 Příznak je nutné nastavit v databázi, která není systémovou databází, například takto: ALTER DATABASE CURRENT SET ALLOW_SNAPSHOT_ISOLATION ON; GO 4 XtraDB, storage engine odvozená od InnoDB, je využívána v některých klonech systému MySQL, ale v základních rysech se s InnoDB shoduje. 34

35 Příklad 3.3: SQL Server: úroveň izolace snapshot Připojení P 1 Připojení P 2 -- Provést v obou připojeních SET IMPLICIT_TRANSACTIONS ON; SET TRANSACTION ISOLATION LEVEL SNAPSHOT; GO CREATE TABLE T3(N INT PRIMARY KEY); COMMIT; SELECT * FROM T3; GO -- (0 rows affected) SELECT * FROM T3; GO -- (0 rows affected) INSERT INTO T3 VALUES(1); COMMIT; GO -- (1 rows affected) UPDATE T3 SET N=2 WHERE N=1; GO -- Příkaz selže z důvodů konfliktu -- (Msg 3960) Příkaz UPDATE v připojení P 1 nalezl a zjistil kolizi s řádkem, který byl commitován jinou transakcí až po vytvoření snapshotu P 1. SQL Server tuto situaci vyhodnotí jako kolizi a transakci zruší, což je korektní; řádek vytvořený v připojení P 2 by však ve snapshotu transakce P 1 neměl být vůbec viditelný. 35

36 určen při vytváření tabulky, InnoDB vytvoří náhradní klíč založený na unikátních ID řádků). Všechny ostatní indexy jsou pak realizovány formou sekundárních indexů, které se odkazují na primární klíč tabulky. InnoDB poskytuje mechanismus MVCC, který dle dostupné dokumentace pracuje na úrovni řádků. Každý řádek obsahuje identifikátor transakce, která řádek vložila, upravila nebo zrušila. Navíc je obsažen ukazatel do rollback segmentu, datové struktury, která obsahuje data potřebná k rekonstrukci dřívějších verzí řádků. Aktualizace řádku je interně realizována jako odstranění starého a vložení nového řádku. Odstraněné řádky zůstávají součástí tabulky i sekundárních indexů i po skončení transakce a jsou periodicky odstraňovány procesem purge. Index-only scan (v kontextu InnoDB nazývaný covering index) je možný v případech, kdy žádná z aktivních transakcí nemodifikovala index, v opačném případě musí mechanismus MVCC využít metadata řádků uložená v tabulce. Veškeré informace potřebné pro rekonstrukci předchozích verzí dat jsou systémem udržovány do doby, než skončí všechny transakce, které by tyto informace mohly využít; v systému InnoDB proto nemůže dojít k chybě mechanismu MVCC při vytváření konzistentního obrazu databáze. InnoDB poskytuje databázovým klientům poměrně široké možnosti implicitního i explicitního uzamykání: jsou podporovány sdílené i exkluzivní zámky, a to jak na úrovni řádků, tak i formou gap, next-key a insert intention zámků. Za některých okolností může dojít i k tomu, že InnoDB nedokáže detekovat existující uváznutí (deadlock). V tomto případě je využit mechanismus zrušení transakcí, které při čekání překročily časový limit. MySQL při využití InnoDB poskytuje všechny úrovně izolace definované ANSI standardem, tj. read uncommitted, read committed, repeatable read i serializable. Při použití každé úrovně izolace lze navíc transakci deklarovat jako read-only. Consistent reads a Locking reads Komponenta InnoDB přistupuje k datům v zásadě jedním ze dvou možných způsobů: Consistent Nonlocking Reads: přístup založený na mechanismu MVCC, kdy databáze pracuje s konzistentními snapshoty. Pro každý příkaz je definován pohled na commitovaná data v databázi k určitému časovému okamžiku a pomocí dat z rollback segmentů jsou data jednotlivých řádků rekonstruována k tomuto okamžiku dle potřeby. Režim je dostupný pouze pro příkazy SELECT nevyžadující uzamčení (varianty SELECT... FOR UPDATE a SELECT... LOCK IN SHARE MODE uzamčení vyžadují) na úrovních izolace read committed a repeatable read. Jak vyplývá i z názvu mechanismu, při čtení dat tímto způsobem nejsou alokovány žádné zámky. Locking Reads: režim, ve kterém příkazy přistupují k poslední existující verzi každého řádku, tedy mimo mechanismus MVCC. Koordinace operací na úrovni necommitovaných řádků je zajištěna pomocí exkluzivních a sdílených zámků. Tento mechanismus je tedy využíván všemi aktualizačními příkazy a příkazy SELECT vyžadujícími uzamčení. Při použití úrovně serializable probíhají všechny přístupy k datům touto formou, tedy i v případě příkazů SELECT nepožadujících explicitně uzamčení dat. Locking Reads provádí implicitní uzamykání dat sdíleným nebo exkluzivním zámkem podle potřeby. 36

37 Čtení dat na úrovni izolace read uncommitted je odlišné od obou popsaných režimů, v podstatě se však jedná o režim Locking reads, ve kterém nejsou alokovány sdílené zámky. Úroveň izolace read uncommitted Na této úrovni izolace může nastat dirty read transakce může přečíst nebo dokonce zahájit modifikaci řádku, který dosud nebyl jinou transakcí commitován. V případě modifikace se však čeká na dokončení kolidující transakce, neboť při modifikaci řádku se vždy alokují exkluzivní zámky. Chování systému v této úrovni izolace při provedení příkazů COMMIT a ROLLBACK je ilustrováno na příkladu 3.4. Příklad 3.4: MySQL: úroveň izolace read uncommitted a fenomén dirty read Připojení P 1 Připojení P 2 -- Provést v obou připojeních SET AUTOCOMMIT = 0; SET SESSION INNODB_LOCK_WAIT_TIMEOUT = 3600; SET SESSION TRANSACTION ISOLATION LEVEL READ UNCOMMITTED; CREATE TABLE T(N INTEGER PRIMARY KEY); SELECT * FROM T; -- Vrátí řádek s ID 1 INSERT INTO T VALUES(1); UPDATE T SET N=2 WHERE N=1; -- Čeká na commit v připojení 2 -- Rows matched: 1 Changed: 1 UPDATE T SET N=11 WHERE N=10; -- Čeká na rollback v připojení 2 -- Rows matched: 0 Changed: 0 COMMIT; INSERT INTO T VALUES(10); ROLLBACK; Databázové aplikace mají na této úrovni izolace k dispozici nejvyšší výkon při čtení dat, za předpokladu, že výskyt fenoménu dirty read je pro aplikaci přijatelný. Úroveň izolace read committed Na této úrovni izolace se využívá režim Consistent nonlocking reads popsaný výše. Jednotlivé příkazy SELECT pracují se snapshotem, který je platný k okamžiku zahájení provádění dotazu. DML příkazy však využívají Locking reads viz příklad 3.5. Dojde-li při aktualizaci některého řádku ke kolizi s aktivní transakcí, InnoDB nejprve vyhodnotí podmínku WHERE s použitím poslední commitované verze řádku. Je-li podmínka splněna, příkaz čeká na dokončení zpracování řádku transakcí, která s příkazem koliduje. Po commitu nebo rollbacku je výsledná verze řádku předána ke zpracování čekajícímu příkazu (příklad 3.6). 37

38 Příklad 3.5: MySQL: Locking Reads v úrovni izolace read committed (1) Připojení P 1 Připojení P 2 -- Provést v obou připojeních SET AUTOCOMMIT = 0; SET SESSION INNODB_LOCK_WAIT_TIMEOUT = 3600; SET SESSION TRANSACTION ISOLATION LEVEL READ COMMITTED; CREATE TABLE T(N INTEGER PRIMARY KEY); SELECT * FROM T; -- Empty set (0.00 sec) INSERT INTO T VALUES(1); UPDATE T SET N=2 WHERE N=1; -- Čeká na commit v připojení 2 -- Rows matched: 1 Changed: 1 SELECT * FROM T; N row in set COMMIT; Příklad 3.6: MySQL: Locking Reads v úrovni izolace read committed (2) Připojení P 1 Připojení P 2 -- Provést v obou připojeních SET AUTOCOMMIT = 0; SET SESSION INNODB_LOCK_WAIT_TIMEOUT = 3600; SET SESSION TRANSACTION ISOLATION LEVEL READ COMMITTED; CREATE TABLE T2(N INTEGER); INSERT INTO T2 VALUES(1); INSERT INTO T2 VALUES(2); COMMIT; UPDATE T2 SET N = N + 1; COMMIT; DELETE FROM T2 WHERE N = 2; -- Čeká na commit v připojení 1 SELECT * FROM T2; N row in set (0.00 sec) V případě kolize příkazu s jinou transakcí (zde v připojení P 2 ) jsou po provedení commitů všechny kolidující zápisy provedené příkazem efektivně řazeny před nebo za zápisy stejných řádků provedené kolidující transakcí. Kdyby tomu tak nebylo, dojde vzhledem k alokaci exkluzivních zámků k deadlocku a alespoň jedna z transakcí bude zrušena. 38

39 Úroveň izolace repeatable read Repeatable read představuje v InnoDB výchozí úroveň izolace transakcí. Při této úrovni izolace je na začátku transakce vytvořen snapshot a přístupy pomocí konzistentního čtení využívají data z tohoto snapshotu. Stejně jako v předchozích úrovních izolace, aktualizační příkazy pracují s poslední commitovanou verzí řádku, což může vést k výskytu fenoménu phantom. Toto chování není v rozporu s ANSI standardem, neboť na úrovni repeatable read je výskyt phantom explicitně povolen, nicméně to znamená, že tato úroveň izolace je slabší než izolace poskytovaná mechanismem SI (viz příklad 3.7). Příklad 3.7: MySQL: úroveň izolace repeatable read Připojení P 1 Připojení P 2 -- Provést v obou připojeních SET AUTOCOMMIT = 0; SET SESSION INNODB_LOCK_WAIT_TIMEOUT = 3600; SET SESSION TRANSACTION ISOLATION LEVEL REPEATABLE READ; CREATE TABLE T3(N INTEGER PRIMARY KEY); SELECT * FROM T3; -- Empty set (0.00 sec) SELECT * FROM T3 FOR SHARE; N row in set SELECT * FROM T3; -- Empty set (0.00 sec) UPDATE T3 SET N=2 WHERE N=1; -- Rows matched: 1 Changed: 1 SELECT * FROM T3; N row in set (0.00 sec) INSERT INTO T3 VALUES(1); COMMIT; První příkaz SELECT v připojení P 1 slouží k zahájení transakce a vytvoření snapshotu. Poté je do tabulky vložen a commitován řádek v připojení P 2. Další dva příkazy SELECT ilustrují rozdíl mezi Locking read a Consistent read pouze první z nich přečte řádek commitovaný jinou transakcí (fenomén phantom). Dále je ukázáno, že řádek je dostupný i pro příkaz UPDATE. Od této chvíle je řádek součástí aktuální transakce (byl aktualizován aktuální transakcí a ta vždy vidí změny, které provedla), a je tedy zobrazen i posledním příkazem SELECT, provedeným v konzistentním režimu. Z uvedeného příkladu dále vyplývá, že na této úrovni izolace nejsou detekovány konflikty mezi transakcemi. MySQL chybu selhání serializace transakcí vyžadovanou mechanismem SI vůbec nezná. V důsledku toho může dojít i k fenoménu lost update. 39

40 Úroveň izolace serializable V úrovni izolace serializable není mechanismus MVCC vůbec využíván, všechny SQL příkazy pracují v režimu Locking reads. Interně jsou všechny příkazy SELECT prováděny, jako by byly spuštěny s klauzulí FOR SHARE. Výsledkem je implementace protokolu dvoufázového zamykání. Výskytu fenoménu phantom z předchozí ukázky je bráněno pomocí blokování, jak demonstruje příklad 3.8. Příklad 3.8: MySQL: úroveň izolace serializable Připojení P 1 Připojení P 2 -- Provést v obou připojeních SET AUTOCOMMIT = 0; SET SESSION INNODB_LOCK_WAIT_TIMEOUT = 3600; SET SESSION TRANSACTION ISOLATION LEVEL SERIALIZBLE; CREATE TABLE T4(N INTEGER PRIMARY KEY); SELECT * FROM T4; -- Empty set (0.00 sec) COMMIT; SELECT * FROM T4; -- Čeká na commit v připojení N row in set (10.80 sec) INSERT INTO T4 VALUES(1); -- Čeká na commit v připojení 1 -- Query OK, 1 row affected (7.57 sec) COMMIT; V InnoDB tedy nemůže dojít k selhání serializace známému z úplné implementace protokolu SI, ale databázová aplikace musí být v každém případě připravena opakovat transakce, které selhaly v důsledku deadlocku. Read only transakce Označení transakce příznakem READ ONLY je možné na každé úrovni izolace. Takto označené transakce nemohou provádět žádné změny v databázi a InnoDB pro ně ani nealokuje identifikátor transakce, ani je nezařazuje do některých interních datových struktur. Dokumentace uvádí, že tato úspora systémových prostředků může být významná. 3.4 Oracle Tato kapitola byla zpracována podle [21, 22], není-li uvedeno jinak. Databázový systém Oracle používá pro zajištění konkurenčního přístupu mechanismus multiversion concurrency control. Ten je implementován na úrovni datového bloku. V okamžiku, kdy databáze přistupuje k nějakému bloku, zjišťuje, zda byl tento 40

41 blok modifikován způsobem porušujícím konzistentní pohled na data čtená prováděným dotazem. Pro zaznamenání okamžiku, kdy byl datový blok modifikován, je používán čítač System Change Number (SCN), jehož hodnota odpovídající času poslední modifikace je uložena v záhlaví bloku. Při každém commitu je hodnota tohoto čítače zvýšena. V okamžiku zahájení transakce nebo dotazu je aktuální systémová hodnota SCN zaznamenána a obraz databáze konzistentní vůči této hodnotě je zprostředkován dotazům. V případě potřeby je na základě dat uložených v UNDO tablespace zrekonstruován obraz bloku platný k okamžiku určenému příslušným SCN (viz obr. 3.2). Tímto způsobem zrekonstruovaný blok (nazývaný consistent read clone konzistentní klon) je pak uložen do buffer cache a dále dotazem zpracován standardním způsobem. Obrázek 3.2: Oracle: rekonstrukce bloků vůči požadovanému SCN Zdroj: [21, s. 9-4] Rekonstruování dřívějšího obrazu dat na úrovni datových bloků přináší velkou výhodu: tentýž mechanismus lze využít pro přístup k tabulkám, indexům i dalším strukturám uloženým v datových blocích. 5 Výjimku představují pouze objekty LOB (viz LOB, str. 71 v příloze A). Postup rekonstrukce dřívější verze bloku probíhá takto (ne nutně v uvedeném pořadí): Pomocí dat z UNDO tablespace jsou revertovány změny provedené všemi aktivními transakcemi, které blok modifikovaly (samozřejmě s výjimkou aktuální 5 Nejedná se však o triviální mechanismus, a to zejména v případě indexů. Andrew Mendelsohn, který tento mechanismus navrhl a implementoval pro B-tree indexy, tuto práci označil za technicky nejnáročnější v celé své kariéře ve společnosti Oracle [14, s. 17]. 41