BAKALÁŘSKÁ PRÁCE NewSQL architektura databázových systémů · 1 Úvod do problematiky, motivace k hledání nových způsobů zpracování dat v databázových systémech Puůvodníá

UNICORN COLLEGE

Katedra informačních technologií

BAKALÁŘSKÁ PRÁCE

NewSQL architektura databázových systémů

Autor BP: Jakub Angelis

Vedoucí BP: Ing. Michal Kökörčený, Ph. D.

2017 Praha

Čestné prohlášení

Prohlaššuji, žše jšem švou bakalaá ršškou praá ci na teáma NewSQL architektura databaá žovýách šýšteámuů výpracoval šamoštatneš pod vedeníám vedoucíáho bakalaá ršškeá praáce a š použš itíám výáhradneš odborneá literaturý a dalššíách informacšníách ždrojuů , ktereá jšou v praáci citovaáný a jšou takeá uvedený v šežnamu literaturý a použš itýách ždrojuů .

Jako autor teá to bakalaá ršškeá praá ce daá le prohlaššuji, žše v šouvišlošti š jejíám výtvoršeníám jšem neporuššil autorškaá praáva tršetíách ošob a jšem ši plneš vešdom naá šledkuů poruššeníá uštanoveníá § 11 a naá šledujíácíách autorškeáho žaákona cš. 121/2000 Sb.

V Praže dne 01.05.2017 .........................................................................Jakub Angeliš

Poděkování

Chteš l bých podeškovat vedoucíámu bakalaá ršškeá praá ce Ing. Michalu Koö koö rcšeneámu, Ph. D. ža odborneá vedeníá a dalššíá cenneá radý prši žpracovaáníá meá bakalaá ršškeá praá ce.

Daá le bých raád podeškovat šveá rodineš ža vššeštrannou podporu a Lence ŽŽ ihloveá ža pomoc š jažýkovou korekturou.

NewSQL architektura databázových systémů

NewSQL database systems architecture

- 6 -

Abstrakt

NewSQL databaá že tvoršíá škupinu novýách výšoce šškaá lovatelnýách tranšakcšníách databaá žovýách šýšteámuů . Tato praá ce ši klade ža cíál prožkoumat motivace vžniku tohoto týpu databaá žíá, porovnat naávrh tešchto šýšteámuů š tradicšníámi databaá žemi a NoSQL databaá žemi a rožebrat hlavníá probleámoveá domeáný prši naávrhu databaá žoveáho šýšteámu. Jednaá še žejmeána o možšnošt šškaá lovaáníá, žajišštešníá konžištence dat a výšokou doštupnošt.

V praáci jšou popšaáný projektý žaštupujíácíá hlavníá šmešrý prši navrhovaáníá NewSQL databaá žovýách šýšteámuů . Jšou žde rožebraáný šilneá a šlabeá štraánký jednotlivýách pršíáštupuů a vhodnošt použš itíá tešchto NewSQL databaá žíá pro jednotliveá týpý aplikacíá.

Žaávešr praáce je žamešršen na nejnoveš jšš íá výážkumý v oblašti NewSQL databaá žovýách šýšteámuů , šmešrovaáníá jednotlivýách projektuů a jejich dalšš íá možšnýá výávoj.

Klíčová slova: NewSQL, OLTP, databaá že, šškaá lovaáníá, CAP teoreám

Abstract

NewSQL databašeš are the new týpe of highlý šcalable tranšactional databaše šýštemš. The aim of thiš bachelor thešiš iš to examine the motivation of šuch databaše šýštemš. It will compare the dešign of theše šýštemš with traditional RDBMS and NoSQL databašeš. It will focuš on main problemš in dešigning šuch šýštemš, i.e. šcalabilitý, conšištencý and high availabilitý.

Thiš thešiš dešcribeš main directionš in dešigning NewSQL databašeš. It will addrešš the proš and conš of individual approacheš and the ušage šuitabilitý of theše NewSQL databašeš in špecific týpe of applicationš.

Lašt chapter iš focušed on the latešt advancement in NewSQL development, the heading of individual projectš and their poššible further evolution.

Keywords: NewSQL, OLTP, databaše, šcale-out, CAP theorem

- 7 -

Obsah

ÚÚ vod ....................................................................................................................................................... 91 ÚÚ vod do problematiký, motivace k hledaáníá novýách žpuů šobuů žpracovaáníá dat

v databaá žovýách šýšteámech ................................................................................................. 111.1 Definice pojmuů .................................................................................................................... 12

2 Tranšakcšníá žpracovaáníá v relacšníách databaá žíách, v NoSQL databaá žíách a v NewSQL databaá žíách; dištribuovaneá šýšteámý a probleám CAP teoreámu ............................... 14

2.1 Dištribuovaneá šýšteámý .................................................................................................... 162.1.1 Dištribuovanýá databaá žovýá šýšteám ......................................................................17

2.2 CAP teoreám .......................................................................................................................... 172.3 Tranšakcšníá žpracovaáníá v NoSQL databaá žíách ...........................................................182.4 Tranšakcšníá žpracovaáníá v NewSQL databaá žíách .......................................................192.5 Charakterištika tranšakcšníá žaá tešžše ..............................................................................19

3 NewSQL databaá že – principý, architektura, použš itíá ................................................... 213.1 In-memorý databaá že ........................................................................................................ 213.2 Oddeš leníá tranšakcšníá logiký od peržištentníáho uložšeníá .......................................213.3 Dvoufaá žoveá žamýkaáníá - 2-phaše locking (2PL) ......................................................213.4 Multiveršion Concurrencý Control (MVCC) ............................................................223.5 Dvoufaá žovýá commit - 2-phaše commit (2PC) .........................................................223.6 Paxoš ....................................................................................................................................... 233.7 MapReduce ........................................................................................................................... 263.8 Optimaližace dotažuů ......................................................................................................... 273.9 Automatickýá šharding ..................................................................................................... 283.10 Použš itíá ................................................................................................................................. 28

4 Sýšteámý žaložšeneá na NewSQL architekturše .................................................................. 304.1 Google Spanner/F1 ........................................................................................................... 304.2 NuoDB .................................................................................................................................... 324.3 VoltDB .................................................................................................................................... 334.4 CluštrixDB ............................................................................................................................ 354.5 MemSQL ................................................................................................................................ 364.6 ScaleBaše .............................................................................................................................. 384.7 ScaleDB .................................................................................................................................. 394.8 Oštatníá .................................................................................................................................... 40

4.8.1 dbShardš ........................................................................................................................ 404.8.2 CockroachDB ................................................................................................................ 404.8.3 Apache Trafodion ....................................................................................................... 414.8.4 SAP HANA ...................................................................................................................... 414.8.5 TIBCO ActiveSpaceš ................................................................................................... 41

5 Trendý ve výávoji v oblašti NewSQL databaá žíá ................................................................ 42Žaávešr ................................................................................................................................................... 45Sežnam použš itýách ždrojuů ........................................................................................................... 47Sežnam obraá žkuů ............................................................................................................................. 51Sežnam tabulek .............................................................................................................................. 52Sežnam použš itýách žkratek ......................................................................................................... 53

- 8 -

Úvod

V šoucšašneám šveš teš jšou jižš vššechna noveš výtvoršenaá data uložšena digitaá lneš v pocšíátacšovýách šýšteámech. Množšštvíá tešchto dat naruů štaá teámešrš exponenciaá lneš a výáhledý praktický vššech analýtikuů še v pohledu na tento trend vžaá cneš šhodujíá.

V kažšdeá šoukromeá špolecšnošti jižš neškolik let dochaá žíá k digitaližaci vešškerýách agend a teámešrš vššechna data šoukromýách špolecšnoštíá jšou jižš uložšena v pocšíátacšovýách šýšteámech.

Staá tníá špraáva, býť š lehkýám odštupem, naá šleduje šoukromýá šektor.

Sociaá lníá šíáteš jšou novýám fenomeánem, kterýá jižš výužš íávaá teámešrš tršetina šveš toveá populace a množšštvíá dat žde uklaádanýách je obrovškeá .

Aktuaá lnošti takeá nabýávaá noveá teáma – Internet vešcíá (Internet of Thingš). Dle neškterýách odhaduů bude ža neškolik let teámešrš jakeákoli žaršíáženíá pršipojeneá k Internetu a bude generovat a uklaádat velkeá množšštvíá dat.

Neníá to tak daávno, co veš tšš ina tešchto šýšteámuů šloužš ila cšišteš pro uklaádaáníá lidmi výtvoršenýách dat a naá šledneá poškýtnutíá opeš t lidem, kteršíá je daá le použš ili, cši nad nimi žpracovali dalšš íá analýážý.

S roštoucíám množšštvíám uložšenýách dat, š ruů štem výápocšetníáho výákonu pocšíátacšovýách šýšteámuů , š výávojem novýách analýtickýách proštršedkuů a š tlakem na žpracovaáníá dat a poškýtovaáníá výášledkuů v reaá lneám cšaše je nežbýtneá hledat takoveá pršíáštupý, poštupý, metodý a proštršedký, ktereá toto všše nejen umožšníá, ale budou žaá rovenš šloužš it jako žaáklad pro rožvoj novýách aplikacíá.

Jednou ž nežbýtnýách komponent pro takoveá to aplikace je šýšteám uklaádaáníá dat a jejich poškýtovaáníá ke žpracovaáníá. Toto býlo dlouhou dobu praktický výá lucšneš ršeššeno tradicšníámi relacšníámi SQL databaá žemi. Nevýáhodou tešchto šýšteámuů je, žše podporujíá použe vertikaá lníá šškaá lovatelnošt (šcale-up), tedý týp šškaá lovaáníá, kdý še databaá že provožuje na výákonneš jšš íám hardwaru, a provožovaáníá na víáce pocšíátacšíách je špíášše pro výšokou doštupnošt nežš pro žvýáššeníá výákonu.

V duů šledku tohoto še žacšalý objevovat noveá týpý databaá žíá, šouhrnneš nažýávaneá NoSQL. Týto databaá že jšou žamešršeneá na ršeššeníá probleámuů , kde použš itíá tradicšníách relacšníách databaá žovýách šýšteámuů neníá optimaá lníá. Jde o velmi ruů žnorodeá aplikace, jejichžš jedníám výážnamnýám špolecšnýám žnakem je šnadnaá horižontaá lníá šškaá lovatelnošt (šcale-out). Vžhledem k CAP teoreámu, kterýá býl formulovaán žacšaá tkem mileánia, týto šýšteámý nepodporujíá tranšakcšníá ACID (Atomicitý, Conšištencý, Išolation, Durabilitý) žpracovaáníá, ale jejich pršíáštup je žaložšen na principu BASE (Bašicallý Available, Soft štate, Eventual conšištencý). Takeá jejich model uklaádaáníá dat neníá relacšníá, ale je volen podle žamešršeníá konkreá tníách databaá žíá.

- 9 -

Vžhledem k šširokeámu našaženíá a žnalošti tradicšníách relacšníách databaá žíá še ukažuje, žše v neškterýách šýšteámech je žšaádoucíá jednak výužš itíá ACID tranšakcíá a takeá výšokeá horižontaá lníá šškaá lovatelnošti. Proto býla tato oblašt podrobena pomešrneš velkeámu výážkumu a žrodilo še neškolik pršíáštupuů , ktereá še kažšdýá švýám žpuů šobem šnažš íá žajištit týto žaákladníá požšadavký.

Tato praá ce še žabýávaá tešmito šýšteámý, principiaá lníám naávrhem jednotlivýách ršeššeníá a vhodnošti jejich použš itíá v rožlicšnýách aplikacíách.

V praáci še výškýtuje velkeá množšštvíá anglickýách termíánuů a žkratek, ktereá nemajíá cšeškýá ekvivalent a jšou použš itý v puů vodníá formeš . Ú termíánuů , ktereá majíá cšeškýá pršeklad, je použš ita jejich cšeškaá verže.

- 10 -

1 Úvod do problematiky, motivace k hledání nových způsobů zpracování dat v databázových systémech

Puů vodníá databaá žoveá šýšteámý býlý provožovaáný na velkýách a drahýách pocšíátacšíách (týpický mainframech a minipocšíátacšíách) a býlý tedý urcšený pro velkeá špolecšnošti a štaá tníá inštituce. Žacšaá tkem šedmdešaá týách let 20. štoletíá dochaá žíá k formaližaci relacšníáho databaá žoveáho modelu E. F. Coddem [1, š. 1] a naá šledneámu výážkumu tešchto šýšteámuů . Koncem šedmdešaá týách let še objevujíá prvníá databaá žoveá šýšteámý poštaveneá na relacšníám modelu.

Dalššíám milníákem ve výávoji databaá žovýách šýšteámuů je pršedštaveníá protokolu HTTP a tedý žroženíá world wide webu (WWW). Straánký WWW býlý puů vodneš štatickeá a štroheá . Ale velmi bržý dochaá žíá k raketoveámu výávoji webovýách prežentacíá a možšnoštíá formaá tovaáníá jednotlivýách štraánek, štýlovaáníá. Nemeáneš duů ležš iteá je, žše dochaá žíá takeá k tvorbeš dýnamickýách štraánek, tedý štraánek tvoršenýách na šerveru ažš prši požšadavku od weboveáho klienta. Týto štraánký še veš tšš inou tvoršíá na žaákladeš uá dajuů uložšenýách v databaá ži.

V nejraneš jšš íá faá ži, ožnacšovaneá takeá web 1.0, býlo velmi maá lo lidíá, kteršíá výtvaá ršeli obšah. Týpický še jednalo o špecialižovaneá firmý nebo profešionaá lý na volneá nože, kteršíá tvoršili weboveá prežentace pro velkeá špolecšnošti, a žbýtek užš ivateluů býl cšišteš konžumentem tohoto obšahu. Pocšaá tkem 21. štoletíá dochaá žíá ke žjednoduššovaáníá tvorbý obšahu. Vžnikajíá noveá firmý, ktereá nabíážejíá štaá le jednodušššš íá proštršedíá pro šveá užš ivatele a praáveš tito užš ivateleá še štaávajíá tvuů rci obšahu. Vžnikaá tžv. web 2.0 [2, š. 1].

Vžnikaá enormníá množšštvíá malýách firem nabíážejíácíách šveá šlužšbý praáveš pro web 2.0. Týto firmý jšou ši podobneá v tom, žše majíá omeženýá pršíáštup ke kapitaá lu. V pršíápadeš uá špešchu firmý ovššem dochaá žíá k neuvešršitelneámu naá ruů štu pocštu užš ivateluů a tedý požšadavku na ruů št výákonu šýšteámu. Kvuů li omeženeámu rožpocštu týto firmý ršešš íá tento požšadavek týpický pršidaáníám komoditníáho hardwaru. Tomuto týpu navýáššeníá výákonu še ršíákaá horižontaá lníá šškaá lovaáníá, viž. daá le. Nešktereá komponentý šýšteámu še takto šškaá lujíá šnaá že, naprš. weboveá šerverý. Naopak u databaá žovýách šýšteámuů toto šškaá lovaáníá v teá dobeš nepršichaá želo v uá vahu a mušelo tedý dochaá žet k vertikaá lníámu šškaá lovaáníá.

S dalššíám rožvojem webovýách šlužšeb dochaá žíá k hledaáníá alternativ k tradicšníám relacšníám databaá žovýám šýšteámuů m a štaá le cšašteš ji še našažujíá a teštujíá NoSQL databaá že. Hlavníá pršednoštíá NoSQL databaá žíá je jejich výnikajíácíá horižontaá lníá šškaá lovatelnošt. Jejich hlavníá nevýáhodou je jejich žšaádnaá , nebo použe cšaá štecšnaá podpora tranšakcíá a puů vodneš takeá abšence štandardníáho dotažovacíáho výšokouá rovnš oveáho jažýka, tedý SQL.

NoSQL databaá že je velmi šš irokýá pojem a nejcšašteš ji býávajíá cšlenešný podle šveáho datoveáho modelu:

- 11 -

• Key-value stores - Týto šýšteámý fungujíá jako ašociativníá pole (pole klíácš-hodnota), tedý k užš ivatelšký žvoleneámu klíácši umožšnš ujíá uložš it neš jakou hodnotu. Klíácš mušíá býá t v databaá ži jedinecšnýá. Jednaá še o velmi jednoduchýá model a nešktereá šložš iteš jšš íá modelý jšou výštavešný praáveš nad tíámto modelem.

• Document stores – Jednaá še vlaštneš o podtršíádu uá ložš iššť klíácš-hodnota. Sloužš íá pro uchovaávaáníá cšaá štecšneš štrukturovanýách dat. Na roždíál od uá ložš iššť klíácš-hodnota ale týto databaá že uchovaávajíá i metadata, kteraá lže prohledaávat.

• Extensible record set – Neškdý še týto databaá že takeá nažýávajíá wide column store. Týto šýšteámý takeá použš íávajíá tabulký, ršaá dký a šloupce, ale na roždíál od tradicšníách relacšníách DBMS kažšdýá ršaá dek muů žše obšahovat jineá šloupce.

• Graph database – Jednaá še o databaá že, ktereá výužš íávajíá grafoveá štrukturý. Vedle vlaštníách dat, kteraá jšou uchovaávaána ve vrcholech, jšou uklaádaáný takeá hraný, tj. vžtahý meži jednotlivýámi vrcholý. Tý jednak mohou býá t orientovaneá , tedý jednošmešrneá , ale mohou býá t i neorientovaneá . Databaá že ke kažšdeá hraneš dokaá žše uložš it rožlicšneá vlaštnošti. Duů ležš itou vlaštnoštíá grafovýách databaá žíá je index free adjacency, tj. žše vžtahý še nevýhledaávajíá v tabulce, ale kažšdýá vrchol maá pršíámýá odkaž na hraný vedoucíá na dalšš íá vrcholý. Tato vlaštnošt dovoluje prochaá žet grafovou štrukturu v konštantníám cšaše O(1), bež ohledu na velikošt databaá že.

A pršeštožše v podnikovýách datovýách centrech jšou štaá le teámešrš výá lucšneš našažovaáný tradicšníá relacšníá SQL databaá že, ktereá tvoršíá žaákladníá podnikovaá datovaá uá ložš iššteš , tak žacšíánaá dochaá žet prši výávoji novýách aplikacíá k našažovaáníá takeá NoSQL databaá žíá.

Nemalaá cšaá št výávojaá ršuů ovššem vníámaá nedoštatký NoSQL databaá žíá jako pršíálišš žaá šadníá.

„Je výhodnější, aby se programátoři aplikací zabývali výkonnostními problémy, až když se objeví, kvůli přílišnému použití transakcí, než aby se snažili rovnou systém naprogramovat bez použití transakcí“ [3, š. 1].

A proto pršichaá žíá požšadavek na relacšníá databaá ži, kteraá bý žajiššťovala tradicšníá tranšakcšníá ACID pršíáštup, podporovala dobrše žnaámýá SQL jažýk a býla dobrše horižontaá lneš šškaá lovatelnaá . Tedý NewSQL databaá že [4, š. 2][5].

1.1 Definice pojmů

Jednoduchou operací rožumíáme žíáškaáníá klíácše, žapšaáníá nebo nacšteníá jednoho žaá žnamu nebo maleáho množšštvíá žaá žnamuů . Protikladem mohou býá t komplexníá dotažý nebo špojeníá (joiný). Naprš. aplikace, špadajíácíá do kategorie nažýávaneá Web 2.0, mohou prohledaávat nebo aktualižovat žaá žnamý ve velkeám pocštu databaá žíá jako jšou email, ošobníá profil, wiki, reklamý atd. Vššechný týto cšinnošti štaá le

- 12 -

špadajíá do teá to definice jednoduchýách operacíá, tedý cšteníá nebo žapšaáníá maleáho pocštu dat prši jedneá operaci [6, š. 2].

Horizontálním škálováním rožumíáme možšnošt rožložšeníá dat i žaá tešžše jednoduchýách operacíá meži množšštvíá šerveruů , ktereá nešdíálejíá procešorý ani pamešť RAM ani diškoveá uá ložš iššteš .

Vertikálním škálováním oproti tomu rožumíáme žvýššovaáníá výákonu žvýáššeníám pocštu jader a/nebo CPÚ, ktereá šdíálejíá pamešť RAM a diškoveá uá ložš iššteš .

Nešktereá šýšteámý umožšnš ujíá oboje šškaá lovaáníá, vertikaá lníá i horižontaá lníá.

Je tršeba upožornit, žše horižontaá lníá a vertikaá lníá roždeš leníá nemaá žšaádnýá vžtah k horižontaá lníámu a vertikaá lníámu šškaá lovaáníá, mimo to, žše obeš deš leníá še prši horižontaá lníám šškaá lovaáníá výužš íávajíá [6, š. 2].

Sharding je týp horižontaá lníáho roždeš leníá (horižontal partitioning), kdý je tabulka roždeš lena do neškolika menššíách tabulek na uá rovni celýách ršaádkuů . Horižontaá lníá roždeš leníá tabulký še provaádíá žejmeána pro žvýáššeníá výákonu. Prši hledaáníá, neníá potršeba prohledat celou velkou tabulku, ale štacšíá prohledat použe tabulku menššíá. Toto deš leníá je výáhodneá použe v pršíápadeš , pokud exištuje neš jakaá implicitníá robuštníá vlaštnošt, podle ktereá lže rožhodnout, kteraá tabulka še maá použš íát. Roždíál meži šhardingem a horižontaá lníám roždeš leníám je, žše horižontaá lníá roždeš leníá še provaádíá cšišteš ž duů vodu žmenššeníá velikošti indexu a jednotliveá tabulký žuů štaávajíá na štejneám užlu. Sharding še oproti tomu provaádíá žejmeána tak, abý jednotliveá tabulký býlý na roždíálnýách užlech a tedý, abý še kažšdaá tabulka žpracovaávala na jineám užlu a doššlo k rovnomešrneámu rožproštršeníá žaá tešžše meži vššechný užlý [7, š. 10].

- 13 -

2 Transakční zpracování v relačních databázích, v NoSQL databázích a v NewSQL databázích; distribuované systémy a problém CAP teorému

Databaá žoveá tranšakce šdružšujíá neškolik SQL pršíákažuů , ktereá mohou býá t ukoncšený uložšeníám (commit) nebo ukoncšený naávratem puů vodníách hodnot (rollback) [8, š. 8]. Tranšakce mohou býá t odvolaáný aplikacíá ž duů vodu naávratu puů vodníách hodnot, nebo šýšteámem, abý býla žajišštešna atomicita a ižolace.

Tranšakce mušíá žajištit naá šledujíácíá vlaštnošti:

A – Atomicita (atomicity) žnamenaá , žše na tranšakci mušíá býá t nahlíážšeno jako na jednotkovou operaci, tedý buď jšou provedený vššechný tranšakcšníá akce, nebo žšaádnaá . Atomicita výžšaduje, abý pokud dojde k pršeruššeníá tranšakce ž libovolneáho duů vodu, tak DBMS mušíá býá t šchopen prši žotaveníá rožhodnout co š tranšakcíá udeš lat.

Tranšakce muů žše v žaá šadeš šelhat že dvou duů voduů . Buď šelžše ž duů vodu nevalidníách vštupníách dat, deadlockuů nebo jinýách podobnýách chýb. Nebo tranšakce šelžše ž duů vodu šelhaáníá šýšteámu [9, š. 344].

C - Konzistence (consistency) tranšakce v podštateš žnamenaá jejíá špraávnošt. Jinýámi šlový tranšakce tranšformuje databaá ži ž jednoho konžištentníáho štavu do druheáho [10, š. 134].

Konžištence jako takovaá je cšlenešna do cštýrš uá rovníá (termíán mezivýsledek odkažuje na hodnotý dat, ktereá býlý tranšakcíá žmešnešný ješšteš pršed jejíám dokoncšeníám):

Stupenš 3: Tranšakci T je žajišštešn štupenš 3 konžištence, kdýžš :

1. T nepršepíášše meživýášledký oštatníách tranšakcíá.

2. T nežapíášše žšaádneá žmešný, dokud nedojde k ukoncšeníá tranšakce.

3. T nepršecšte meživýášledký jinýách tranšakcíá.

4. Oštatníá tranšakce nežacšnou modifikovat žšaádnaá data cštenaá T pršedtíám, nežš T škoncšíá.




3. T nepršecšte meživýášledký jinýách tranšakcíá.




- 14 -



Je žršejmeá , žše výšššš íá štupneš konžištence v šobeš automatický žahrnujíá nižšššíá štupneš konžištence. Duů vodem k žavedeníá tešchto uá rovníá je poškýtnutíá volnošti programaá toruů m prši definovaáníá tranšakcíá, ktereá fungujíá na ruů žnýách uá rovníách. Tedý žatíámco nešktereá tranšakce mohou fungovat na štupni 3, oštatníá mohou fungovat na nižššš íá uá rovni a mohou napršíáklad videš t meživýášledký jinýách tranšakcíá [9, š. 345].

I - Izolace (isolation), neškdý býávaá nažýávaána nežaávišloštíá, žnamenaá takovou vlaštnošt tranšakce, kteraá výžšaduje, abý kažšdaá tranšakce videš la celou dobu použe konžištentníá databaá ži. Jinýámi šlový špušštešníá tranšakce nemuů žše odhalit švoje meživýášledký šoubešžšnýám tranšakcíám pršed jejich dokoncšeníám (commit). Mohl bý totižš naprš. naštat probleám še žtracenýámi aktualižacemi (lošt update problem).

ÚÚ rovneš konžištence lže braá t i ž hlediška ižolace. Stupenš 0 poškýtuje velmi malou nežaávišlošt, ažš na žmíánešnýá probleám še žtracenýámi aktualižacemi. Je žršejmeá , žše probleám š ižolacíá tranšakcíá je pršíámo špojenýá š konžištencíá a tedý ršíáženíám šoubešhu (concurrencý control) [9, štr. 346].

Norma ANSI SQL-92 žavaádíá cštýrši uá rovneš ižolace. Týto uá rovneš jšou urcšený podle toho, ke kterýám ž naá šledujíácíách tršech jevuů muů žše dojíát:

1. P1 (Dirtý read) Pršecšteníá meživýášledku: Tranšakce T1 žmešníá ršaá dek. Tranšakce T2 pršecšte tento ršaádek, ješšteš pršed tíám, nežš je proveden commit v tranšakci T1. Pokud poteá dojde v tranšakci T1 k rollbacku, T2 pršecšetla ršaádek, kterýá nebýl commitnut a tedý nikdý neexištoval.

2. P2 (Non-repeatable read): Tranšakce T1 nacšte ršaádek. Tranšakce T2 potom tento ršaádek žmešníá, nebo šmažše a provede commit. Pokud naá šledneš bude chtíát tranšakce T1 žnovu nacšíášt tento ršaádek, žíáškaá jinou hodnotu, nebo žjištíá, žše tento ršaádek neexištuje.

3. P3 (Phantom): Tranšakce T1 nacšte šadu ršaádek N, kteraá výhovuje urcšiteá podmíánce. Tranšakce T2 potom provede takoveá žmešný, ktereá povedou k tomu, žše daneá podmíánce výhovíá jinaá šada ršaádek. Pokud naá šledneš T1 žopakuje nacšteníá ršaá dek še štejnou podmíánkou, žíáškaá jinou šadu ršaádek.

Naá šledujíácíá tabulka udaávaá vžtah meži uá rovnešmi ižolace a jevý, ktereá mohou naštat [11, š. 68].

Tabulka 1: Vztah mezi úrovněmi izolace a jevy, které mohou nastat

Dirty read Non-repeatable read Phantom

Read uncommited Ano Ano Ano

Read commited Ne Ano Ano

Repeatable read Ne Ne Ano

Serializable Ne Ne NeŽdroj: vlaštníá žpracovaáníá na žaákladeš ANSI SQL-92 [11, štr. 68]

- 15 -

Úkažuje še ovššem, žše toto cšlenešníá neníá kompletníá a opomíájíá nešktereá dalšš íá oblíábeneá uá rovneš ižolace, žejmeána Snapšhot ižolaci [12, š. 1]. Pršeštožše u Snapšhot ižolace nemuů žše dojíát ani k jednomu ž jevuů uvedenýách v ANSI SQL-92, nešplnš uje uá rovenš Serialižable [12, š. 8].

D - Trvanlivost (durability) žnamenaá , žše jakmile je tranšakce uá špešššneš dokoncšena (commit), výášledký teá to tranšakce jšou trvaleá . Tedý DBMS žarucšuje, žše uložšeneá hodnotý pršecškajíá naá šledneá šýšteámoveá šelhaáníá. Toto je takeá duů vod, procš mušíá nejprve dojíát k vlaštníámu ukoncšeníá tranšakce a teprve poteá dojde k informovaáníá užš ivatele o uá špešššneám dokoncšeníá tranšakce [9, š. 349].

2.1 Distribuované systémy

Dištribuovaneá šýšteámý definujeme jako šýšteámý, ve kterýách šoftwaroveá nebo hardwaroveá komponentý pocšíátacšuů propojenýách do šíáteš komunikujíá a koordinujíá šveá akce použe výámešnou žpraáv.

Síáťoveš propojeneá pocšíátacše mohou býá t od šebe libovolneš vždaá lený. Mohou býá t ve štejneá míáštnošti, ve štejneám meššteš nebo mohou býá t na roždíálnýách kontinentech.

Tato definice dištribuovanýách šýšteámuů maá naá šledujíácíá dopadý:

Souběh (concurrency) – v pocšíátacšovýách šíátíách je šoubešžšneá špušštešníá programu štandardem. Pršíákladem muů žše býá t pršíáštup k jednomu ždroji, naprš. k weboveá štraánce nebo šouboru. Kapacita šýšteámu, kterýá špravuje šdíáleneá ždroje, muů žše býá t navýáššena pršidaáníám dalššíách ždrojuů (naprš. pocšíátacšuů ) do šíáteš . Koordinace šoubešžšneš špušštešnýách programuů pršištupujíácíách ke šdíáleneámu ždroji je takeá duů ležš iteá a opakujíácíá še teáma, protožše nedoštatecšneá oššetršeníá možšneáho šoubešhu pršedštavuje výážnamneá bežpecšnoštníá rižiko [13, š. 205].

Asynchronnost (no global clock) – kdýžš potršebujíá programý špolupracovat, koordinujíá švoji cšinnošt výámešnou žpraáv. ÚÚ žkaá špolupraá ce cšašto žaávišíá na šdíáleneá pršedštaveš o cšaše, kdý naštala konkreá tníá programovaá udaá lošt. Ale ukažuje še, žše exištujíá limitý, ve kterýách jednotliveá pocšíátacše dokaá žš íá šešýnchronižovat švoje hodiný, tžn., žše neexištuje jeden špraávnýá cšaš. Toto je pršíámýá duů šledek toho, žše jedinýám žpuů šobem jak šešýnchronižovat cšaš je výámešna žpraáv šíátíá.

Nezávislé poruchy (independent failures) – vššechný pocšíátacšoveá šýšteámý mohou šelhat a je žodpovešdnoštíá šýšteámovýách architektuů domýášš let duů šledký možšnýách šelhaáníá. Dištribuovaneá šýšteámý mohou šelhat novýámi žpuů šobý. Poruchý v pocšíátacšoveá šíáti žpuů šobíá oddeš leníá jednotlivýách puů vodneš propojenýách pocšíátacšuů , ale to nežnamenaá , žše týto pocšíátacše pršeštalý bešžšet. Ve škutecšnošti programý bešžš íácíá na tešchto pocšíátacšíách nemušíá býá t šchopný žjištit, ještli doššlo k pršeruššeníá špojeníá, nebo je špojeníá použe pršíálišš pomaleá . Obdobneš šelhaáníá jednoho pocšíátacše nebo neocšekaávaneá ukoncšeníá programu nemušíá býá t okamžš iteš žjištitelneá pro vššechný štraný uá cšaštníácíá še vžaá jemneá komunikace. Kažšdaá komponenta v šýšteámu muů žše šelhat nežaávišle, žatíámco oštatníá štaá le bešžš íá [14, š. 2].

- 16 -

2.1.1 Distribuovaný databázový systém

Dištribuovanou databaá ži definujeme jako šoubor neškolika logický propojenýách databaá žíá dištribuovanýách v pocšíátacšoveá šíáti. Dištribuovanýá DBMS je potom definovanýá jako šoftwarovýá šýšteám, kterýá umožšnš uje špraávu dištribuovaneá databaá že a tato dištribuce je pro užš ivatele tranšparentníá.

Neškdý je termíán DDBS (dištributed databaše šýštem) použš íávaán špolecšneš , jak pro dištribuovanou databaá ži, tak pro dištribuovanýá DBMS.

Dva nejduů ležš iteš jšš íá pojmý ž teá to definice jšou logický propojeneá a dištribuovaneá v pocšíátacšoveá šíáti. Tato definice umožšnš uje výloucšit problematickeá okrajoveá pršíápadý, ktereá takeá obcšaš býávajíá nažýávaáný DDBS [9, š. 3].

2.2 CAP teorém

Jako švou domnešnku pršedštavili tento princip ve šveá praá ci Harvest, Yield, and Scalable Tolerant Systems ž roku 1999 Eric A. Brewer a Armando Fox [15, š. 1]. Do šš irokeáho povešdomíá še vššak doštala ažš prši prežentaci Ericem Brewerem na konferenci PODC v roce 20001.

Naá šledneš ji v roce 2002 formaá lneš dokaá žali Seth Gilbert a Nancý Lýnch [16, š. 1], a tehdý še tento princip žacšal nažýávat CAP teoreám.

CAP teoreám ršíákaá , žše v dištribuovaneám šýšteámu nelže žaršíádit naá šledujíácíá trši vlaštnošti najednou.

• Konsistence (C – consistency) – vššechný kopie, cšašto ožnacšovaneá jako repliký, štejnýách dat budou šhodneá v celeám dištribuovaneám šýšteámu.

• Dostupnost (A – availability) – vššechný žš iveá užlý v šýšteámu jšou šchopneá žpracovat požšadovanou operaci a odpovešdeš t na dotažý.

• Odolnost při oddělení (P - partition tolerant) - šýšteám je navržšen tak, abý býl šchopen pracovat i v pršíápadeš výápadku konektivitý meži kopiemi.

Pro pochopeníá teoreámu ši lže pršedštavit dva užlý, ktereá jšou najednou oddeš leneá (naprš. dojde k výápadku šíáteš ). V pršíápadeš , žše dovolíáme žaktualižovat štav jednoho užlu, dojde k nekonžištentnošti meži tešmito dvešma užlý a tedý pršijdeme o (C). Obdobneš , pokud padne volba na žachovaáníá konžištence, tak v pršíápadeš , žše užlý jšou od šebe oddeš leneá , jeden užel še mušíá žachovat tak, jako bý býl nedoštupnýá a tedý pršichaá žíáme o (A). Použe v pršíápadeš , žše oba užlý špolu komunikujíá, je možšneá žajištit jak doštupnošt (A), tak konžištenci (C) a tedý pršichaá žíáme o (P). Vššeobecneš še šoudíá, žše v dištribuovanýách šýšteámech je tršeba žachovat (P) a tedý je nutneá vždaá t še (C) nebo (A). Napršíáklad NoSQL databaá že veš tšš inou štavíá do popršedíá doštupnošt (A) a ažš naá šledneš konžištenci, žatíámco dištribuovaneá databaá že, ktereá dodržšujíá ACID deš lajíá opak [17].

1 Nineteenth ACM Sýmpošium on Principleš of Dištributed Computing (PODC 2000),Julý 16-19 2000, Portland, Oregon

- 17 -

Je ovššem pravdou, žše od teá dobý doššlo k pomešrneš intenživníámu výážkumu a acš bý še teoreám mohl jevit jako neobejitelnýá, pršece jen doššlo k urcšiteámu pošunu ve vníámaáníá CAP.

CAP nedovoluje použe malou cšaá št naávrhu, kteraá špocšíávaá v perfektníá doštupnošti a perfektníá konžištenci v pršíápadeš oddeš leníá (P), cožš je vžaá cneá .

Pršeštožše naávrhaá rši štaá le mušíá volit meži konžištencíá (C) a doštupnoštíá (A) v pršíápadeš výáškýtu oddeš leníá (P), je žde štaá le velkeá množšštvíá možšnoštíá, jak še v pršíápadeš tešchto oddeš leníá žachovat a jak še ž nich žotavit.

Aktuaá lníám cíálem žohlednš ujíácíám CAP bý mešla býá t šmýšluplnaá maximaližace konžištence a doštupnošti pro konkreá tníá aplikace. Takovýá to pršíáštup maá v šobeš jižš žahrnuteá žotaveníá še ž oddeš leníá užluů a dovolíá naávrhaá ršuů m dištribuovanýách šýšteámuů pršemýášš let o CAP bež ohledu na puů vodneš vníámanaá omeženíá [17].

2.3 Transakční zpracování v NoSQL databázích

Klíácšovou vlaštnoštíá NoSQL databaá žíá je shared nothing horižontaá lníá šškaá lovaáníá, tedý replikovaáníá a roždeš leníá dat pršeš mnoho šerveruů . Díáký tomu žvlaádnou velkeá množšštvíá jednoduchýách operacíá.

NoSQL databaá že týpický nepodporujíá ACID tranšakcšníá žpracovaáníá, tedý aktualižace dat je nakonec provedena na vššech užlech, ale neníá žajišštešna konžištence prši cšteníá tešchto dat.

Proto neškteršíá autorši hovoršíá o BASE tranšakcíách. BASE tranšakce jšou charakterižovaáný naá šledujíácíámi vlaštnoštmi:

• Basically available – žnamenaá , žše šýšteám je doštupnýá podle CAP teoreámu.

• Soft state – žnamenaá , žše štav šýšteámu muů žše žmešnit šaám, dokonce bež neš jakeáho vštupu. To šouvišíá š naá šledujíácíá vlaštnoštíá Eventual consistency.

- 18 -

Obrázek 1: CAP teorém

Ždroj: vlaštníá žpracovaáníá na žaákladeš [18]

• Eventual consistency - žnamenaá , žše še šýšteám šaám, v konecšneám cšaše, doštane do konžištentníáho štavu, pokud v tomto cšaše nenaštane dalšš íá vštup.

Hlavníám duů vodem pro vždaáníá še ACIDu je došažšeníá výáražneš výšššš íáho výákonu a šškaá lovatelnošti, acš še jednotliveá šýšteámý od šebe výáražneš odliššujíá tíám, jak moc še vždaávajíá.

Veš tšš ina NoSQL šýšteámuů je eventually consistent, tedý prši bešhu takoveáho šýšteámu muů žše dochaá žet k rožporuů m prši cšteníá štejnýách dat ž ruů žnýách užluů , ale došt šýšteámuů obšahuje mechanižmý žajiššťujíácíá urcšitýá štupenš konžištence, jako napršíáklad multi--veršion concurrencý control (MVCC).

Žaštaánci NoSQL šýšteámuů cšašto použš íávajíá CAP teoreám k obhajobeš abšence jedneá ž uvedenýách vlaštnoštíá. NoSQL šýšteámý še veš tšš inou vždaávajíá konžištence [6, š. 2].

2.4 Transakční zpracování v NewSQL databázích

Na roždíál od NoSQL databaá žíá NewSQL databaá že majíá šcheáma, SQL rožhraníá a ACID tranšakce. Tradicšníá RDBMS šýšteámý nedošahujíá takoveá šškaá lovatelnošti jako NoSQL šýšteámý. V pošledníá dobeš še ovššem objevujíá šýšteámý, ktereá majíá šluššnýá výákon na užel a žaá rovenš umožšnš ujíá dobrou šškaá lovatelnošt. Ždaá še, žše bý mohlý nabíádnout šškaá lovatelnošt podobnou NoSQL šýšteámuů m, ale použe ža šplnešníá naá šledujíácíách pršedpokladuů :

• Použš itíá jednoduchýách operacíá. Operace, ktereá še mušejíá žpracovaávat na neškolika užlech, naprš. špojeníá víáce tabulek, še š šhardingem nešškaá lujíá dobrše.

• Použš itíá jednoduchýách tranšakcíá. Tranšakce, ktereá še mušejíá žpracovaávat na neškolika užlech, nebudou pršíálišš efektivníá ž duů vodu potršebneá šíáťoveá komunikace a dvoufaá žoveáho commitu.

Stojíá ža povššimnutíá, žše NoSQL šýšteámý obchaá žíá týto probleámý tak, žše je velice tešžškeá nebo nemožšneá proveášt šložš iteá operace nebo tranšakce. Proti tomu NewSQL databaá že šložš iteá operace a tranšakce umožšnš ujíá, nicmeáneš užš ivatel je prši jejich použš itíá penaližovaán žtraá tou výákonu. NewSQL šýšteámý tedý majíá výáhodu v tom, žše nabíážejíá SQL jažýk a ACID, pršicšemžš výákon je degradovaán použe prši použš itíá dotažu nebo tranšakce, kteraá še dotýákaá víáce užluů [6, š. 9].

2.5 Charakteristika transakční zátěže

Žaákladníá cšlenešníá žaá tešžše databaá že špocšíávaá v tom, kolik dotažuů databaá že žpracovaávaá a jak dlouho trvaá žpracovat kažšdýá dotaž. Ž tohoto pohledu deš líáme aplikace výužš íávajíácíá databaá že na dva týpý. Prvníám týpem jšou OLTP aplikace, ktereá jšou charakterižovaneá velkýám pocštem šoucšašneš pršištupujíácíách užš ivateluů a tedý velkeá množšštvíá šoucšašneš špoušštešnýách tranšakcíá. Týto tranšakce veš tšš inou obšahujíá použe jednoducheá dotažý a žpracovaáníá jedneá takoveá to tranšakce je proto velice

- 19 -

rýchleá . Meži takoveá to aplikace patršíá naprš. on-line režervacšníá šýšteám letenek, nebo bankovníá aplikace.

Naproti tomu OLAP aplikace, jako analýáža trenduů nebo tvorba pršedpovešdíá, výužš íávajíá komplexníá dotažý pršeš mnoho velkýách tabulek. Týpickaá žaá tešžš OLAP aplikacíá ovššem nepršedštavuje velkeá množšštvíá šoucšašneš pršištupujíácíách užš ivateluů a tedý abšolutníá pocšet dotažuů je malýá. Proto prši špoušštešníá OLAP dotažuů pršeš dištribuovaneá produkcšníá databaá že vývštaávajíá dva probleámý. OLAP dotažý veš tšš inou trvajíá delšš íá dobu a tíám výtíážš íá lokaá lníá databaá že, kde užš ivateleá OLTP aplikacíá požorujíá degradaci výákonu. Ža druheá , celkovýá cšaš ke žpracovaáníá výášledkuů muů žše býá t žnacšnýá, protožše výžšaduje pršenoš žnacšneáho objemu dat. Navíác šoucšašneá OLAP aplikace nepotršebujíá míát pršíáštup k nejaktuaá lneš jšš íám datuů m, proto še veš tšš inou OLAP aplikace použš íávajíá nad datovýámi škladý, kam še data odklaádajíá ž produkcšníách databaá žíá [9, š. 132].

- 20 -

3 NewSQL databáze – principy, architektura, použit

V teá to kapitole jšou pršedštavený techniký a algoritmý, ktereá výužš íávajíá tvuů rci NewSQL databaá žovýách šýšteámuů pro došažšeníá švýách cíáluů . Tedý horižontaá lneš šškaá lovatelnýách SQL databaá žovýách šýšteámuů . Pošledníá podkapitola še žabýávaá nejcšašteš jšš íám výužš itíám takovýáchto šýšteámuů .

3.1 In-memory databáze

Standardníá RDBMS uklaádaá data dvakraá t. Ú kažšdeá tranšakce je tršeba, abý pršed jejíám dokoncšeníám býla data žapšaána jak v databaá ži, tak i v tranšakcšníám logu [8, š. 853].

In-memorý databaá že (IMDS) pršedštavujíá výáražnýá pošun v naávrhu vlaštníáho DBMS. Tradicšníá DBMS jšou celkoveš optimaližovaáný pro uklaádaáníá dat na pevneá dišký, a to od konštrukce indexuů (B-Treeš) pršeš buffer management a V/V diškoveá operace ažš po uklaádaáníá tranšakcšníách loguů . IMDS nežnamenaá použe nahraženíá pevnýách diškuů RAM diškem, ale pršedevššíám novýá naávrh DBMS. Jednou ž komponent, kteraá maá výážnamnýá podíál na šníážšeníá výákonu (overhead), je buffer management [22, š. 2]. Výnechaáníá buffer managementu a výužš itíá jinýách týpuů indexuů , naprš. T-Tree, tedý muů žše výáražneš žvýášš it výákon DBMS. Na druheá štraneš prši naávrhu IMDS vývštaávajíá noveá probleámý. Data totižš nejšou nikde trvanliveš uložšena a vžhledem k výšokeámu výákonu je tršeba vešnovat požornošt tranšakcšníámu logu. Pouheá uklaádaáníá logu na dišk bý mohlo žnamenat šníážšeníá výákonu, proto še veš tšš inou volíá jineá poštupý. Log je napršíáklad replikovaán na jineá užlý a teprve poteá je ašýnchronneš žapšaán na dišk nebo do jineáho šýšteámu [23, š. 1].

3.2 Oddělení transakční logiky od perzistentního uložení

Tradicšníá databaá žoveá šýšteámý jšou navržšený tak, žše vššechna data jšou šýnchronižovaána meži pameštíá RAM a štrukturou uložšenou na dišku. Tato uá žkaá važba potom žnemožšnš uje jednoducheá horižontaá lníá šškaá lovaáníá. Oddeš leníá tešchto rolíá umožšnš uje jednodušššš íá šškaá lovaáníá, ktereá neníá tak žaávišleá na diškoveá propuštnošti (u architektur še šdíálenýám diškovýám uá ložš išštešm) nebo nevýžšaduje explicitníá šharding dat [20, š. 2] [24, š. 3].

3.3 Dvoufázové zamykání - 2-phase locking (2PL)

Jednaá še o pruů bešh žamýkaáníá a uvolnš ovaáníá žaámkuů že žaá žnamuů . Jak naá žev napovíádaá , je celaá tranšakce roždeš lena do dvou na šebe navažujíácíách cšaá štíá. V prvníá faá ži je možšneá žaá žnamý použe žamýkat. V pršíápadeš , žše neníá možšneá danýá žaá žnam žamknout, bude tato tranšakce pršeruššena do dobý, nežš bude možšneá žaámek žíáškat. Toto evidentneš muů žše veášt k deadlockuů m a š tešmi je tršeba še výporšaádat jinýámi proštršedký.

- 21 -

Ve druheá faá ži še jižš žaámký použe uvolnš ujíá. Neboli v žšaádneá tranšakci nešmíá dojíát k uvolnešníá libovolneáho žaámku pršed užamknutíám libovolneáho žaá žnamu [25, š. 10].

3.4 Multiversion Concurrency Control (MVCC)

MVCC neškdý takeá býávaá v literaturše ožnacšovaán jako Multiveršion timeštamp ordering. Ke kažšdeámu uložšeneámu objektu v databaá ži je takeá uložšeno cšašoveá ražíátko tranšakce, kteraá danýá objekt žmešnila nebo výtvoršila.

Tranšakcšníá manažšer (TM) kažšdeá tranšakci, i teá kteraá provaádíá použe cšteníá, prširšadíá jedinecšneá cšašoveá ražíátko. Toto ražíátko je prširšaženo ke vššem cšteníám i žaápišuů m teá to tranšakce.

V pršíápadeš žaápišu noveá hodnotý neníá pršíámo pršepšaán puů vodníá objekt, ale je výtvoršen objekt novýá. Tomuto objektu je takeá prširšaženo cšašoveá ražíátko tranšakce, kteraá jej výtvoršila. V tento okamžšik tedý v databaá ži exištuje víáce veržíá jednoho objektu. V pršíápadeš , žše dojde ke commitu tranšakce, jšou verže objektuů š cšašovýám ražíátkem uvolnešný pro cšteníá. V pršíápadeš rollbacku jšou šmažaáný.

Nejveš tšš íá výáhoda tohoto pršíáštupu še projevíá prši cšteníá, kdý neníá tršeba žšaádneáho žamýkaáníá a cšekaáníá. V pršíápadeš požšadavku pro nacšteníá nešktereáho objektu še vežme cšašoveá ražíátko teá to operace a databaá že výhledaá odpovíádajíácíá objekt š nejvýšššš íám cšašovýám , ktereá je žaá rovenš nižššš íá, nežš to, ktereá maá prširšažena tato operace [25, š. 15].

Optimištickeá žamýkaáníá, žejmeána timestamp ordering method je výáhodneš jšš íá, pokud je víáce tranšakcíá, ktereá použe cštou. Naopak pešimištickeá žamýkaáníá, žejmeána 2PL, je výáhodneš jšš íá, pokud je víáce tranšakcíá, ktereá provaádeš jíá žaápiš [14, š. 718]. Exištujíá i šýšteámý, ktereá kombinujíá oba pršíáštupý a tedý pro cšteníá použš íávajíá MVCC a pro žaápiš 2PL [26, š. 11].

3.5 Dvoufázový commit - 2-phase commit (2PC)

2PC je velmi jednoduchýá protokol, kterýá dokaá žše žarucšit atomickýá commit u dištribuovanýách tranšakcíá. Jednaá še o rožššíáršeníá lokaá lníáho commitu na dištribuovaneá tranšakce tak, žše trvaá na potvrženíá od vššech užluů , kterýách še tranšakce dotýákaá . Teprve poteá je tranšakce definitivneš potvržena a žmešný provedeneá tranšakcíá jšou trvanliveš uložšeneá . Vlaštníá 2PC funguje naá šledovneš . Exištuje jeden koordinaá tor tranšakce a neškolik uá cšaštníákuů .

• Koordinaá tor žaššle vššem uá cšaštníákuů m žpraávu Prepare.

• Pokud je uá cšaštníák šchopen proveášt commit, žaššle koordinaá torovi žpraávu Vote-commit, v opacšneám pršíápadeš žašíálaá žpraávu Vote-abort. V tomto pršíápadeš jižš neníá pro uá cšaštníáka potršeba še touto tranšakcíá daá le žabýávat. Žpraáva Vote-abort totižš funguje jako veto.

• Jakmile koordinaá tor obdržš íá žpraávý od vššech uá cšaštníákuů , rožhodne, jak bude tranšakce pokracšovat. V pršíápadeš , žše doštane býť jednu žpraávu o žruššeníá

- 22 -

tranšakce, tak koordinaá tor žaššle vššem uá cšaštníákuů m žpraávu Global-abort. V opacšneám pršíápadeš žaššle žpraávu Global-commit.

• Jednotlivíá uá cšaštníáci podle žpraávý, kterou obdržšeli, buď provedou commit, nebo tranšakci žruššíá a žaššlou koordinaá torovi potvrženíá o provedeneá akci.

• Jakmile koordinaá tor obdržš íá od vššech uá cšaštníákuů potvrženíá, ukoncšíá tranšakci [9, š. 428].

3.6 Paxos

Algoritmuš vžnikl na ršeckeám oštroveš Paxoš kolem roku 1000 n. l. Paxoš býl v teá dobeš bohatýám obchodníám centrem. Žaákonodaá rcuů m še nechteš lo traávit pršíálišš mnoho cšašu v parlamentu, a tak nebýlo možšneá hlašovat na šchuů žíách. Býlo tedý nutneá najíát žpuů šob, jak fungovat v parlamentu na cšaá štecšnýá uá važek (proto býávaá algoritmuš obcšaš nažýávaán Part-Time Parliament). Puů vodníá algoritmuš tedý šloužš il k hledaáníá konšenžu pro jednotlivaá hlašovaáníá parlamentu [27, š. 2].

Nejjednodušššš íá variantou je tžv. Jednoduchýá Paxoš. Ten je žaákladem pro vššechný pokrocšilejšš íá variantý, ktereá jižš poteá nachaá žejíá uplatnešníá v dištribuovanýách šýšteámech. Jednaá še žejmeána o Multi-Paxoš anebo tžv. Býžantškýá Paxoš.

Požšadavký, ktereá mušíá Jednoduchýá Paxoš žajištit:

• Je žvolena hodnota, kteraá býla nejprve navržšena.

• Na konci je žvolena použe jedinaá hodnota.

• ŽŽ aádnýá užel še nenaucšíá hodnotu, pokud škutecšneš neníá žvolena.

• Jedna hodnota je nakonec žvolena.

• Kdýžš je hodnota žvolena, jednotliveá užlý še jíá nakonec naucšíá.

Pro fungovaáníá algoritmu je tršeba žajištit naá šledujíácíá trši funkcionalitý, nažýávaneá role:

• Navrhovatel (Proposer)

◦ Aktivníá role v algoritmu.

◦ Pršijíámaá požšadavký na volbu od klientuů .

◦ Navrhuje oštatníám užluů m konkreá tníá hodnotý, na kterýách še maá clušter šhodnout.

• Schvalovatel (Acceptor)

◦ Pašivníá role v algoritmu.

◦ Odpovíádaá na žpraávý od navrhovateluů .

◦ Odpovíádaá na konkreá tníá volbu, tedý tvoršíá konšenžuš.

◦ Úchovaávaá volenou hodnotu a štav volbý.

- 23 -

• Učedník (Learner)

◦ Chce žnaá t hodnotu, ke ktereá še naššel konšenžuš.

◦ Poškýtuje klientuů m žvolenou hodnotu.

Jednotlivíá agenti ši výmešnš ujíá žpraávý, pršedpoklaádaáme tžv. fail-štop model, tj. žše žpraávý še mohou žtratit, mohou še duplikovat, muů žše jim trvat libovolneš dlouho, nežš doražíá, ale pokud žpraáva nakonec doražíá, neníá naruššena.

Klient neníá uá plneš šoucšaá štíá algoritmu, u klienta vžnikajíá požšadavký, rešp. klient še š požšadavký obracíá na navrhovatele.

Pršeštožše je možšneá implementovat tento algoritmuš š oddeš lenýámi rolemi, cšašteš ji kažšdýá užel plníá role vššechný. Vžhledem k tomu, žše še jednaá o algoritmuš žajišštujíácíá konšenžuš, je tršeba víáce šchvalovateluů (týpický nižššš íá licheá cšíášlo, abý šš lo žajištit kvorum). Kažšdýá naávrh mušíá míát unikaá tníá cšíášlo. CŽ íám je naávrh noveš jšš íá, tíám maá výšššš íá cšíášlo, rešp. novýá naávrh mušíá míát nejvýšššš íá cšíášlo, ktereá kdý býlo použš ito. Veš tšš inou še volíá špojeníá cšíášla poršadíá naávrhu a cšíášla navrhovatele, abý býlo možšneá rožhodnout, kterýá naávrh doštane pršednošt prši koliži.

Algoritmuš funguje dvoufaá žoveš . Prvníá faá že je pršíápravnaá . V teá to faá ži še žjiššťujíá jižš navržšeneá hodnotý a žaá rovenš dochaá žíá k blokaci štarššíách naávrhuů š nižššš íám cšíášlem. Druhaá faá že je šchvalovacíá. Žde dochaá žíá k výážveš pro šchvalovatele, abý pršijali konkreá tníá hodnotu [28, š. 1].

Celýá algoritmuš lže šhrnout do naá šledujíácíách šedmi krokuů . Kroký 1 ažš 4 jšou pršíápravnaá faá že, kroký 5 ažš 7 jšou faá že šchvalovacíá. Kažšdýá agent je žodpovešdnýá ža peržištentníá uložšeníá jíám vedenýách lokaá lníách promešnnýách minNávrh, zvolenýNávrh a zvolenáHodnota.

- 24 -

Tabulka 2: Jednoduchý PaxosNavrhovatel Schvalovatel

1) Pro žvoleníá hodnoty žvolíá noveá cšíášlo naávrhu n.2) Rožeššle žpraávu Připrav(n) vššem šchvalovateluů m.

3) Odpovíádaá na Připrav(n).Pokud je n > minNávrh, potom ši do minNávrh uložš íá n.V opacšneám pršíápadeš vraá tíá zvolenýNávrh jíám šchvaá leneá hodnotý a zvolenáHodnota

4) Pokud jšou, po pršijetíá veš tšš iný odpovešdíá od šchvalovateluů , vraá cený jižš neš jakeá šchvaá leneá hodnotý, žvolíá hodnotu podle nejvýšššš íáho cšíášla naávrhu.5) Rožeššle Schval(n, hodnota) vššem šchvalovateluů m.

6) Odpovíádaá na Schval(n, hodnota).Pokud je n ≥ minNávrh, potom minNávrh = zvolenýNávrh = n azvolenáHodnota = hodnota.V opacšneám pršíápadeš je šchvalovanaá hodnota odmíátnuta a je vraáceno cšíášlo minNávrh.

7) Pokud je, po pršijetíá veš tšš iný odpovešdíá od šchvalovateluů , neš jakeá odmíátnutíá, je tršeba žacšíát krokem 1.V opacšneám pršíápadeš je hodnota žvolena.

Ždroj: vlaštníá žpracovaáníá na žaákladeš [29]

Pršeštožše tento popiš neníá dlouhýá a šamotnýá algoritmuš je vcelku jednoduchýá, jeho implementace pro produkcšníá našaženíá neníá triviaá lníá. Jednoduchýá Paxoš je pomešrneš štarýá algoritmuš, je detailneš rožebíáraán v literaturše, je mu vcelku dobrše porožumešno a je dokaá žaána jeho špraávnošt, ale pro praktickeá našaženíá je tršeba Jednoduchýá Paxoš rožššíárš it o dalššíá vlaštnošti:

• Praá ce nad šeáriíá hodnot – abý býl algoritmuš použš itelnýá, je tršeba, abý býlo možšneá uklaádat (volit) víáce hodnot a nikoli použe jednu. Proto je prši kažšdeá volbeš tršeba žajištit unikaá tníá ID volbý, abý nemohlo dojíát ke koliži.

• Optimaližace výákonu – je volen líádr, abý še mohla výpuštit veš tšš ina pršíápravnýách faá žíá. Líádr je veš tšš inou volen podle nejvýšššš íáho šerver ID.

• Žajišštešníá plneá replikace – v Jednoducheám Paxošu žnaá žvolenou hodnotu použe navrhovatel, ale pro praktickeá použš itíá je tršeba, abý še žvolenou hodnotu dožvešdeš li všš ichni agenti.

• Komunikace š klientem – žejmeána v pršíápadeš , žše je volen líádr a v pršíápadech, kdý líádr šelžše.

• Žajišštešníá konfiguracšníách žmešn – žajišštešníá pocštu agentuů , kteršíá še uá cšaštníá hlašovaáníá a tedý jakeá je potršebneá kvorum. Pršidaávaáníá a odebíáraáníá agentuů .

- 25 -

Takto rožššíáršenýá algoritmuš še nažýávaá Multi-Paxoš. Multi-Paxoš je ovššem šouhrnnýá naá žev pro ruů žneá techniký rožššíáršeníá Jednoducheáho Paxošu tak, abý adrešoval požšadavký na použš itíá v reaá lneám šýšteámu. Tato rožššíáršeníá jižš ale nejšou tak detailneš proštudovaána, exištuje víácero pršíáštupuů a jejich praktickeá implementace še objevujíá ažš v pošledníá dobeš a žršejmeš ne naáhodou še objevujíá u NewSQL databaá žíá. Nejveš tšš íá tešžškoštíá je praáveš potršeba ruů žnýách optimaližacíá a netriviaá lníáho teštovaáníá. Takeá je tršeba vešnovat požornošt tomu, žše šamotnýá algoritmuš pocšíátaá š bežpecšnýám a trvanlivýám uložšeníám hodnot, ktereá býlý akceptovaáný. V reaá lneám šýšteámu je tršeba pocšíátat š možšnoštíá, žše k teá to žtraá teš dojde [30, š. 1].

3.7 MapReduce

MapReduce, kterýá vžnikl v Googlu v roce 2003, je programovacíá model a pršidružšenaá implementace ke žpracovaáníá a tvorbeš velkýách množš in dat. Úžš ivatel špecifikuje funkci Map, kteraá žpracuje paá r klíácš-hodnota k výgenerovaáníá množš iný mežihodnot klíácš-hodnota, a funkci Reduce, kteraá šloucšíá vššechný mežihodnotý vaá žaneá ke štejneámu klíácši.

Programý napšaneá tíámto štýlem jšou automatický paraleližovaneá a mohou bešžšet žaá rovenš na velkeám pocštu pocšíátacšuů .

Bešhoveá proštršedíá še šamo poštaraá o roždeš leníá vštupníách dat, plaánovaáníá špoušštešníá jednotlivýách procešuů na jednotlivýách užlech v clušteru, naápravu prši šelhaáníá jednotlivýách štrojuů a potršebnou komunikaci meži pocšíátacši. Tíámto žnacšneš ulehcšuje praáci programaá toruů m, kteršíá še nemušejíá žabýávat paralelišmem a programovaáníám dištribuovanýách funkcíá, a pršešto umožšnš uje jejich aplikacíám výužš íávat ždroje ve velkeám clušteru.

Spušštešníá funkce Map je roždeš leno meži víácero štrojuů tak, žše automatický roždeš líá vštupníá data na M cšaá štíá. Vštupníá cšaá šti mohou býá t žpracovaávaáný paralelneš ruů žnýámi štroji. Spušštešníám funkce Reduce jšou dištribuovaáný podle roždeš leníá meživýášledkuů (naprš. hash(key) mod R). Pocšet roždeš leníá R a dištribucšníá funkci volíá užš ivatel.

MapReduce funguje v naá šledujíácíách krocíách:

1. MapReduce knihovna v užš ivatelškeám programu roždeš líá vštupníá šoubor do M cšaá štíá podle užš ivatelem žvoleneá velikošti. Poteá špuštíá program na velkeám množšštvíá pocšíátacšuů v clušteru.

2. Program na jednom pocšíátacši je žvolen jako mašter, žbýleá pocšíátacše jšou pracovníáci, kterýám žadaávaá uá kolý praáveš mašter. Pro danýá probleám exištuje M map uá koluů a R reduce uá koluů . Mašter výbíáraá volneá užlý a pršideš luje jim jednotliveá uá kolý.

3. Pracovníák, ktereámu je pršideš len map uá kol, pršecšte odpovíádajíácíá cšaá št vštupníách dat. Projde vššechný paá rý klíácš -hodnota ž cšaá šti vštupníách dat a aplikuje na neš užš ivatelšký žvolenou funkci. Výášledkem teá to funkce je mežihodnota, kterou tento pracovníák uložš íá do bufferu.

- 26 -

4. Týto meživýášledký jšou pak pravidelneš žašíálaáný mašteru (rešp. lokaá torý k tešmto výášledkuů m). Mašter je naá šledneš žodpovešdnýá ža pršedaáníá vššech potršebnýách lokaá toruů reduce pracovníákuů m.

5. Kdýžš je reduce pracovníákovi pršedaán šežnam lokaá toruů , nacšte ši tento pracovníák mežihodnotý pomocíá vždaá leneáho volaáníá procedurý (RPC). Jakmile maá pracovníák nacštený vššechný výášledký, šrovnaá je podle klíácše a výáškýtý še štejnýám klíácšem šloucšíá.

6. Reduce pracovníák prochaá žíá vššechný meživýášledký, pro kažšdýá unikaá tníá klíácš vraá tíá mežihodnotu užš ivatelškeá reduce funkci. Výášledek je poteá pršipojen do výáštupníáho šouboru pro tuto reduce cšaá št.

7. Kdýžš jšou vššechný map a reduce uá kolý šplnešný, mašter vžbudíá užš ivatelškýá program a je mu pršedaán konecšnýá výášledek.

MapReduce lže použš íát pro velice roždíálneá týpý uá koluů , naprš.:

• probleámý prši štrojoveám ucšeníá,

• extrakce dat pro pršíápravu reportuů ,

• extrakce dat pro výápocštý indexuů ,

• výápocštý grafovýách funkcíá,

• dištribuovaáníá dotažuů (SQL querý) roždeš leníám na menššíá cšaá šti [31, š. 1].

3.8 Optimalizace dotazů

Jednou ž duů ležš itýách vlaštnoštíá relacšníáho databaá žoveáho šýšteámu, díáký ktereámu je tato technologie tak uá špešššnaá , je odštíánešníá od níážkouá rovnš oveá reprežentace dat pomocíá jažýka SQL. Ten umožšnš uje rýchlejšš íá tvorbu aplikacíá a žvýáššeníá produktivitý užš ivateluů . Úžš ivatel nepotršebuje pršešneš špecifikovat poštup, jakýám še výtvaá ršíá odpovešď na dotaž, to v kažšdeá relacšníá databaá ži žajiššťuje procešor dotažuů . Jeho hlavníám uá kolem je roždeš leníá výšokouá rovnš oveáho dotažu na šekvenci databaá žovýách operaá toruů , ktereá še aplikujíá na cšaá šti tabulek. Procešor dotažu takeá urcšuje poršadíá jednotlivýách krokuů š ohledem na jejich proštorovou a cšašovou naá rocšnošt. V pršíápadeš dištribuovaneáho databaá žoveáho šýšteámu je toto výáražneš šložš iteš jšš íá, protožše do rožhodovaáníá procešoru dotažuů vštupujíá dalššíá promešnneá , ktereá mohou celkovýá cšaš velmi ovlivnit. Jde žejmeána o lokalitu dat a cšašoveá žpožšdešníá meži jednotlivýámi užlý databaá že. Lokalita dat žnamenaá , na kterýách užlech jšou potršebnaá data uložšena a tedý jakýám žpuů šobem je vhodneá danýá dotaž dekomponovat, abý še vlaštníá cšaá šti dotažu žpracovaávalý co nejblíážše datuů m a teprve potom še centraá lneš výtvoršila odpovešď. Jinýámi šlový je vhodneá pršešunout dotažý k datuů m a ne data k dotažuů m [9, š. 205]. Jedníám ž možšnýách pršíáštupuů výužš íávanýách ovššem i v tradicšníách databaá žovýách šýšteámech je Cašcadeš Querý Optimižer. Tento pršíáštup je žaložšen na hodnoceníá jednotlivýách exekucšníách plaánuů . Nejprve je výtvoršena tžv. Search Space. Jednaá še o množš inu vššech permutacíá možšnoštíá jak žíáškat požšadovanýá výášledek. Naá šledneš je vššem exekucšníám plaánuů m že

- 27 -

Search Space prširšažena urcšitaá cena, kteraá je urcšena podle toho, kolik danýá exekucšníá plaán špotršebuje ždrojuů . Nakonec je výbraán exekucšníá plaán, kterýá maá nejnižšššíá cenu [26, š. 7] [32, š. 1].

3.9 Automatický sharding

Na roždíál od tradicšníách databaá žovýách šýšteámuů je do veš tšš iný NewSQL databaá žovýách šýšteámu implementovaán automatickýá šharding. V tradicšníách SQL šýšteámech je podporovaán manuaá lníá šharding. To žnamenaá , žše ža špraávneá roždeš leníá tabulký je žodpovešdnýá užš ivatel nebo užš ivatelškaá aplikace. To pršinaá šš íá špecifickeá probleámý a ve šveám duů šledku i prodražšuje provož aplikace. Je tršeba žajištit, abý data býla štaá le rovnomešrneš roždeš lena a tedý, abý výtíážšeníá jednotlivýách užluů býlo rovnomešrneá . Vžšdý, kdýžš dojde k nerovnomešrneámu žatíážšeníá, nebo je potršeba žmešnit pocšet užluů databaá že, dochaá žíá ke žmešnoveámu ršíáženíá aplikace a je tedý tršeba ješšteš proveášt teštovaáníá a žmešnu dokumentace. To je duů vod, procš nemaleá množšštvíá užš ivateluů upoušštíá od manuaá lníáho šhardingu.

NewSQL databaá že ž tešchto duů voduů implementujíá automatickýá šharding, kterýá nevýžšaduje žšaádnou šoucšinnošt od užš ivatele. Týto šýšteámý automatický roždeš lujíá data podle výtíážšeníá. Duů ležš itou vlaštnoštíá tohoto automatickeáho deš leníá je, žše veš tšš ina tranšakcíá muů žše bešžšet paralelneš , tj. žše kažšdaá jednotlivaá tranšakce je výkonaávaána na jednom užlu [24, š. 4].

3.10 Použit

Podštatou NewSQL databaá žovýách šýšteámuů je podpora ACID tranšakcíá a možšneáho horižontaá lníáho šškaá lovaáníá bež žaá šahu nebo bež optimaližace aplikacšníáho koá du. Jejich hlavníám výužš itíám jšou šýšteámý, kde je výžšadovaáno velkeá množšštvíá tranšakcíá, ale jejichžš komplexnošt neníá pršíálišš výšokaá . V tomto pršíápadeš lže výužš íát automatickýách optimaližacíá žahrnutýách do NewSQL databaá žíá, ktereá data automatický roždeš líá na jednotliveá užlý v databaá ži, abý výtíážšeníá jednotlivýách užluů býlo rovnomešrneá .

Nejbešžšneš jšš íámi pršíákladý pro použš itíá NewSQL databaá žíá jšou:

• Hraníá on-line her, kde jšou kladený velkeá požšadavký na rýchlošt a možšnošt šškaá lovaáníá.

• Weboveá aplikace pro projektý, kde pršeštaávaá štacšit jedna databaá že. Je žde požšadavek na možšnošt jednoducheáho šškaá lovaáníá a výážnamnaá cšaá št produktuů je tvoršena jako drop-in naáhrada ža MýSQL databaá ži.

• CEP – Complex Event Proceššing - jednaá še o žpracovaáníá dat nad velkýámi šeáriemi dat, ktereá še neuštaá le mešníá. Sýšteám hledaá v udaá loštech vžorý a na žaákladeš tešchto hištorickýách vžoruů porovnaáníám š aktuaá lníá šituacíá še šnažš íá pršedpovíádat dalšš íá šmešršovaáníá. Výužš íávaá še pro nejruů žneš jšš íá pršedpovešdi, od obchodu, pršeš logištiku ažš po analýážu chovaáníá žaákažníákuů . Toto nabýávaá na výážnamu žejmeána ve špojeníá š dalššíám fenomeánem pošledníá dobý a to je

- 28 -

Internet vešcíá (IoT). Kažšdeá takoveá to žaršíáženíá generuje velkeá množšštvíá dat ktereá je potršeba analýžovat [21].

• HTAP – hýbridníá tranšakcšneš -analýtickeá žpracovaáníá je možšnošt špouššteš t analýtickeá dotažý nad cšerštvýámi datý. Toto je roždíál od puů vodníáho pojetíá BI – bušinešš intelligence, kde jšou analýtickeá dotažý špoušštešný použe nad hištorickýámi datý. V bešžšneá praxi še data žpracovaávajíá v OLTP šýšteámu, že ktereáho jšou pravidelneš pomocíá datoveá pumpý uklaádaána do OLAP šýšteámu. V tomto druheám šýšteámu jšou pak žpracovaávaáný vššechný analýtickeá dotažý, abý nebýl degradovaán výákon OLTP šýšteámu. NewSQL šýšteámý cíáleneá na HTAP jšou proto výbaveneá i šloupcoveš orientovanýám uá ložš išštešm a tranšakce neblokujíácíá ršíáženíá pršíáštupu pro cšteníá, týpický MVCC [33, š. 52].

- 29 -

4 Systémy založené na NewSQL architektuře

V teá to kapitole jšou pršedštavený šýšteámý špadajíácíá do kategorie NewSQL databaá žíá. V prvníá tabulce je pršehled vššech hlavníách žnaá mýách produktuů vcšetneš jejich licencíá.

Tabulka 3: Seznam NewSQL databází

Databáze Licence Charakteristika

Google Spanner/F1 Internal Globaá lneš dištribuovanýá DBMS

NuoDB Proprietarý Vlaštníá novaá trš íávrštvaá (three-tier) architektura

VoltDB GPL/Proprietarý Vlaštníá jednovlaáknovaá in-memorý architektura

CluštrixDB Proprietarý Vlaštníá architektura, drop-in replacement ža Mýšql

MemSQL Proprietarý In-memorý DDBS kompatibilníá š MýSQL

CockroachDB Apache 2.0 Open šource google španner

Apache Trafodion Apache 2.0 Nad Hbaše, Hadoop

SAP HANA Proprietarý Vlaštníá architektura š hýbridníám uá ložš išš tešm

TIBCO ActiveSpaceš Proprietarý In-memorý dištribuovanýá data grid

ScaleBaše Proprietarý Clušter nad Mýšql inštancemi

ScaleDB GPL Scale-out uá ložš išš teš pro Mýšql

dbShardš Proprietarý Clušter nad Mýšql inštancemiŽdroj: vlaštníá žpracovaáníá

4.1 Google Spanner/F1

Databaá že Google Spanner a F1 še odliššujíá od vššech oštatníách šýšteámuů ž pršehledu NewSQL databaá žíá uvaádešnýách v teá to praáci, protožše jšou vývíájený a výužš íávaáný výáhradneš pro potršebý špolecšnošti Google.

Google Spanner je globaá lníá dištribuovaneá uá ložš iššteš týpu klíácš -hodnota. Data uklaádanaá do databaá že jšou veržovaána a kažšdaá verže automatický doštaávaá cšašoveá ražíátko, kdýžš dojde ke commitu tranšakce. O štareá verže še pak poštaraá garbage collector, kterýá je dle naštavenýách pravidel mažše. Spanner nabíážíá tranšakce a jažýk SQL.

Spanner maá dveš vlaštnošti, ktereá jšou obtíážšneš implementovatelneá v dištribuovanýách databaá žíách. Je to:

• externeš konžištentníá cšteníá a žaápišý,

• globaá lneš konžištentníá cšteníá napršíácš databaá žíá v jednom cšašoveám okamžšiku.

Týto vlaštnošti umožšnš ujíá Spanneru podporu pro konžištentníá žaá lohý, konžištentníá špoušštešníá MapReduce a atomickeá žmešný šcheámatu a to všše v globaá lníám mešršíátku a ža bešhu tranšakcíá.

- 30 -

Týto vlaštnošti jšou umožšnešný tíám, žše Spanner prširšažuje commitu tranšakcíá cšašovaá ražíátka š globaá lníám výážnamem, pršeštožše týto tranšakce mohou býá t dištribuovaneá . CŽašovaá ražíátka odpovíádajíá pošloupnošti jednotlivýách tranšakcíá.

Google pro šýnchronižaci cšašu výužš íávaá vlaštníá šýšteám žaložšenýá na pršešneám cšašu žíáškaávaneáho že šignaá lu GPS, kterýá umožšnš uje udržšet roždíál v hodinaá ch ve vššech datovýách centrech pod 10 mš.

Ve Spanneru jšou datoveá ršaá dký roždeš lený do clušteruů nažýávanýách adrešaá rše, podle jejich dešdicšnýách vžtahuů ve šcheámatu. Kažšdýá adrešaá rš maá alešponš jeden fragment a velkeá adrešaá rše mohou míát víácero fragmentuů . Skupiný uklaádajíá kolekce adrešaá ršovýách fragmentuů . Kažšdaá škupina maá týpický jednu repliku tabletu na datoveá centrum. Tablet je datovaá štruktura, modifikace klíácš -hodnota uá ložš iššteš , kdý ke kažšdeámu klíácši je pršidaáno cšašoveá ražíátko. Tablet tedý pršíámo v šobeš implementuje MVCC. Data jšou šýnchronneš replikovaána pomocíá Paxoš algoritmu a vššechný tabletý pro škupinu obšahujíá štejnaá data. Jeden tablet je vžšdý žvolen jako Paxoš líádr pro škupinu a tento líádr je vštupníám bodem pro vššechný tranšakce v teá to škupineš . Ve škupineš mohou takeá býá t repliký urcšeneá použe pro cšteníá ž duů vodu žvýáššeníá výákonu, ale týto repliký v Paxošu nemajíá volebníá praávo a nemohou še proto štaá t líádrý.

Spanner umožšnš uje šerialižovaneá pešimištickeá tranšakce pomocíá štriktníáho 2PL. Tranšakce obšahujíá neškolikanaá šobneá cšteníá výžšadujíácíá šdíálenýá nebo exkluživníá žaámek naá šledovanýá jedníám žaápišem. Vššechný commitý jšou šýnchronneš replikovaáný protokolem Paxoš. Tranšakce jšou nejefektivneš jšš íá, kdýžš aktualižujíá lokaá lníá data v jedneá škupineš . Spanner nicmeáneš podporuje i tranšakce pršeš ruů žneá škupiný, nažýávaneá tranšakcšníá uá cšaštníáci. Pro týto dištribuovaneá tranšakce še výužš íávaá 2PC protokol nad protokolem Paxoš. Takoveá to ršeššeníá šškaá luje dobrše do dešíátek uá cšaštníákuů , ale v pršíápadeš štovek uá cšaštníákuů jižš neuá mešrneš štoupaá frekvence žruššeníá a latence [19, š. 10].

Google F1 je nadštavba Google Spanner, kteraá navíác pršidaávaá podporu pro:

• dištribuovaneá SQL dotažý a možšnošt špojovaáníá tabulek ž externíách ždrojuů ,

• tranšakcšneš konžištentníá šekundaá rníá indexý,

• ašýnchronníá žmešný šcheámatu databaá že,

• optimištickeá tranšakce,

• automatickeá uklaádaáníá a žíáškaávaáníá hištorie jednotlivýách hodnot.

Vššechný indexý v F1 jšou plneš tranšakcšneš konžištentníá. Indexý jšou uložšený jako oddeš leneá tabulký ve Spanneru š klíácšem šložšenýám ž primaá rníách klíácšuů tabulek [3, š. 4].

- 31 -

4.2 NuoDB

NuoDB je produkt špolecšnošti NuoDB Inc. V roce 2010 býla žaložšena špolecšnošt NimbušDB š cíálem navrhnout uá plneš novýá týp databaá že nežatíážšenýá naávrhý ž konce 80týách let 20. štoletíá. Hlavníám cíálem býla výšokaá horižontaá lníá šškaá lovatelnošt, podpora ACID tranšakcíá a jednoduchošt žavedeníá do provožu a jejíá naá šledneá uá držšbý. V roce 2011 býla špolecšnošt pršejmenovaána na NuoDB.

Vlaštníá DDBS je roždeš len do tršíá vrštev a to na tranšakcšníá vrštvu, uá ložšnou vrštvu a adminištrativníá vrštvu.

• Tranšakcšníá vrštva, kteraá je tvoršena Tranšaction Engineš (TE), je žodpovešdnaá ža dodržšeníá atomicitý, konžištence a nežaávišlošti špoušštešnýách tranšakcíá. Nemaá žšaádnýá vhled do žpuů šobu uložšeníá dat. Tranšakcšníá vrštva je cšišteš in-memorý.

• ÚÚ ložšnaá vrštva, kteraá je tvoršena Storage Managerš (SM), je žodpovešdnaá ža žajišštešníá trvanlivošti dat po commitu tranšakce a ža pršíáštup k datuů m, pokud data nejšou k dišpožici v tranšakcšníá cachi.

• Adminištrativníá vrštva žajiššťuje jednoduchou špraávu clušteru. Na kažšdeám fýžickeám užlu bešžš íá agent, kterýá špoušštíá a výpíánaá jednotliveá TE a SM. Kažšdýá agent muů žše býá t špušštešn jako tžv. broker. Broker maá pršehled o vššech agentech v clušteru a šloužš íá takeá jako vštupníá bod pro špraávu clušteru.

Jednotliveá vrštvý še šškaá lujíá nežaávišle na šobeš a takeá na šelhaáníá reagujíá nežaávišle na šobeš .

Dveš nejduů ležš iteš jšš íá vrštvý, tranšakcšníá a uá ložšnaá jšou tvoršený libovolnýám pocštem užluů . Obeš týto komponentý jšou tvoršený jedníám programem špušštešnýám v roždíálnýách moá dech. Vššechný užlý jšou ši rovný, a tedý neexištuje žšaádnýá

- 32 -

Obrázek 2: Porovnání logické a fyzické struktury ukládání dat v tradičním normalizovaném schématu a hierarchickém schématu používaném v F1

Ždroj: vlaštníá žpracovaáníá na žaákladeš [3, š. 4]

koordinaá tor. Jednotliveá užlý jšou autentižovaáný protokolem SRP2 a komunikujíá špolu žaššifrovaneš .

Vlaštníá fungovaáníá probíáhaá naá šledovneš :

TE umožšnš uje pršipojeníá klientuů , paršuje a špoušštíá databaá žoveá dotažý proti datuů m uložšenýám ve šveá cachi. Pokud TE nemaá data v cachi (cache mišš), muů žše ši je výžšaádat od jineáho užlu (TE nebo SM). SM a TE špolu komunikujíá jednoduchýám peer-to-peer koordinacšníám protokolem. TE pravidelneš špoušštíá hodnotíácíá funkci, takžše víá, ktereá užlý odpovíádajíá nejrýchleji. Minimem, ktereá je tršeba, je jeden SM a jeden TE. V pršíápadeš potršebý je možšneá špuštit víáce jednotlivýách inštancíá TE nebo SM. V tomto pršíápadeš še po autentižaci vlaštníá inštance automatický žaršadíá do clušteru, a pokud je inštance TE, nacšte ši neškolik koršenovýách objektuů a muů žše prševžíát cšaá št tranšakcšníá žaá tešžše. Pokud še jednaá o inštanci SM, dojde nejprve k šýnchronižaci a poteá žacšne býá t aktivníá v clušteru.

NuoDB neuklaádaá data do tabulek, ale objektuů , ktereá nažýávaá Atomý. Atom interneš reprežentuje vlaštníá data, indexý nebo šcheámata. ACID vlaštnošti jšou aplikovaáný na Atom objektý. TE je žodpovešdnýá ža prševod Atom objektuů do SQL.

NuoDB použš íávaá MVCC jak pro commit, tak pro cšteníá. NuoDB štandardneš výužš íávaá uá rovenš Snapšhot ižolace, ale je podporovaána i Read commited.

TE je cache, kteraá držš íá kanonickou verži a potom libovolnýá pocšet ješšteš nedokoncšenýách nebo hištorickýách veržíá, ktereá mohou býá t potršebneá pro probíáhajíácíá tranšakce. Verže je nedokoncšenaá , dokud vlaštníácíá tranšakce neprovede commit. Dalšš íá výáhodou je, žše še žšaádnaá data nemušíá mešnit na míášteš uložšeníá, takžše aktualižace lže provaádeš t optimištický, protožše rollback žnamenaá použe šmažaáníá verže ž cache. Vššechný žpraávý jšou žašíálaáný ašýnchronneš , cožš umožšnš uje tranšakcíám pokracšovat ža pršedpokladu, žše konecšnaá aktualižace škoncšíá uá špešchem. Ašýnchronnošt v tranšakcíách dokaá žše žamaškovat žpožšdešníá v šíáti, ale v pršíápadeš , žše še tranšakce doštane ažš ke commitu, mušíá užš pocškat na potvrženíá [20, š. 2].

4.3 VoltDB

VoltDB je noveš navržšenaá databaá že še žamešršeníám na co nejveš tšš íá propuštnošt, šškaá lovaáníá na výžšaádaáníá, výšokou doštupnošt a odolnošt proti šelhaáníá.

Pro došažšeníá výtýcšenýách vlaštnoštíá žavaádíá VoltDB naá šledujíácíá koncepci a funkcionalitý:

• Data a jejich žpracovaávaáníá je roždeš leno špolecšneš a je rožmíáštešno na jednotlivaá jaádra CPÚ šhared-nothing hardware clušteru.

• Vššechna data jšou uložšena použe v pamešti a díáký tomu neníá potršeba buffer management.

• Tranšakce še špoušštíá šekvencšneš v pamešti a tíám še eliminuje potršeba žaámkuů a špinlockuů .

2 RFC 2945 - The SRP Authentication and Keý Exchange Sýštem

- 33 -

• Pro žajišštešníá výšokeá doštupnošti je VoltDB poštavena na neškolika funkcšnoštech: K-šafetý, detekce šíáťoveáho oddeš leníá, pršidaávaáníá užluů ža provožu.

• Sýnchronníá multi-mašter replikace a možšnošt výtvaá ršeníá šnapšhotuů daá le žvýššuje robuštnošt a žjednoduššuje žaá lohovaáníá.

• Logovaáníá pršíákažuů je daleko výákonneš jšš íá naáhrada tradicšníáho výtvaá ršeníá loguů

Týto vlaštnošti jšou v naá šledujíácíám textu detailneš ji popšaáný.

Pro žrýchleníá komunikace aplikace š databaá žíá obšahuje VoltDB noveá rožhraníá pro pršíáštup k uložšenýám proceduraám. Proto výkonaáníá jedneá tranšakce výžšaduje použe jednu výámešnu žpraáv meži klientem a šerverem. Kažšdaá uložšenaá procedura ve VoltDB pršedštavuje jednu tranšakci.

Ú tradicšníách databaá žíá dochaá žíá prši provaádešníá tranšakcíá k prodlevaám. Týto šýšteámý pak, abý výtíážš ilý centraá lníá procešor, radeš ji pršepíánajíá meži tranšakcemi. Avššak toto pršepíánaáníá výžšaduje intenživníá výužš íávaáníá žaámkuů a špinlockuů [22, š. 2].

Ú VoltDB k takovýámto prodlevaám nedochaá žíá, protožše vššechný tranšakce še odehraávajíá v uložšenýách proceduraá ch a vešškeraá data jšou uložšena v pamešti.

VoltDB databaá že je šložšenaá ž programuů , ktereá jšou uložšený v pamešti, a nažýávajíá še oddíálý. Oddíál je kombinace dat a výákonneá jednotký. VoltDB automatický výtvaá ršíá a dištribuuje týto oddíálý na jednotlivaá procešorovaá jaádra. Kažšdýá takovýá to oddíál je jednovlaáknovýá a obšahuje frontu tranšakcšníách požšadavkuů , ktereá špoušštíá poštupneš a exkluživneš proti švýám datuů m.

VoltDB umožšnš uje jednoducheá horižontaá lníá i vertikaá lníá šškaá lovaáníá. Vertikaá lníám šškaá lovaáníám je žde míánešno žvýššovaáníá výákonu jednotlivýách užluů , žejmeána žvýššovaáníá pocštuů jader procešoru, cožš umožšnš uje šníážš it latence prši dotažech napršíácš oddíálý. Horižontaá lníá šškaá lovaáníá dovoluje pršidaávaáníám užluů žvýššovat propuštnošt databaá že teámešrš lineaá rneš . Oba týto poštupý žvýššujíá pocšet oddíáluů v databaá ži. Toto še provede žcela automatický, bež nutnošti jakeáhokoli žaá šahu do aplikace nebo šcheámatu databaá že.

Tabulký jšou ve VoltDB deš lený podle hašhe primaá rníáho klíácše. Pro toto deš leníá ši VoltDB neuštaá le volíá tžv. deš líácíá klíácše tak, abý býla žaá tešžš co nejrovnomešrneš ji rožložšena a tedý výákon celeáho šýšteámu nejvýšššš íá. Pro dalšš íá žvýáššeníá výákonu umožšnš uje VoltDB žvolit tabulký, ktereá budou replikovaáný na vššechný oddíálý v clušteru, abý še žamežilo špojovaáníá tabulek ž ruů žnýách oddíáluů . Toto je výáhodneá u tabulek, ktereá še pršíálišš cšašto nemešníá, napršíáklad u cšíášelníákuů .

K-šafetý je šýnchronníá replikace oddíálu v clušteru. V pršíápadeš , žše je funkce K-šafetý žapnutaá , VoltDB automatický a tranšparentneš replikuje databaá žoveá oddíálý na ruů žneá databaá žoveá užlý tak, abý býla žajišštešna bežchýbnaá funkcšnošt i prši výápadku K užluů . Tedý v pršíápadeš , žše naprš. K je rovno jedneá , exištujíá v databaá ži vžšdý alešponš dveš kopie kažšdeáho oddíálu. Pro K rovno dvešma, exištujíá v databaá ži vžšdý alešponš trši kopie kažšdeáho oddíálu, atd. Replikovaneá oddíálý ovššem nešloužš íá použe jako žaá loha,

- 34 -

ale automatický pršebíárajíá cšaá št žaá tešžše. V pršíápadeš šelhaáníá jednoho oddíálu je praá ce pršešunuta na oštatníá funkcšníá repliký oddíáluů .

V pršíápadeš , žše dojde k roždeš leníá clušteru na podobneš velkeá cšaá šti, je pravdešpodobneá , žše kažšdaá ž tešchto cšaá štíá maá kompletníá kopii databaá že. Pro pršedejitíá tomu, abý obeš týto cšaá šti obšluhovalý klientý, lže žapnout detekci chýbý šíáteš , kteraá v tomto pršíápadeš žajištíá to, žše jedna cšaá št ši automatický výtvoršíá šnapšhot a výpne še. Rožhodnutíá, kteraá cšaá št še maá výpnout, še provede na žaákladeš ocšíášlovaáníá jednotlivýách užluů v clušteru. Jakmile je špraávnaá funkcšnošt šíáteš obnovena, lže obeš cšaá šti opeš t špojit pomocíá funkce Live Node Rejoin, anižš bý býlo nutneá databaá ži odštavovat.

Úžlý, ktereá býlý výpnutý, mohou býá t vraácený do clušteru pomocíá operace rejoin. Úžel ši nejprve štaáhne kopii dat pro švuů j oddíál od švýách šoušedníách užluů . Bešhem teá to operace vššechný puů vodníá užlý normaá lneš fungujíá a výršižujíá žšaá došti. Jakmile pršipojovanýá užel maá aktuaá lníá kopii šveáho oddíálu, plnohodnotneš še žacšleníá do clušteru a žacšne výršižovat požšadavký.

Jako doplnešk k výšokeá doštupnošti a trvanlivošti umožšnš uje VoltDB ješšteš online replikaci. Databaá žovaá replikace žajištíá, žše kažšdaá uškutecšnešnaá tranšakce na mašter clušteru je ašýnchronneš provedena i na žaá ložšníám clušteru, kterýá muů žše býá t i v jineám datoveám centru. Toto umožšnš uje provožovat hot štandbý databaá ži. V pršíápadeš , žše v hlavníám clušteru dojde ke kataštrofickeámu šelhaáníá, muů žše jej žaá ložšníá clušter jednodušše žaštoupit. Po obnoveš puů vodníáho clušteru lže jejich role opeš t jednodušše prohodit.

Ve žvolenýách intervalech VoltDB výtvaá ršíá šnapšhotý a uklaádaá je na dišk. Ú šnapšhotuů je žajišštešno, žše jšou tranšakcšneš konžištentníá. Výtvoršeníá šnapšhotu je možšneá proveášt na požadíá š minimaá lníám dopadem na výákon.

Ú aplikacíá, ktereá výžšadujíá 100% obnovitelnošt, lže žapnout logovaáníá pršíákažuů . Databaá že žapišuje špušštešníá kažšdeá uložšeneá procedurý do peržištentníáho uá ložš iššteš , ktereá še štalo meži dvešma šnapšhotý. Databaá ži lže v pršíápadeš potršebý obnovit tak, žše še použš ije pošledníá šnapšhot a provedou še vššechný pršíákažý uložšeneá v logu pršíákažuů . V pršíápadeš reštartu toto VoltDB provede automatický. Logovaáníá pršíákažuů je konfigurovatelneá , lže volit šýnchronníá nebo ašýnchronníá žaápiš a takeá frekvenci, š jakou še log škutecšneš maá žapšat na dišk.

VoltDB podporuje operace š globaá lníám cšteníám nebo šumarižacšníá operace. VoltDB pro týto operace použš íávaá MapReduce žpracovaáníá, kdý kažšdýá oddíál žpracuje co nejveš tšš íá množšštvíá praá ce. Vedle tohoto podporuje VoltDB takeá materialižovaneá pohledý [34, š. 4].

4.4 ClustrixDB

CluštrixDB je databaá že, kterou lže pršíámo výmešnit ža MýSQL. Je tedý navržšena tak, abý pršíámo podporovala ACID, ale oproti MýSQL pršidaávaá možšnošt šnadneáho šškaá lovaáníá a výšokeá doštupnošti. Je cíálenaá na kombinaci ruů žnýách týpuů žaá tešžše, konkreá tneš OLTP i OLAP.

- 35 -

CluštrixDB pro žajišštešníá konžištence výužš íávaá kombinaci MVCC, dvoufaá žoveáho žamýkaáníá a Paxošu. Tato kombinace žajiššťuje možšnošt šškaá lovaáníá prši žachovaáníá ACID. Prši cšteníá še výužš íávaá šnapšhot ižolace, kteraá nevýžšaduje použš itíá žaámkuů a prši žaápišu še pro žameženíá konfliktuů výužš íávaá dvoufaá žoveáho žamýkaáníá. Výužš itíá kombinace tešchto metod žajiššťuje, žše v DBMS nekoliduje cšteníá še žaápišý a opacšneš .

CluštrixDB pro žajišštešníá konžištence prši žachovaáníá možšnošti šškaá lovaáníá výužš íávaá :

• Sýnchronníá replikaci v raámci clušteru. Vššechný žuá cšaštnešneá užlý mušíá žaápiš potvrdit pršed tíám, nežš je žaápiš škutecšneš dokoncšen.

• Výužš itíá protokolu Paxoš pro dištribuovaneá tranšakce.

• Podporuje naá šledujíácíá uá rovneš ižolace: Read committed, Repeatable read a omeženeš Serialižable.

• MVCC umožšnš uje cšteníá bež použš itíá žaámkuů a takeá žaápiš neblokuje cšteníá.

Úžš ivatelškeá tabulký jšou nejprve horižontaá lneš roždeš lený do reprežentacíá podle indexuů . V kažšdeá reprežentaci je špocšíátanýá hašh podle dištribucšníáho klíácše. Dištribucšníá klíácš je tvoršen žvolenýámi šloupci nebo indexem nebo jeho cšaá štíá. Kažšdaá reprežentace je daá le deš lenaá na ršežý podle dištribucšníáho klíácše. Pocšet ršežuů na reprežentaci je užš ivatelšký konfigurovatelnýá. V pršíápadeš požšadavku na výšokou doštupnošt jšou ž jednotlivýách ršežuů výtvoršeneá repliký a týto repliký jšou umíáštešneá na jineá užlý v clušteru, abý v pršíápadeš výápadku užlu býla databaá že štaá le doštupnaá .

Pro dlouhodobou optimaá lníá funkcšnošt je výužš íávaá n rebalancer. Jednaá še o proceš bešžš íácíá na požadíá a žajišštujíácíá naá šledujíácíá:

• Kažšdaá reprežentace maá adekvaá tníá pocšet ršežuů .

• Reprežentace maá odpovíádajíácíá dištribucšníá klíácš tak, abý býlý ršaádký rovnomešrneš roždeš leneá do ršežuů .

• RŽ ežý jšou rovnomešrneš roždištribuovaneá napršíácš clušterem.

CluštrixDB’š Querý Optimižer še šnažš íá kažšdýá dotaž špuštit š maximaá lníám možšnýám paralelišmem. Toho je docíáleno dištribuovanýám dotažovacíám plaánovacšem, kompilaá torem a dištribuovanýámi šhared-nothing výákonnýámi jednotkami (execution engineš). CluštrixDB Querý Optimižer je žaložšen na projektu The Cašcadeš Framework for Querý Optimižation [26, š. 4].

4.5 MemSQL

MemSQL je real-time in-memorý dištribuovanaá relacšníá databaá že žamešršenaá na žpracovaáníá velkeáho pocštu tranšakcíá a real-time analýtiku. MemSQL je žaložšena na dvouvrštveá architekturše šklaádajíácíá še ž agregacšníách užluů a koncovýách (leaf) užluů . Agregacšníá užlý majíá pršehled o celeám clušteru a šloužš íá jako vštupníá braána do clušteru. Úklaádajíá použe metadata a referencšníá data, dištribuujíá dotažý na koncoveá užlý a naá šledneš šklaádajíá díálcšíá výášledký dohromadý, ježš pak žašíálajíá

- 36 -

klientovi. Žmešnou pomešru agregacšníách a koncovýách užluů lže pršižpuů šobit clušter špecifickeá žaá tešžš i. Pršidaáníám agregacšníách užluů lže žvýášš it maximaá lníá pocšet šoucšašneš pršištupujíácíách klientuů .

Koncoveá užlý šloužš íá jako uá ložšneá a výápocšetníá užlý. Data jšou automatický dištribuovaána do vššech užluů tak, abý býlo umožšnešno paralelníá špoušštešníá dotažuů .

Použe prši replikaci dochaá žíá ke komunikaci meži užlý v raámci jedneá vrštvý (agregaá tor–agregaá tor nebo lišt-lišt). Ve vššech oštatníách pršíápadech je komunikace meži užlý žajiššťovaána SQL pršíákažý nad MýSQL protokolem. Napršíáklad clušter heartbeatš jšou implementovaáný jako dotažý „SELECT 1“ nikoli neš jakýám jinýám špecifickýám žpuů šobem. Obeš vrštvý nabíážíá automatickeá žotaveníá v pršíápadeš šelhaáníá šerveru pro žajišštešníá fault-tolerance.

MemSQL použš íávaá pokrocšileá techniký, abý nebýlo nutneá použš itíá žaámkuů a abý žaápišý neblokovalý cšteníá. Vedle MVCC jšou ješšteš výužš íávaáný datoveá štrukturý, ktereá nevýžšadujíá použš itíá žaámkuů . MemSQL výužš íávaá skiplist jako švuů j hlavníá index. Skiplist pršinaá šš íá lepššíá výákon prši žachovaáníá šoubešžšnošti, je to výáhodnaá technika pro hledaáníá a uá pravu dat. Toto je výážnamnýá roždíál proti jinýám databaá žíám výužš íávajíácíá B-Tree indexý uložšeneá na dišku.

MemSQL je plneš kompatibilníá naáhrada ža MýSQL a lže tedý použš íát MýSQL konektorý (ODBC a JDBC) a odpovíádajíácíá klientškeá knihovný pro kažšdýá výážnamneš jšš íá programovacíá jažýk. Navíác MemSQL nabíážíá nativníá podporu pro uklaádaáníá a uá pravu JSONu. MemSQL výhovuje štandardu ANSI SQL-92.

S kažšdýám novýám dotažem MemSQL automatický odštraníá parametrý a výtvoršíá exekucšníá plaán napšanýá v C++, kterýá je žkompilovaán do štrojoveáho koá du. MemSQL ši uklaádaá vššechný žkompilovaneá exekucšníá plaáný do šveáho uá ložš iššteš . V pršíápadeš , žše neškterýá budoucíá dotaž odpovíádaá takoveámuto parametrižovaneámu dotažoveámu plaánu, lže okamžš iteš výužš íát pršedkompilovanou verži.

MemSQL umožšnš uje automatickou výšokou doštupnošt tak, žše užš ivatel naštavíá parametr redundance v clušteru na dveš . Databaá že automatický naštavíá a špaá ruje dva koncoveá užlý, v nich výtvoršíá hlavníá oddíál a k nim odpovíádajíácíá žaá ložšníá oddíál. Žaá ložšníá oddíál je pršešnaá replika hlavníáho oddíálu. Kažšdýá užel maá pršibližšneš polovinu hlavníách a polovinu žaá ložšníách oddíáluů , abý býla žaá tešžš rovnomešrneš rožvržšena. V pršíápadeš šelhaáníá užlu, agregaá tor automatický pršešune vššechný uá lohý na druhýá užel a povýášš íá žaá ložšníá oddíálý na hlavníá, anižš bý to neš jak ovlivnilo výákon.

MemSQL provaádíá šharding automatický na žaákladeš užš ivatelem naštavitelneáho parametru. Standardneš je naštaven jeden oddíál na jedno procešoroveá jaádro. Na roždíál od tradicšníách databaá žíá, ktereá jšou navržšený tak, abý bešžšelý na jednom šerveru, je MemSQL dištribuovanýá DBMS š tranšparentníám a bežuá držšbovýám šhardingem.

MemSQL použš íávaá k žajišštešníá trvanlivošti peržištentníá logý a šnapšhotý. Tranšakce provedeneá v pamešti jšou uložšený do tranšakcšníáho bufferu. Proceš bešžš íácíá na požadíá pravidelneš prochaá žíá tento buffer a uklaádaá týto logý na dišk. Pokud je

- 37 -

naštavena velikošt tranšakcšníáho bufferu na nulu, potom databaá že v raámci tranšakce uložš íá data i na dišk ješšteš pršed potvrženíám tranšakce. Dalšš íám parametrem, kterýá je užš ivatelšký naštavitelnýá, je velikošt logu. Jakmile je teá to velikošti došažšeno MemSQL udeš laá obraž (šnapšhotš) celeá databaá že a uložš íá jej na dišk. Toto umožšnš uje užš ivateluů m jemnou kontrolu nad výákonem a robuštnoštíá databaá že.

MemSQL podporuje online žaá lohovaáníá a obnovu. Obeš operace lže dokoncšit špušštešníám jedineáho pršíákažu a mohou bešžšet na požadíá prši normaá lníá žaá tešžš i.

Kažšdýá oddíál ši uklaádaá vlaštníá log tranšakcíá. Toto umožšnš uje výážnamneš šníážš it cšaš obnový dat, kdý obnový oddíáluů mohou bešžšet paralelneš a nežaávišle na šobeš . Prši obnoveš databaá že MemSQL vežme nejnoveš jšš íá šnapšhot a provede žbýtek tranšakcíá ž logu [35].

4.6 ScaleBase

ScaleBaše je relacšníá databaá žovýá clušter žaložšenýá na MýSQL/InnoDB uá ložš iššti, optimaližovanýá pro weboveá aplikace a cloud. ScaleBaše neníá novýá DBMS, ale je žaložšen na výužš itíá MýSQL šerveruů a jeho uá ložš iššteš InnoDB. ScaleBaše žjednoduššuje žapojeníá a špraávu jednotlivýách MýSQL užluů do clušteru.

RŽ eššeníá ScaleBaše pršidaávaá dalšš íá dveš komponentý. Jednaá še o management a tranšakcšníá vrštvu.

Na konfiguracšníách šerverech, ktereá pršedštavujíá management celeáho clušteru, jšou uložšena vešškeraá metadata a konfiguracšníá data ke clušteru.

Tranšakcšníá vrštva neuštaá le optimaližuje dištribuci dat lokaá lneš i napršíácš regioný a cloudem tak, abý neuštaá le dochaá želo k optimaližaci výákonu a šškaá lovatelnošti. Tedý abý nejcšašteš ji špoušštešneá dotažý mohlý býá t provedený na jednom užlu a nebýlo tršeba provaádeš t dotažý pršeš víáce oddíáluů . V pršíápadeš dotažuů , ktereá neníá

- 38 -

Obrázek 3: Schématické znázornění ScaleBase clusteru


možšneá proveášt na jednom užlu, še tranšakcšníá manažšer poštaraá o dištribuci pod-dotažuů konkreá tníám užluů m a jejich odpovešdi naá šledneš pošklaádaá a pršedaá klientovi. Tranšakcšníá vrštva špravuje vššechný tranšakce, podporuje SQL dotažovacíá model a špojeníá tabulek ž ruů žnýách databaá žíá prši žachovaáníá ACID.

Jako uá ložšnou vrštvu výužš íávaá ScaleBaše štandardníá DBMS MýSQL/InnoDB.

Clušterý mohou býá t navržšený ruů žnýám žpuů šobem a pršižpuů šobený tak pršedpoklaádaneá žaá tešžš i. Na obraá žku cšíášlo 3 jšou žnaá žornešný dohromadý trši oddíálý. V kažšdeám oddíále je vžšdý jeden hlavníá užel, kterýá umožšnš uje cšteníá i žaápiš, a dveš dalšš íá repliký urcšeneá použe pro cšteníá. Toto umožšnš uje výšokou doštupnošt v raámci oddíálu a takeá to umožšnš uje šškaá lovat cšteníá. Vššechný oddíálý dohromadý tvoršíá šhared-nothing clušter, kterýá muů žše býá t rožproštršen pršeš neškolik lokalit, anižš bý býlo tršeba provaádeš t jakeákoli žmešný v aplikacíách, nebo upravovat databaá žoveá šcheáma [24, š. 2].

4.7 ScaleDB

ScaleDB tranšparentneš pršemešníá jednotlivou databaá žovou inštanci MariaDB nebo MýSQL do clušteru, kde víáce databaá žovýách inštancíá žpracovaávaá šdíálenaá data. Výužš íávaáníám clušteru je umožšnešno šškaá lovaáníá tíám, žše še dýnamický pršidaávajíá databaá žoveá a uá ložšneá ždroje, anižš bý býlo tršeba data deš lit nebo provaádeš t šharding. Clušter takeá žajiššťuje výšokou doštupnošt tíám, žše žde neníá SPoF.

Vžhledem k tomu, žše vššechný databaá žoveá inštance pršištupujíá ke štejneá šadeš dat, mušíá šýšteám žajištit koordinaci žmešn dat na vššech databaá žovýách inštancíách tak, žše kdýkoli še databaá žovaá inštance dotaá žše na data, doštane aktuaá lníá verži i pokud bý tato data býla jinou inštancíá žmešnešna. ScaleDB žajiššťuje tuto funkcionalitu tíám, žše podporuje žamýkaáníá na uá rovni clušteru a upožorníá databaá žoveá užlý, pokud býla data žmešnešna jinýám užlem.

- 39 -

Obrázek 4: Schematické znázornění typického ScaleDB clusteru


ScaleDB še cšleníá na trši komponentý:

• Databaá žovaá vrštva je tvoršena šouborem databaá žovýách užluů propojenýách pocšíátacšovou šíátíá. V pršíápadeš MýSQL a MariaDB kažšdýá databaá žovýá užel obšahuje inštanci MýSQL/MariaDB šerveru, kterýá výužš íávaá ScaleDB jako uá ložšnýá šýšteám. Vššechný databaá žoveá užlý žpracovaávajíá šdíálenaá data, kteraá jšou špravovaána uá ložšnou vrštvou. Se ScaleDB je kompletníá databaá že doštupnaá kažšdeámu databaá žoveámu užlu a kažšdýá databaá žovýá užel muů žše cšíášt a žapišovat celou databaá ži.

• ÚÚ ložšnaá vrštva je tvoršena kolekcíá uá ložšnýách užluů propojenýách pocšíátacšovou šíátíá. ÚÚ ložšnaá vrštva špravuje data, je to trvanlivaá uá ložšnaá vrštva pro databaá žoveá užlý. Data jšou organižovaána do blokuů , ktereá jšou naáhodneš rožproštršený pršeš uá ložšneá švažký. Kažšdýá švažek še šklaádaá ž jednoho nebo víáce uá ložšnýách užluů . ScaleDB uklaádaá data do blokoveš štrukturovanýách šouboruů . Jednotliveá šouborý jšou roždeš lený na bloký pevneá velikošti. Týto bloký jšou uložšený v clušteru na jednom nebo víáce užlech, ktereá še nažýávajíá uá ložšneá užlý. ÚÚ ložšnýá užel, na kterýá še maá uložš it blok dat, je žvolen naáhodneš . Pro žajišštešníá výšokeá doštupnošti je kažšdýá uá ložšnýá užel žrcadlen, tedý uá ložšneá užlý še vžšdý pršidaávajíá v paá ru.

• Manažšer clušteru je pršipojenýá k šíáti a žajiššťuje integritu meži procešý v ruů žnýách databaá žovýách užlech. Vžhledem k tomu, žše data jšou doštupnaá vššem databaá žovýám užluů m v clušteru, roždíálneá databaá žoveá užlý mohou míát konfliktníá procešý nad štejnýámi datý. Manažšer clušteru maá na štarošti ršeššeníá konfliktuů meži databaá žovýámi užlý v clušteru. Týpickaá inštalace obšahuje dveš inštance manažšera clušteru, výákonneáho a žaá ložšníáho. V pršíápadeš , žše výákonnýá manažšer šelžše, pršebíáraá jeho funkci žaá ložšníá. Manažšer clušteru špravuje žaámký, ktereá ršešš íá konfliktý meži užlý v clušteru, napršíáklad pokud še dva užlý šnažš íá žaktualižovat jeden žaá žnam [36, š. 3].

4.8 Ostatní

4.8.1 dbShards

DbShardš je nadštavba nad MýSQL databaá žíá. Vývinula ji špolecšnošt CodeFutureš, kteraá še poždeš ji pršejmenovala na AgilData. AgilData nýníá použe žajiššťuje podporu pro štaávajíácíá inštalace, ale dalšš íá výážnamnýá rožvoj ršeššeníá še neocšekaávaá i vžhledem k pomešrneš šširokeá doštupnošti podobnýách naá štrojuů , tedý naá štrojuů umožšnš ujíácíách horižontaá lníá šškaá lovaáníá nad MýSQL [7, š. 6].

4.8.2 CockroachDB

Hlavníám cíálem je žajišštešníá globaá lníá konžištence a šchopnošt pršecškat jakýákoli výápadek.

Je to openšource varianta Google F1, kterou vývíájejíá býávalíá výávojaá rši Google [37].

- 40 -

4.8.3 Apache Trafodion

Apache Trafodion je SQL databaá že poštavenaá nad Apache Hadoop. Tedý ršeššeníá žamešršeneá na provožníá žaá tešžš pro žacšlenešníá do proštršedíá Hadoop Big Data.

Hlavníá charakterištiký:

• plneš podporuje jažýk ANSI SQL,

• plnaá podpora ACID pro cšteníá i žaápiš vcšetneš dištribuovanýách tranšakcíá,

• heterogenníá uá ložš iššteš vcšetneš nativníáho pršíáštupu k datoveámu uá ložš iššti,

• podpora pro výšokou doštupnošt,

• podpora pro velkeá šadý dat díáký optimaližovaneámu intra-querý paralelišmu,

• kompilovaneá a bešhoveá optimaližace pro OLTP žaá tešžš ,

• šerialižace tranšakcíá pomocíá HBaše-Trx implementace MVCC,

• obnoveníá tranšakcíá k žajišštešníá konžištence databaá že,

• podpora víácevlaáknovýách SQL klientuů ,

• netranšakcšníá pršíámýá pršíáštup k Hbaše tabulkaám [38, š. 1].

4.8.4 SAP HANA

SAP HANA je špecifickeá in-memorý ršeššeníá (appliance) žamešršeneá na hýbridníá datovou analýtiku - HTAP. Jednaá še o kombinaci hardwaru a šoftwaru a dodaávaá še jako optimaližovanýá komplet š hardware partnerý SAPu. SAP HANA obšahuje dveš relacšníá databaá žoveá uá ložš iššteš . Pro kažšdou tabulku lže žvolit, ktereá še použš ije:

• Sloupcoveš orientovaneá uá ložš iššteš optimaližovaneá pro uklaádaáníá velkeáho množšštvíá dat, kteraá jšou agregovanaá a použš íávanaá v analýtickýách operacíách.

• RŽ aádkoveš orientovaneá uá ložš iššteš pro uklaádaáníá relacšníách dat. Toto uá ložš iššteš je optimaližovaneá pro žaápišý, maá menššíá kompreši a nižššš íá výákon pro dotažý oproti šloupcoveámu uá ložš iššti [39, š. 4].

4.8.5 TIBCO ActiveSpaces

TIBCO ActiveSpaceš® je dištribuovanýá peer-to-peer in-memorý data grid, š konfigurovatelnou replikacíá. TIBCO ActiveSpaceš® kombinuje vlaštnošti a výákon databaá že, cache šýšteámu a meššaging šoftwaru pro podporu rýchle še mešníácíách dat a CEP. Úmožšnš uje off-load výšoce tranšakcšneš žatíážšenýách šýšteámuů a výávojaá ršuů m dovoluje koncentrovat še použe na bušinešš logiku, nežš abý še žabýávali komplexnoštíá dištribuovaneáho fault-tolerant šýšteámu [40, š. 11].

- 41 -

5 Trendy ve vývoji v oblasti NewSQL databází

Pršeštožše NewSQL databaá že nabíážíá podporu šilnýách ACID tranšakcíá, jejich adopce je žatíám velmi požvolnaá . To je v pršíámeám kontraštu k rýchlošti adopce NoSQL databaá žíá o neškolik let dršíáve. Tento roždíál je žpuů šoben žejmeána tíám, v jakýách šýšteámech jšou konkreá tníá ršeššeníá použš íávaána. NoSQL šýšteámý jšou prševaá žšneš výužš íávaáný v novýách webovýách aplikacíách. Oproti tomu NewSQL databaá že jšou špíášše cíálený do štaávajíácíách podnikovýách informacšníách šýšteámu, kde je vuů le ke žkouššeníá neovešršenýách ršeššeníá velmi malaá . Proto veš tšš ina dodavateluů NewSQL databaá žíá nabíážíá naá štroje, ktereá ušnadnš ujíá migraci a nebo integraci jejich ršeššeníá [33, š. 53].

Dalššíám velkýám cíálem dodavateluů jšou maleá žacšíánajíácíá špolecšnošti (štart-up), ktereá ši nemohou dovolit na žacšaá tku inveštovat do tradicšníách robuštníách RDBMS, ale radeš ji výužš íávajíá ršeššeníá, ktereá jim dovolíá plýnule navýššovat výákon švýách informacšníách šýšteámuů , a tak š naruů štajíácíá žaá tešžš íá pršidaávat komoditníá šerverý, takžše jejich šýšteám bude velmi dobrše horižontaá lneš šškaá lovatelnýá. Proto cšašto nabíážejíá tžv. komunitníá verže, ktereá jšou omeženeá švojíá funkcionalitou (VoltDB), nebo možšnoštíá šškaá lovaáníá (NuoDB).

Pošledníá oblaštíá, kde še šnažš íá býá t výárobci NewSQL šýšteámuů aktivníá je cloud computing. Tak jako ve veš tšš ineš oblaštíá cloud computingu, jšou nejveš tšš íá špolecšnošti takeá nejveš tšš íámi hraácši na poli DBaaS díáký uá šporaám ž rožšahu. Vššechný týto špolecšnošti puů vodneš poškýtovalý inštance tradicšníách jedno-užlovýách DBMS, cšašto MýSQL. Pro pršiblíážšeníá švýách produktuů užš ivateluů m a díáký šnadneá vertikaá lníá šškaá lovatelnošti žacšali výárobci NewSQL databaá žíá nabíážet šveá produktý v raámci cloudovýách šlužšeb. Cluštrix umožšnš uje špouššteš t švojíá databaá ži u rožlicšnýách XaaS provideruů [41]. Oproti tomu MemSQL pršíámo nabíážíá švojíá databaá ži jako šlužšbu. Pro tuto DBaaS výužš íávaá platformu AWS [42].

Ovššem i šami poškýtovateleá pršichaá žejíá š vlaštníámi ršeššeníámi, kteraá lže ršadit meži NewSQL šýšteámý. Amažon puů vodneš nabíážel švoje ršeššeníá Amažon DýnamoDB, cožš je uá ložš iššteš klíácš-hodnota, ale švoje portfolio rožššíárš il o plneš šškaá lovatelneá ršeššeníá nabíážejíácíá ACID tranšakce, ktereá nažýávaá Aurora. Obdobnaá ršeššeníá še žacšíánajíá objevovat i u oštatníách poškýtovateluů cloudovýách šlužšeb. Google žacšíánaá poškýtovat švojíá databaá ži Spanner jako šlužšbu v raámci šveá Google Cloud Platform.

S tíámto šouvišíá šnaha neškterýách dodavateluů NewSQL pršijíát š ršeššeníám, ktereá umožšníá bešh jednotlivýách užluů v roždíálnýách datacentrech. Toto je žcela novýá pršíáštup, kterýá v pršedchožíách akademickýách projektech nebýl žahrnut. Pro moderníá výápocšetníá šýšteámý je týpickeá , žše je velmi šnadneá je našadit v ruů žnýách datacentrech, dokonce na ruů žnýách kontinentech. Jakýákoli šoucšašnýá NewSQL databaá žovýá šýšteám muů žše býá t špušštešn tak, žše še bude šýnchronneš replikovat pršeš WAN, ale protožše žpožšdešníá na WAN linkaách je neškolikanaá šobneš výšššš íá, nežš v raámci jednoho datacentra, žpuů šobíá to výáražnou degradaci výákonu takoveáhoto šýšteámu.

- 42 -

Míášto toho še meži vždaá lenýámi datacentrý veš tšš inou provaádíá ašýnchronníá replikace. Žatíám použe Google Spanner a CockroachDB nabíážejíá podporu pro výšoce konšištentníá replikaci pršeš WAN.

Google k žajišštešníá šýnchronníá replikace výužš íávaá výšoce pršešnýá hodinovýá šignaá l, kterýá je žajiššťovaán externíám hardware GPS modulem [19, š. 5]. CockroachDB k tomuto výužš íávaá hýbridníách logickýách hodin, kdý pro urcšitýá cšašovýá uá šek je žvolen vedoucíá v algoritmu žajiššťujíácíám konžištenci [37]. Spolecšnošt NuoDB ohlaá šila, žše na tomto pracuje, nicmeáneš podpora pro šýnchronníá replikaci pršeš WAN še objevíá ažš v nešktereá ž pršíášš tíách veržíá.

Dalššíá oblaštíá, ve ktereá dochaá žíá k výávoji u NewSQL DBMS, je praá ce še šekundaá rníámi indexý. Vššechný NewSQL šýšteámý jšou decentraližovaneá a použš íávajíá roždeš leneá šekundaá rníá indexý. To žnamenaá , žše kažšdýá užel špravuje cšaá št indexu, míášto abý držšel celou kopii. Roždíál meži roždeš lenýám indexem a replikovanýám indexem je, žše u roždeš leneáho indexu, še mušíá dotažý provaádeš t na víáce užlech, ale v pršíápadeš tranšakcšníách aktualižacíá je potršeba pršíáštupu použe na jeden užel. Ú dištribuovaneáho indexu je to opacšneš . Hledaáníá lže proveášt použe na jednom užlu, ale v pršíápadeš aktualižace hodnotý šekundaá rníáho indexu je potršeba proveášt dištribuovanou tranšakci, kteraá žaktualižuje vššechný kopie v databaá ži [33, š. 7].

Cluštrix proto pršiššel š metodou decentraližovaneáho šekundaá rníáho indexu, kterýá výužš íávaá oba týto pršíáštupý. DBMS nejprve udržšuje replikovanýá hrubýá index na kažšdeám užlu, cožš dovoluje šmešrovat dotažý k odpovíádajíácíám užluů m. Na tešchto užlech je naá šledneš špušštešn puů vodníá dotaž. Takovýá to dvouuá rovnš ovýá pršíáštup žmenššuje potršebu koordinace, kteraá je žapotršebíá pro udržšeníá konžištence šekundaá rníáho indexu [26, š. 5].

Pošledníá oblaštíá, kde probíáhaá urcšitýá pošun, je v homogeniteš architekturý. Homogenita architekturý žnamenaá , žše vššechný užlý jšou ši rovný a výkonaávajíá štejnou praá ci. Praáce je potom dištribuovanaá meži užlý použe na žaákladeš dat, kteraá špravujíá konkreá tníá užlý. Proti tomu štojíá pršíáštup, kdý exištujíá ruů žneš špecialižovaneá užlý. Meži pršíákladý heterogenníá architekturý patršíá NuoDB, MemSQL a SAP HANA. Týto šýšteámý mohou míát pršíámo konkreá tníá užlý navržšeneá pro špecifickou žaá tešžš , anebo jšou šice vššechný užlý štejneá , ale jednotliveá užlý jšou výhražený pro jineá aplikace. Jako pršíáklad lže vžíát použš itíá pro HTAP aplikace, kdý cšaá št užluů je výhražena pro tranšakcšníá žaá tešžš a jineá užlý jšou výhražený pro analýtickeá dotažý [43, š. 1].

K tomuto ršeššeníá pršištupujíá i tradicšníá dodavateleá RDBMS ršeššeníá (Oracle, Microšoft, IBM), kteršíá šveá produktý daá le rožvíájejíá a doplnš ujíá švaá ršeššeníá o funkcšnošti nebo komponentý, ktereá umožšnš ujíá pokrýá t daleko šš iršš íá pole aplikacíá [44, š. 2]. Microšoft doplnil švuů j produkt MS SQL Server 2016 o in-memorý komponentu žamešršenou na výšokou OLTP žaá tešžš [45]. Tato komponenta, puů vodneš nažýávanaá Microšoft Hekaton, štavíá na podobnýách technologiíách jako NewSQL DBMS. Vedle toho, žše jde o in-memorý ršeššeníá, výužš íávaá optimištickýá pršíáštup v podobeš MVCC. Hekaton takeá výužš íávaá jineá indexý, konkreá tneš Bw-tree [46]. V raámci cloudoveá šlužšbý Microšoft Ažure je k dišpožici i toto in-memorý rožššíáršeníá v Ažure SQL databaše. Oracle

- 43 -

nabíážíá in-memorý rožššíáršeníá Oracle Databaše In-Memorý a Oracle TimešTen In-Memorý Databaše. Stranou neštojíá ani IBM š DB2 a dašhDB [44, š. 5].

Databaá žovýá trh bý nýníá mohl býá t cšlenešn do cštýršech kategoriíá: Tradicšníá relacšníá DBMS, OLAP datoveá škladý, NoSQL DBMS a NewSQL DBMS. V delšš íám cšašoveám horižontu še pršedpoklaádaá , žše bude dochaá žet ke konvergenci funkcionalit meži žaá štupci jednotlivýách týpuů DBMS. V budoucnu týto databaá žoveá šýšteámý budou podporovat relacšníá model a SQL, pokud jej jižš nepodporujíá. Takeá týto šýšteámý budou podporovat žaá rovenš jak OLTP, tak analýtickeá dotažý, štejneš jako HTAP DBMS. Ažš toto naštane, potom jižš takoveá to cšlenešníá na kategorie bude poštraádat šmýšl [33, š. 54].

- 44 -

Závěr

Cíálem teá to praá ce býlo pršedštavit, prožkoumat a popšat architekturu NewSQL DBMS, tj. horižontaá lneš šškaá lovatelnýách DBMS žamešršenýách na výšokou žaá tešžš a žajišštujíácíá ACID tranšakce a ukaá žat roždíálý od oštatníách DBMS.

Prvníá relacšníá DBMS žacšíánajíá vžnikat koncem 70týách let. Naá šledneš dochaá žíá k výávoji databaá žíá urcšenýách pro datoveá škladý a špoušštešníá analýtickýách dotažuů . Týto DBMS še žacšíánajíá objevovat ve druheá polovineš 80týách let. Na pršelomu mileánia, š rožvojem webu 2.0 pršichaá žíá potršeba jednodušše horižontaá lneš šškaá lovatelnýách šýšteámuů , vcšetneš DBMS. RŽ eššeníám jšou NoSQL DBMS. Naá šledneš pak po roce 2005 vžnikajíá NewSQL DBMS.

Vžhledem k tomu, žše týp aplikacíá, pro ktereá jšou NewSQL DBMS urcšený, še nejcšašteš ji výškýtujíá v podnikoveá šfeárše, je adopce tešchto šýšteámuů výážnamneš pomalejšš íá na roždíál od NoSQL. To je takeá žršejmeš duů vodem, procš prševlaádaá pocšet komercšníách ršeššeníá.

Acškoli jšou NewSQL nejnoveš jšš íámi DBMS, jšou poštavený na technologiíách, ktereá býlý pršedštavený v 70týách, 80týách a žacšaá tku 90týách let. Je pravda, žše vššechný týto principý še objevilý v databaá žovýách produktech, ale vžšdý ižolovaneš a š minimaá lníám benefitem pro výášlednýá produkt. Co cšiníá NewSQL databaá že výá jimecšneá , je špojeníá tešchto principuů dohromadý a jejich implementace vhodnaá i pro produkcšníá našaženíá.

Takeá še žmešnila doštupnošt HW, nýníá je šnadno doštupneá velkeá množšštvíá komoditníách šerveruů jednodušše žapojitelnýách do clušteru a týto šerverý takeá nabíážejíá podporu pro velkeá množšštvíá pamešti RAM, takžše škoro vššechný databaá že mohou býá t in-memorý, cožš je duů ležš iteá pro výšokou tranšakcšníá žaá tešžš , jednu ž duů ležš itýách vlaštnoštíá NewSQL databaá žíá.

Tradicšníá dodavateleá relacšníách DBMS še šnažš íá pršižpuů šobit tešmto potršebaám trhu a implementujíá funkcionalitý, ktereá umožšníá žvýášš it tranšakcšníá žaá tešžš a žaá rovenš takeá funkcionalitý umožšnš ujíácíá špouššteš t analýtickeá dotažý.

Pošledníá oblaštíá, ve ktereám hrajíá DBMS šýšteámý výážnamnou roli, je cloud computing. Žde poškýtovateleá nejprve poškýtovali NoSQL ršeššeníá a nebo tranšakcšníá SQL ršeššeníá, ktereá ale býlo omeženo na jeden užel. Nýníá jižš nabíážejíá vlaštníá NewSQL ršeššeníá a nebo nabíážejíá ršeššeníá ve špolupraá ci š neškterýám výárobcem NewSQL DBMS.

Dochaá žíá tedý k pršibližšovaáníá jednotlivýách produktuů a dle neškterýách analýtikuů i ke štíáraáníá hranic meži tešmito kategoriemi. Takeá dochaá žíá ke štaá le intenživneš jšš íámu výužš íávaáníá databaá žíá a potršebeš výáražneš výšššš íáho tranšakcšníáho výákonu.

Žda-li budou NewSQL DBMS prševratnou technologiíá (dišruptive technologý), jak ji definoval Claýton Chrištenšen ve šveá kniže The Innovator‘š Dilemma [47, š. xiii] a jak še je šnažš íá neškteršíá výárobci NewSQL prežentovat, nebo ještli tradicšníá výárobci

- 45 -

poštupneš rožššíárš íá šveá produktý o vlaštnošti, ktereá nýníá nabíážejíá použe NewSQL a tedý nepršepuštíá šveá míášto jinýám, še teprve ukaá žše.

- 46 -

Seznam použitých zdrojů

[1] CODD, E. F. A Relational Model of Data for Large Shared Data Banks [online]. Communication of the ACM, June 1970. [cit. 2016-07-02] Doštupneá ž: http://www.šeaš.upenn.edu/~živeš/03f/ciš550/codd.pdf

[2] DiNÚCCI, D. Fragmented Future [online]. 1999. [cit. 2016-07-02] Doštupneá ž: http://darcýd.com/fragmented_future.pdf

[3] SHÚTTE, J. et al. F1: A Distributed SQL Database That Scales [online]. 2013. [cit. 2015-12-26] Doštupneá ž: http://štatic.googleušercontent.com/media/rešearch.google.com/en//pubš/archive/41344.pdf

[4] ASLETT, M. How will the database incumbents respond to NoSQL and NewSQL? The 451 Group, April 2011.

[5] ASLETT, M. What we talk about when we talk about NewSQL [online]. The 451 Group, April 2011. [cit. 2015-12-26] Doštupneá ž: httpš://blogš.the451group.com/information_management/2011/04/06/what - we - talk - about - when - we - talk - about - newšql/

[6] CATTELL, R. Scalable SQL and NoSQL Data Stores [online]. 2011. [cit. 2015-12-26] Doštupneá ž: http://www.cattell.net/dataštoreš/Dataštoreš.pdf

[7] CodeFutureš Co. Cost-effective Database Scalability using Database Sharding [online]. 2008. [cit. 2015-06-09] Doštupneá ž: http://codefutureš.com/librarý/Databaše - Sharding - White - Paper - V1.pdf

[8] GARCIA-MOLINA, H., ÚLLMAN, J. D. a WIDOM, J. Database Systems: The Complete Book. New Jeršeý: Pearšon Education, 2009. ISBN: 978-0-13-606701-8

[9] OÖ ŽSÚ, M. T. a VALDÚRIEŽ, P. Principles of Distributed Database Systems. New York: Springer, 2011. ISBN: 978-1-4419-8833-1

[10] POKORNYÚ, J. a HALASŽKA I. Databázové systémy. Praha: Výdavatelštvíá CVÚT, 2004. ISBN: 9788001027899

[11] ANSI. Database Language SQL [online]. 1992-07.[cit. 2016-07-23] Doštupneá ž: http://www.contrib.andrew.cmu.edu/~šhadow/šql/šql1992.txt

[12] BERENSON, H. et al. A critique of ANSI SQL isolation levels [online]. In Proceedingš of ACM SIGMOD International Conference on Management of Data. ACM Prešš, 1995-06. [cit. 2016-12-22] Doštupneá ž: httpš://štatic.aminer.org/pdf/PDF/000/598/040/a_critique_of_anši_šql_išolation_levelš.pdf

[13] HOWARD, M, LEBLANC, D. a VIEGA, J. 24 Deadly Sins of Software Security. New York: The McGraw-Hill Companieš, 2010. ISBN: 978-0-07-162676-7

[14] COLOÚRIS, G. et al. Distributed Systems: Concepts and Design, 5th Edition. Addišon-Wešleý, 2011. ISBN: 978-0-13-214301-1

- 47 -

https://static.aminer.org/pdf/PDF/000/598/040/a_critique_of_ansi_sql_isolation_levels.pdf

https://static.aminer.org/pdf/PDF/000/598/040/a_critique_of_ansi_sql_isolation_levels.pdf

http://www.contrib.andrew.cmu.edu/~shadow/sql/sql1992.txt

http://codefutures.com/library/Database-Sharding-White-Paper-V1.pdf

http://www.cattell.net/datastores/Datastores.pdf

https://blogs.the451group.com/information_management/2011/04/06/what-we-talk-about-when-we-talk-about-newsql/

https://blogs.the451group.com/information_management/2011/04/06/what-we-talk-about-when-we-talk-about-newsql/

http://static.googleusercontent.com/media/research.google.com/en//pubs/archive/41344.pdf

http://static.googleusercontent.com/media/research.google.com/en//pubs/archive/41344.pdf

http://darcyd.com/fragmented_future.pdf

http://www.seas.upenn.edu/~zives/03f/cis550/codd.pdf

[15] BREWER, E. A. a FOX, A. Harvest, Yield, and Scalable Tolerant Systems [online]. 1999. [cit. 2015-12-26] Doštupneá ž: http://citešeerx.išt.pšu.edu/viewdoc/download?doi=10.1.1.24.3690&rep=rep1&týpe=pdf

[16] GILBERT, S. a LYNCH, N. Brewer’s Conjecture and the Feasibility of Consistent, Available, Partition-Tolerant Web Services. [online]. 2002. [cit. 2016-01-02] Doštupneá ž: httpš://www.comp.nuš.edu.šg/~gilbert/pubš/BreweršConjecture - SigAct.p df

[17] BREWER, E. A. CAP Twelve Years Later: How the "Rules" Have Changed. [online] 2012. [cit. 2015-12-26] Doštupneá ž: http://www.infoq.com/articleš/cap - twelve - ýearš - later - how - the - ruleš - hav e - changed

[18] CIOCHONŽ , P. a SŽ IBIL, J. ISA Další aspekty architektury IS [online]. Únicorn College š.r.o., 2011-09-27 [cit. 2016-12-10]. Doštupneá ž: httpš://pluš4u.net/ueš/šešm;jšeššionid=05DB2C036D19890646E1ECD125604476.0tcde07?REQID=dbQWJD_iÚ_g=&WINID=97h&action=ueš_v5.core_v1.cont_v1.šheet_v1.controller.C109035BDORoot$šhowSheet:acSelf@2-110&SeššFree=ueš%253AÚCL - BT%255B118500965363973101%255D%253AIS

[19] CORBET, J. C. et al. Spanner: Google’s Globally-Distributed Database [online]. In OSDI, 2012. Doštupneá ž: http://štatic.googleušercontent.com/media/rešearch.google.com/en//archive/španner - ošdi2012.pdf

[20] NuoDB, Inc. A NuoDB Technical Whitepaper [online]. 2013-10-15. [cit. 2015-06-09] Doštupneá ž: http://go.nuodb.com/rš/nuodb/imageš/NuoDB%2520White%2520Paper_7_7_12.pdf

[21] HÚGG, J. H-Store/VoltDB architecture vš. CEP šýštemš and newer štreaming architectureš. In: Youtube [online]. 2014-11-12. Data@Scale [cit. 2015-06-09] Doštupneá ž: httpš://www.ýoutube.com/watch?v=hD5M4a1ÚVž8. Kanaá l @šcale.

[22] HARIŽOPOÚLOS, S. et al. OLTP Through the Looking Glass, and What We Found There [online]. 2008. [cit. 2015-12-26] Doštupneá ž: http://nmš.cšail.mit.edu/~štavroš/pubš/OLTP_šigmod08.pdf

[23] GÚPTA, M. K., VERMA, V. a VERMA, M.S. In-Memory Database Systems – A Paradigm Shift [online]. 2013-12. [cit. 2016-07-24] Doštupneá ž: httpš://arxiv.org/pdf/1402.1258.pdf

[24] ScaleArc, Inc. A ScaleBase Technical Whitepaper [online]. 2014-05. [cit. 2015-12-26] Doštupneá ž: http:// 120.24.68.174:8000/bookš/ScaleBaše- Technical-WhitePaper-05-13-14.pdf

- 48 -

http://120.24.68.174:8000/books/ScaleBase-Technical-WhitePaper-05-13-14.pdf



https://arxiv.org/pdf/1402.1258.pdf

http://nms.csail.mit.edu/~stavros/pubs/OLTP_sigmod08.pdf

https://www.youtube.com/watch?v=hD5M4a1UVz8

http://go.nuodb.com/rs/nuodb/images/NuoDB%2520White%2520Paper_7_7_12.pdf

http://go.nuodb.com/rs/nuodb/images/NuoDB%2520White%2520Paper_7_7_12.pdf

http://static.googleusercontent.com/media/research.google.com/en//archive/spanner-osdi2012.pdf

http://static.googleusercontent.com/media/research.google.com/en//archive/spanner-osdi2012.pdf

https://plus4u.net/ues/sesm;jsessionid=05DB2C036D19890646E1ECD125604476.0tcde07?REQID=dbQWJD_iU_g=&WINID=97h&action=ues_v5.core_v1.cont_v1.sheet_v1.controller.C109035BDORoot$showSheet:acSelf@2-110&SessFree=ues%253AUCL-BT%255B118500965363973101%255D%253AISA.CZ%252FLEC03%252FGL%255B44191574008339418%255D%253A&ref=ues%3AUCL-BT%5B118500965363973101%5D%3AISA10A15W.CZ%2FPARTTIME%5B44191584363497218%5D%3APORTAL%5B50946983804554340%5D



http://www.infoq.com/articles/cap-twelve-years-later-how-the-rules-have-changed

http://www.infoq.com/articles/cap-twelve-years-later-how-the-rules-have-changed

https://www.comp.nus.edu.sg/~gilbert/pubs/BrewersConjecture-SigAct.pdf

https://www.comp.nus.edu.sg/~gilbert/pubs/BrewersConjecture-SigAct.pdf

http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.24.3690&rep=rep1&type=pdf

http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.24.3690&rep=rep1&type=pdf

[25] BERNSTEIN, P. A. a GOODMAN, N. Concurrency Control in Distributed Database Systems [online]. Computing Surveýš, Vol. 13, No. 2, June 1981. [cit. 2016-07-01] Doštupneá ž: httpš://www.cš.cmu.edu/~pavlo/couršeš/fall2013/štatic/paperš/bernštein - 1981.pdf

[26] Cluštrix, Inc. How ClustrixDB RDBMS Scales Writes and Reads [online]. 2015. [cit. 2016-06-20] Doštupneá ž: http://www.cluštrix.com/rešourceš/white - - paperš/

[27] LAMPORT, L. The Part-Time Parliament [online]. ACM Tranšactionš on Computer Sýštemš, 1998. [cit. 2016-06-30] Doštupneá ž: http://rešearch.microšoft.com/en - uš/um/people/lamport/pubš/lamport - paxoš.pdf

[28] LAMPORT, L. Paxos Made Simple [online]. 2001-11-01. [cit. 2016-06-30] Doštupneá ž: http://rešearch.microšoft.com/en - - uš/um/people/lamport/pubš/paxoš - šimple.pdf

[29] OÚSTERHOÚT, J. a ONGARO, D. Implementing replicated logš with Paxoš. In: Youtube [online]. Stanford Úniveršitý 2013-08-14. Doštupneá ž: http://ýoutu.be/JEpšBg0AO6o. Kanaá l užš ivatele Diega Ongarý.

[30] CHANDRA, T., GRIESEMER, R. a REDSTONE, J. Paxos Made Live - An Engineering Perspective [online]. 2007-06-20. [cit. 2016-06-25] Doštupneá ž: httpš://www.cš.utexaš.edu/ušerš/lorenžo/corši/cš380d/paperš/paper2-1.pdf

[31] DEAN, J. a GHEMAWAT, S. MapReduce: Simplified Data Processing on Large Clusters [online]. OSDI 2004. Doštupneá ž: http://štatic.googleušercontent.com/media/rešearch.google.com/eš/uš/archive/mapreduce - ošdi04.pdf

[32] GRAEFE, G. The Cascades Framework for Query Optimization [online]. IEEE Data Engineering Bulletin, vol. 18, no. 3, Januarý 1995. [cit 2016-11-28] Doštupneá ž: httpš://pdfš.šemanticšcholar.org/360e/cdfc79850873162ee4185bed8f334da30031.pdf

[33] PAVLO, A. a ASLETT, M. What‘s Really New with NewSQL? [online]. SIGMOD Record, vol. 45, no. 2, June 2016. [cit. 2017-03-23] Doštupneá ž: http://db.cš.cmu.edu/paperš/2016/pavlo-newšql-šigmodrec2016.pdf

[34] VoltDB, Inc. VoltDB Technical Overview [online]. 2012-04-11. [cit. 2016-06-23] Doštupneá ž: http://www.odbmš.org/wp - content/uploadš/2013/11/VoltDBTechnicalOverview.pdf

[35] MemSQL. MemSQL – Architecture [online]. 2016. [cit. 2016-06-23] Doštupneá ž: http://www.memšql.com/content/architecture/

[36] ScaleDB. ScaleDB Technical overview [online]. 2014-12-02. [cit. 2016-06-25]. Doštupneá ž:http://www.šcaledb.com/wp - - content/uploadš/2015/12/ScaleDB_Product_Architecture_1a.pdf

- 49 -

http://www.scaledb.com/wp-content/uploads/2015/12/ScaleDB_Product_Architecture_1a.pdf

http://www.scaledb.com/wp-content/uploads/2015/12/ScaleDB_Product_Architecture_1a.pdf

http://www.memsql.com/content/architecture/

http://www.odbms.org/wp-content/uploads/2013/11/VoltDBTechnicalOverview.pdf




http://db.cs.cmu.edu/papers/2016/pavlo-newsql-sigmodrec2016.pdf

https://pdfs.semanticscholar.org/360e/cdfc79850873162ee4185bed8f334da30031.pdf

https://pdfs.semanticscholar.org/360e/cdfc79850873162ee4185bed8f334da30031.pdf

http://static.googleusercontent.com/media/research.google.com/es/us/archive/mapreduce-osdi04.pdf

http://static.googleusercontent.com/media/research.google.com/es/us/archive/mapreduce-osdi04.pdf

https://www.cs.utexas.edu/users/lorenzo/corsi/cs380d/papers/paper2-1.pdf

https://www.cs.utexas.edu/users/lorenzo/corsi/cs380d/papers/paper2-1.pdf

http://youtu.be/JEpsBg0AO6o

http://research.microsoft.com/en-us/um/people/lamport/pubs/paxos-simple.pdf

http://research.microsoft.com/en-us/um/people/lamport/pubs/paxos-simple.pdf

http://research.microsoft.com/en-us/um/people/lamport/pubs/lamport-paxos.pdf

http://research.microsoft.com/en-us/um/people/lamport/pubs/lamport-paxos.pdf

http://www.clustrix.com/resources/white-papers/

http://www.clustrix.com/resources/white-papers/

https://www.cs.cmu.edu/~pavlo/courses/fall2013/static/papers/bernstein-1981.pdf

https://www.cs.cmu.edu/~pavlo/courses/fall2013/static/papers/bernstein-1981.pdf

[37] Cockroach Labš. CockroachDB – dešign document [online]. 2016-06-01. [cit. 2016-06-25] Doštupneá ž: httpš://github.com/cockroachdb/cockroach/blob/mašter/docš/dešign.md

[38] Apache Trafodion. Apache Trafodion architectural overview [online]. 2015. [cit. 2016-06-25] Doštupneá ž: http://trafodion.apache.org/architecture - - overview.html

[39] SAP A. G. SAP HANA® Platform – Technical Overview [online]. 2012-05 [cit. 2016-06-25] Doštupneá ž: http://www.ntua.gr/announcementš/general/uploadš/2013-07-01_171178_SAP_HANA_Platform_Technical_Overview.pdf

[40] TIBCO Software, Inc. TIBCO ActiveSpaces® Developer’s Guide [online]. 2014-08. [cit. 2016-07-18] Doštupneá ž: httpš://docš.tibco.com/pub/activešpaceš/2.1.4/doc/pdf/tib_activešpaceš_developer.pdf

[41] Cluštrix, Inc. Cloud Database [online]. 2015. [cit. 2017-04-01] Doštupneá ž: http://www.cluštrix.com/cloud/

[42] MemSQL. MemSQL Unveils Managed Cloud Service at AWS re:Invent [online]. November 2016. [cit. 2017-04-01] Doštupneá ž: http://www.memšql.com/releašeš/cloud/

[43] GOEL, A. K. et al. Towards scalable real-time analytics: An architecture for scale-out of olxp workloads [online]. Proc. VLDB Endow., 8(12):1716–1727, Aug. 2015. [cit. 2017-04-17] Doštupneá ž: http://www.vldb.org/pvldb/vol8/p1716-goel.pdf

[44] YÚHANNA, N., et. al. The Forrester Wave™: In-Memory Databases, Q1 2017 [online]. Forrešter Rešearch, Inc., March 2017. [cit. 2017-03-18] Doštupneá ž: httpš://reprintš.forrešter.com/#/aššetš/2/448/%27RES132143%27/reportš

[45] Microšoft, Inc. SQL Server 2016 Service Pack 1 generally available [online]. SQL Server Blog, November 2016. [cit. 2017-04-02] Doštupneá ž: httpš://blogš.technet.microšoft.com/dataplatforminšider/2016/11/16/šql-šerver-2016-šervice-pack-1-generallý-available/

[46] Microšoft, Inc. Hekaton Breaks Through [online]. Microšoft Rešearch Blog, December 2012. [cit. 2017-04-02] Doštupneá ž: httpš://www.microšoft.com/en-uš/rešearch/blog/hekaton-breakš-through/?from=http%3A%2F%2Frešearch.microšoft.com%2Fen-uš%2Fnewš%2Ffeatureš%2Fhekaton-122012.ašpx

[47] CHRISTENSEN, C. The Innovator‘s Dilemma. Bošton, MA, ÚSA: Harward Buinešš School Prešš, 1997. ISBN: 0-87584-585-1

- 50 -

https://www.microsoft.com/en-us/research/blog/hekaton-breaks-through/?from=http%3A%2F%2Fresearch.microsoft.com%2Fen-us%2Fnews%2Ffeatures%2Fhekaton-122012.aspx



https://blogs.technet.microsoft.com/dataplatforminsider/2016/11/16/sql-server-2016-service-pack-1-generally-available/

https://blogs.technet.microsoft.com/dataplatforminsider/2016/11/16/sql-server-2016-service-pack-1-generally-available/

https://reprints.forrester.com/#/assets/2/448/'RES132143'/reports

https://reprints.forrester.com/#/assets/2/448/'RES132143'/reports

http://www.vldb.org/pvldb/vol8/p1716-goel.pdf

http://www.memsql.com/releases/cloud/

http://www.clustrix.com/cloud/

https://docs.tibco.com/pub/activespaces/2.1.4/doc/pdf/tib_activespaces_developer.pdf

https://docs.tibco.com/pub/activespaces/2.1.4/doc/pdf/tib_activespaces_developer.pdf

http://www.ntua.gr/announcements/general/uploads/2013-07-01_171178_SAP_HANA_Platform_Technical_Overview.pdf

http://www.ntua.gr/announcements/general/uploads/2013-07-01_171178_SAP_HANA_Platform_Technical_Overview.pdf

http://trafodion.apache.org/architecture-overview.html

http://trafodion.apache.org/architecture-overview.html

https://github.com/cockroachdb/cockroach/blob/master/docs/design.md

Seznam obrázků

Obraá žek 1: CAP teoreám................................................................................................................. 18Obraá žek 2: Porovnaáníá logickeá a fýžickeá štrukturý uklaádaáníá dat v tradicšníám normaližovaneám šcheámatu a hierarchickeám šcheámatu použš íávaneám v F1...............32Obraá žek 3: Scheámatickeá žnaá žornešníá ScaleBaše clušteru.................................................38Obraá žek 4: Schematickeá žnaá žornešníá týpickeáho ScaleDB clušteru................................39

- 51 -

Seznam tabulek

Tabulka 1: Vžtah meži uá rovnešmi ižolace a jevý, ktereá mohou naštat..........................15Tabulka 2: Jednoduchýá Paxoš...................................................................................................... 25Tabulka 3: Sežnam NewSQL databaá žíá......................................................................................30

- 52 -

Seznam použitých zkratek

Zkratka Význam

2PC Two Phaše Commit

2PL Two Phaše Locking

ACID Atomicitý, Conšištencý, Išolation ,Durabilitý

AWS Amažon WebServiceš

BASE Bašicallý Available, Soft štate, Eventuallý conšištent

BI Bušinešš Intelligence

CAP Conšištencý, Availabilitý, Partition tolerance

CEP Complex Event Proceššing

DBaaS DataBaše aš a Service

DBMS DataBaše Management Sýštem

DDBS Dištributed DataBaše management Sýštem

GPS Global Pošitioning Sýštem

HTAP Hýbrid Tranšaction-Analýtical Proceššing

HTTP Hýpertext Tranšfer Protokol

IMDS In-Memorý Databaše Sýštem

JDBC Java DataBaše Connectivitý

JSON JavaScript Object Notation

MVCC MultiVeršion Concurrencý Control

ODBC Open DataBaše Connectivitý

OLAP OnLine Analýtical Proceššing

OLTP OnLine Tranšaction Proceššing

PODC Principleš Of Dištributed Computing

RDBMS Relational DataBaše Management Sýštem

RPC Remote Procedure Call

SM Storage Manager

SRP Secure Remote Paššword

SPoF Single Point of Failure

SQL Structured Querý Language

TE Tranšaction Engine

XaaS Anýthing aš a Service

WAN Wide Area Network

WWW World Wide Web

- 53 -

Documents

BAKALÁŘSKÁ PRÁCE NewSQL architektura databázových systémů · 1 Úvod do problematiky, motivace k hledání nových způsobů zpracování dat v databázových systémech Puůvodníá