}w!"#$%&'()+,-./012345<ya

}w!"#$%&'()+,-./012345<ya Masarykova univerzita Fakulta informatiky Robustní a škálovatelný datový sklad pro systém Perun Diplomová práce Bc. Michal Šťava Brno, podzim 2014

Prohlášení Prohlašuji, že tato diplomová práce je mým původním autorským dílem, které jsem vypracoval samostatně. Všechny zdroje, prameny a literaturu, které jsem při vypracování používal nebo z nich čerpal, v práci řádně cituji s uvedením úplného odkazu na příslušný zdroj. Bc. Michal Šťava Vedoucí práce: RNDr. Michal Procházka ii

Poděkování Rád bych poděkoval všem, kteří se mnou měli tu trpělivost a podporovali mě v dokončení této práce. Své rodině, kamarádům, kolegům a zvláště pak svému vedoucímu a své ženě. Díky Vám všem. iii

Shrnutí Práce se zabývá hledáním výkonného, dobře škálovatelného a robustního datového úložiště pro systém Perun. Popisuje systém Perun, data tohoto systému a nejčastější způsob práce s těmito daty. Detailně se věnuje jednotlivým technologickým možnostem, ze kterých vybírá představitele a porovnává je mezi sebou na základě vytyčených vlastností. Pro nejlépe hodnocené představitele popisuje postup nasazení a na základě porovnávacích měření definuje výkonnostní rozdíly v práci s daty oproti dosavadnímu datovému úložišti systému Perun. Na závěr shrnuje získané informace a nabízí alternativní řešení. iv

Klíčová slova SQL, NoSQL, databáze, replikace, aplikační cache, Perun, PostgreSQL, Pgpool- II, Postgres-XL v

Obsah 1 Úvod.................................. 3 2 Systém Perun............................. 5 2.1 Ukládání dat v systému Perun................. 6 2.2 Schéma systému Perun...................... 7 2.3 Uživatelská data v systému Perun............... 8 2.4 Atributy v systému Perun.................... 9 2.5 Generování dat pro služby.................... 10 2.6 Shrnutí.............................. 11 3 Očekávané vlastnosti řešení pro práci s daty......... 12 3.1 Výkonnost............................. 12 3.2 Škálovatelnost........................... 12 3.3 Robustnost............................ 12 3.4 Open source řešení........................ 13 3.5 Aktuální vlastnosti systému Perun............... 13 3.6 Minimální požadavky nového řešení.............. 14 3.7 Ostatní důležité vlastnosti nového řešení............ 14 4 Technologické možnosti práce s daty.............. 15 4.1 Optimalizace stávajícího řešení................. 15 4.2 NoSQL databáze......................... 16 4.2.1 Garance v databázích.................. 16 4.2.2 Typy NoSQL....................... 19 4.2.3 Vhodnost použití NoSQL databází........... 21 4.2.4 Obecné výhody a nevýhody NoSQL řešení....... 21 4.3 Cachování a databáze operující v paměti............ 22 4.3.1 Plnění databázové cache................. 23 4.3.2 Synchronizace cache................... 24 4.3.3 Náročnost na paměť................... 25 4.3.4 Vícemístné cachování.................. 26 4.3.5 inmemory databáze................... 26 4.3.6 Vhodnost použití cache a inmemory databází..... 27 4.4 Replikace relačních SQL databází................ 27 4.4.1 Vlastnosti systémů pro replikaci SQL databází.... 27 4.4.2 Vhodnost použití replikací nad databázemi...... 31 4.5 Ucelená aplikační řešení (framework).............. 31 5 Konkrétní technologická řešení.................. 33 5.1 NoSQL Databáze......................... 33 5.1.1 Sloupcové DB....................... 33 1

5.1.2 Dokumentově orientované databáze........... 35 5.1.3 Databáze typu klíč-hodnota............... 37 5.1.4 Grafové databáze..................... 39 5.1.5 Hybridní databáze.................... 40 5.2 Cachování a in-memory databáze................ 42 5.3 Replikace relačních databází................... 45 5.4 Srovnání technologií....................... 49 5.5 Výběr technologie......................... 50 6 Hodnocení vybraných technologií................ 51 6.1 Postgres-XL............................ 51 6.1.1 Návrh........................... 51 6.1.2 Instalace a prerekvizity................. 53 6.1.3 Inicializace........................ 54 6.1.4 Nastavení konfiguračních souborů............ 55 6.1.5 Spuštění.......................... 57 6.1.6 Potíže s alokací sdílené paměti............. 57 6.1.7 Lokální nastavení konfiguračních tabulek....... 57 6.1.8 Přidávání a odstraňování koordinátorů a datových uzlů 58 6.1.9 Import dat a definice tabulek.............. 58 6.1.10 Zjištěné problémy.................... 59 6.1.11 Shrnutí.......................... 60 6.2 Pgpool-II a PostgreSQL streamovací replikace......... 60 6.2.1 Návrh........................... 60 6.2.2 Instalace a prerekvizity................. 62 6.2.3 Inicializace........................ 63 6.2.4 Nastavení konfiguračních souborů............ 63 6.2.5 Podpůrné skripty..................... 69 6.2.6 Spuštění.......................... 70 6.2.7 Importování dat a komunikace s Pgpool-II serverem. 72 6.2.8 Měření výkonnosti a hodnocení............. 73 6.2.9 Shrnutí.......................... 81 6.3 Rozšíření master-slave streamovací replikace.......... 82 6.3.1 Návrh........................... 83 6.3.2 Instalace a prerekvizity................. 83 6.3.3 Nastavení konfigurace a spuštění............ 84 6.3.4 Shrnutí.......................... 85 7 Závěr.................................. 86 A Příloha A tabulka s vlastnostmi technologií........ 92 B Příloha B grafy.......................... 96 C Příloha C soubory na přiloženém disku........... 101 2

1 Úvod V dnešní době je stále důležitější, aby aplikace uměla škálovat svůj výkon vzhledem k vzrůstajícímu počtu produkčních dat. Škálovatelnost se velmi úzce pojí se způsobem, jakým jsou data pro aplikaci ukládána. Ačkoliv je s ukládáním dat nejčastějí spojován pojem relačních SQL 1 databází, stále více se mluví o tzv. NoSQL 2 databázích, které si zakládají na výkonu, a především na vysoké míře škálovatelnosti. Ke zvýšení výkonu a škálovatelnosti aplikace lze dospět i jinak než jen volbou databázového systému. Správné umístění aplikační nebo databázové cache, či rozložení výkonu mezi více uzlů jedné databáze (tzv. replikace) může také pomoci. Pro každou konkrétní aplikaci je potřeba najít nejideálnější variantu [38]. Obdobně jako škálovatelnost je pro aplikace důležitá odolnost proti výpadkům a schopnost se z výpadku zotavit. Toto se ve světě informatiky označuje jako robustnost. Ještě častěji se v tomto směru hovoří o tzv. vysoké dostupnosti aplikací, která zajišťuje, že za daný časový úsek (často jeden rok) bude aplikace nedostupná jen po dohodnutý čas. Často je ještě vytyčena maximální délka intervalů jednotlivých nedostupností. Zajištění takových podmínek je velmi finančně náročné a často se mluví o pojmu několika devítek. Například v kontextu vysoké dostupnosti pojem tří devítek [26] značí pravděpodobnost 99,9%, že aplikace bude dostupná. To vychází ročně na cca devět hodin, kdy aplikace může být nedostupná. K docílení takovéto vysoké dostupnosti aplikace lze využít redundanci dat, decentralizované či hardwarové řešení. Cílem mé diplomové práce je najít vhodné řešení pro práci s daty v systému Perun 3, který bude splňovat zmíněné vlastnosti robustnost, škálovatelnost a výkonnost. Je potřeba zmapovat technologické možnosti pro práci s daty a následně je mezi sebou porovnat. Dále pak nejúspěšnější technologii nasadit, otestovat a porovnat její vlastnosti s momentálním řešením. Na začátku práce se věnuji obecnému popisu systému Perun. Definuji způsob uložení dat a nejčastěji prováděné operace s těmito daty. Zároveň hledám nejproblematičtější místa pro práci s daty vzhledem k potřebnému výkonu. V další kapitole se soustředím na definování očekávaných vlastností. Stanovuji zde několik dalších potenciálně důležitých vlastností a popisuji minimální požadavky. 1. SQL Structured Query Language 2. NoSQL Not only Structured Query Language 3. Perun http://perun.cesnet.cz/ 3

1. Úvod V kapitole čtyři vybírám několik technologických možností, jak lze daných vlastností dosáhnout a zabývám se hlavně teoretickou částí těchto technologií. V následující kapitole pak volím konkrétní představitele technologií z kapitoly čtyři a popisuji je společně s několika důležitými pozitivními, ale i negativními vlastnostmi. V předposlední kapitole se věnuji nasazení některých vybraných řešení spolu s popisem jednotlivých potíží, které mě během nasazení potkaly. Dále pak provádím měření a hodnocení výkonnosti a škálovatelnosti vzhledem k původnímu řešení. V poslední kapitole je uveden závěr celé práce s důrazem na nasazené technologie s jejich klady a zápory. Součástí práce jsou i tři přílohy, kde v příloze A je tabulka veškerých zkoumaných technologií z kapitoly 5 spolu s definicí jednotlivých porovnávaných vlastností. Cílem této tabulky je přehledně porovnat ne vždy stejně zaměřené technologie. V přiloze B jsou k dispozici dodatečné grafy z měření výkonnosti nasazeného řešení z kapitoly 6 a v příloze C je popis obsahu přiloženého disku. 4

2 Systém Perun Systém Perun slouží ke správě uživatelů, skupin a přístupů ke službám. Jeho vývoj zaštiťuje CESNET 1 a Masarykova univerzita. Momentálně se využívá hlavně pro účely akademické e-infrastruktury a řídí přístupy např. ke službám národní gridové infrastruktury. Mimo Českou republiku se využívá např. pro řízení přístupu na různé typy služeb v evropské gridové infrastruktuře a národní gridové infrastruktuře v Jižní Africe [35]. K lepšímu pochopení fungování systému Perun je nejprve nutné popsat, kdo jsou jeho uživatelé. V dnešní době mají uživatelé webového prostředí své tzv. digitální identity, kterými se v tomto prostředí prokazují. Digitální identitou se myslí soubor informací o uživateli (jméno, tituly apod.), který je podložen nějakým ověřením, například digitálním certifikátem nebo jménem a heslem [8]. Každý uživatel může mít hned několik svých digitálních identit. Na základě těchto digitálních identit je možné uživatele do systému Perun registrovat nebo synchronizovat z různých systémů pro správu uživatelů, které spravuje externí organizace. Jednotlivé digitální identity je pak možné v systému spojit a mít tak pro každého uživatele jen jeden účet. Systém Perun tedy slouží jako jeden společný bod pro řízení přístupu uživatelů ke službám jednotlivých organizací. Pro rozčlenění uživatelů v systému je navržen koncept tzv. VO (virtuálních organizací) a skupin. Uživatel v podstatě žádá o vytvoření členství v některé z virtuálních organizací, v níž chce získat přístupy ke konkrétním službám. V rámci virtuální organizace je přiřazen do skupin, které přímo definují samotné přístupy ke službám. Uživatel může být zároveň členem hned několika virtuálních organizací současně [34]. Aby bylo možné tyto přístupy definovat, musí být v systému uloženo potřebné množství informací (metadat) o těchto uživatelích, skupinách a službách. Taková metadata se v systému Perun nazývají Atributy (pojem Atribut je dále používán v textu). Atributem může být email, adresa nebo jakákoliv jiná informace nutná pro potřeby nastavení autorizace uživatele ke službě. Autorizace je proces ověření uživatele, zda má právo provést požadovanou činnost (práce s daty, provedení příkazu apod.). Nejčastěji se ověřuje kontrolou vůči nějakému věrohodnému zdroji informací, například souboru se seznamem autorizovaných identit nebo dotazu do externího systému, jako je např. LDAP 2. Nastavením autorizace z pohledu systému Perun se zde tedy myslí připravení těchto zdrojů autorizačních dat. K přípravě autorizačních 1. Czech Education and Scientific NETwork http://www.cesnet.cz/ 2. Lightweight Directory Access Protocol http://www.openldap.org/ 5

2. Systém Perun dat je nejprve potřeba shromáždit potřebné informace, které jsou uloženy v různých atributech. Uživatel tedy musí mít v systému Perun všechna potřebná data k provedení nastavení autorizace pro využívané služby (např. login, email či jiné). Samotný proces nastavení přístupových práv ke službám se řeší pomocí Push mechanismu, kdy se data v systému Perun vygenerují a následně se propagují (odešlou a zpracují) k vybrané službě. Tomuto stavu se pak říká poslední aktuální konfigurace a i v případě nedostupnosti systému Perun je taková konfigurace zachovaná a službou dále používaná. Velkou výhodou této metody je, že služby dále fungují a poskytují přístup uživatelům nezávisle na tom, zda je systém Perun dostupný či ne [36]. Jelikož se propagace dat neustále opakuje (pravidelně podle potřeby aktuálnosti dat nebo v případě vynucení změnou) a je potřeba propagovat velké množství uživatelů s desítkami atributů, je tento proces velmi náročný na čtení dat a v případě tisíců uživatelů naráží na limity jedné instance databáze systému Perun. 2.1 Ukládání dat v systému Perun V současné době se pro ukládání dat používá databáze PostgreSQL 3. Dále se stále udržuje kompatibilita s databází Oracle 4. Důvod udržování kompatibility je, že některé akademické instituce, které si chtějí vytvořit vlastní instanci systému Perun pro svoje účely, preferují databázové řešení od firmy Oracle. Systém Perun se jim snaží vyjít maximálně vstříc. Tato kompatibilita však bude při výběru technologií hrát jen velmi minoritní roli. Problémem při ukládání dat do jedné databáze je samozřejmě strop výkonu takového řešení na jednom samostatném stroji. Množství dotazů, které je na systém Perun kladeno, přesahuje možnosti aktuálního stroje a nabízí se několik možností jak toto řešit (posílit stroj, distribuovat zátěž mezi více strojů, zvolit jinou techniku práce s daty atd.). Dalším problémem při ukládání dat do jedné databáze je, že při havárii stroje nebo databáze je přístup k systému Perun až do opětovného nastartování úplně odstřihnut. To je problém zvláště z pohledu uživatelů, neboť uživatelé nemohou nadále k systému Perun přistupovat, a to ani za účelem získání informací (čtení). Díky zmíněnému Push mechanizmu však nedojde k odpojení uživatelů od služby, ke které jim systém Perun zajišťuje nastavení přístupu. Data se pouze po dobu výpadku neaktualizují o nové změny a 3. Postgre SQL http://www.postgresql.org/ 4. Oracle http://www.oracle.com/technetwork/database/enterpriseedition/overview/index.html 6

uživatelé ani nemohou nové změny do systému zadávat. 2.2 Schéma systému Perun 2. Systém Perun Systém Perun se skládá z mnoha komponent, které mezi sebou vzájemně komunikují a spolupracují viz. obrázek 2.1. Obrázek 2.1: Znázornění komunikace jednotlivých modulů systému Perun s databází. Jádro systému Perun (peruncore) má veškerý přístup k datovému skladišti. Jednotlivé moduly pak využívají ke komunikaci s peruncore rozhraní nazvané perun-rpc. Některé z modulů jsou určeny pro komunikaci uživatelů a jiných systémů se systémem Perun, některé pak plní určitou požadovanou funkcionalitu. Mezi moduly zprostředkovávajícími komunikaci patří perun-cli (příkazová řádka pro práci se systémem Perun) a perun-gui (grafické rozhraní pro uživatele). Kromě těchto dvou existuje ještě několik dalších rozhraní založených na technologii PHP 5 a Javascript 6, které na obrázku sice nejsou, ale jejich komunikace funguje na stejném principu jako v případě zmíněných dvou. 5. PHP skriptovací programovací jazyk 6. Javascript interpretovaný programovací jazyk 7

2. Systém Perun Zajimavé moduly, které obstarávají konkrétní funkcionalitu, jsou perunengine, perun-dispatcher, perun-ldapc, perun-notificator a perun-registrar. Další stále přibývají, proto je obrázek nakreslen tak, že definice tří teček znázorňuje další nespecifikované moduly komunikující stejnou cestou. Perun-engine je důležitá komponenta. Stará se o již dříve zmíněnou propagaci přístupů uživatelů ke službám. Vyžaduje pouze čtení dat za účelem generování nastavení pro jednotlivé služby a nepotřebuje žádná data zapisovat. O výběr dat k propagaci, samotné zpracování a následné uložení výsledků se stará komponenta perun-dispatcher. Ta na obrázku komunikuje s perunengine a zjednodušeně řečeno mu předává úkoly a čeká až od něj nazpět dostane potvrzení o provedení nebo o chybě. Tyto dvě komponenty mohou bez potíží běžet odděleně na různých strojích a jediná podmínka je, že spolu potřebují komunikovat. Komponenta perun-ldapc řídí synchronizaci dat mezi systémem Perun a serverem LDAP. LDAP server se následně využívá pro autorizované čtení dat ze systému Perun bez zatížení databáze. Zároveň také zajišťuje rychlejší a jednodušší dotazování. Komponenta perun-ldapc stejně jako perun-engine data ze systému čte, ale žádná data do něj nezapisuje. Předposlední zmíněná komponenta perun-notificator se stará o zasílání zpráv uživatelům podle nastavení v systému. Například, když vyprší platnost přístupu nějakého uživatele ke službě apod. Tato komponenta převážně čte, ale svá nastavení musí do systému i ukládat, takže v takovém případě vyžaduje i zápis. Perun-registrar je komponentou určenou ke správě přihlášek. Každý uživatel, který chce systém Perun využívat, se musí registrovat pomocí přihlášky. Registrace většinou probíhá k nějaké konkrétní skupině nebo virtuální organizaci. Ta si může vytvořit svou vlastní přihlášku s očekávanými parametry, které uživatel musí uvést. Vyplní-li uživatel přihlášku, může se buď automaticky nebo potvrzením některého ze správců stát členem této skupiny a uživatelem systému Perun. Za účelem správy těchto přihlášek musí perunregistrar provádět čtecí i zapisovací operace v databázi [34]. 2.3 Uživatelská data v systému Perun Mezi uživatelská data patří základní informace jako např. jméno, příjmení, email, či adresa. Základní informace jsou však jen střípek toho, co se o uživatelích v systému Perun ukládá. Například jednou z možností, jak systém Perun použít, je nastavit uživatelům uživatelské účty pro přístup na nějaký unixový stroj. V takovém případě je jedním z parametrů shell (uživatelské rozhraní 8

2. Systém Perun pro přístup k danému stroji např. bash 7 ), který se bude volit na základě povolených shellů pro danou službu a preferovaných shellů uživatele. Tyto informace jsou pak v systému Perun uloženy v podobě metadat v atributech [22]. Velký důraz je kladen na konzistenci dat v systému. K udržení základní konzistence slouží právě databáze. Aby databáze mohla rozumně udržet konzistenci, používá unikátní a cizí klíče nad tabulkami, podmínky 8, typy (číslo, text apod.) a další techniky [39]. Nové řešení by tedy mělo být schopné nabídnout podobnou úroveň kontrol. Složitější konzistence se dále řeší přímo aplikací, o které bude řeč v sekci o atributech. 2.4 Atributy v systému Perun Atributy v systému Perun definují metadata, která je možné uložit o konkrétní entitě (uživateli, členovi organizace, skupině, službě, organizaci a jiné), nebo vztahy mezi více entitami. Dobrým příkladem je výše zmíněný preferovaný shell. Uživatel si zadá v systému Perun svoje preference a stejně tak vlastník služby definuje povolené shelly pro přístup ke službě. Poté se provede výpočet, který zjistí, jaký shell bude mít uživatel v rámci služby nastavený, a který se mu tedy po přihlášení zobrazí. Takových nastavení je v systému Perun momentálně více než sto a další stále přibývají. Z interních měření vyplývá, že právě atributy jsou momentálně nejsložitějším místem, co se náročnosti na množství dotazů týče, a mají největší vliv na zpomalení operací v systému. Z tohoto důvodu jim a veškerým komponentám, které s nimi pracují, bude věnována větší pozornost. Čtení a výpočet atributů Čtení atributů je operace provádějící volání do databáze, kdy se na základě informace o entitě a informace o konkrétních metadatech zavolá dotaz, který vrátí potřebnou hodnotu. Složitější je pak ještě varianta vypočítávaných atributů, které svoji hodnotu mění dynamicky na základě dalších dat ze systému Perun a nemají svou hodnotu nikde staticky uloženou. Takový výpočet pak může znamenat v horším případě i stovky volání do databáze. Zde je samozřejmě prostor k optimalizacím, ale tato diplomová práce se především zabývá řešením na straně datového skladu [22]. 7. bash druh interpretru příkazové řádky, http://www.gnu.org/software/bash/ 8. constraint podmínka pro validaci dat v databázi 9

2. Systém Perun Zápis atributů Operace zápisu atributů je mnohem méně častá než operace čtení. Samotné nastavení se provádí pouze několikrát a většinou se jedná o jeden dotaz do databáze, který danou hodnotu nastaví nebo upraví podle nového nastavení. Daleko zajímavější je pohled na to, co se děje během zápisu hodnoty do atributu. Jak už bylo naznačeno, v systému Perun je důležitá konzistence dat, a ta se řeší jak na straně databáze, tak i na straně aplikace. V momentě uložení nové hodnoty do atributu se musí zjistit, zda tato konzistence nebyla narušena. Příkladem může být již zmíněné nastavování shellů uživatelům pro přístup ke službě, ke které jim byl zřízen účet. Každá taková služba má svá omezení (seznam povolených shellů, které uživatelé mohou používat). Uživatelé mají naopak možnost volby, který shell by preferovali. Na základě těchto dat se nastaví jejich průnik anebo v případě prázdného průniku jeden z povolených shellů služby. Když bude chtít správce služby v budoucnu omezit nastavení povolených shellů, provede se kontrola, která zjistí, zda některý z uživatelů nemá jako aktivní shell nastavený ten právě vyřazený. Takových uživatelů může být stovky i tisíce, proto je nutné je všechny zkontrolovat a na základě kontroly provést patřičné kroky k odstranění této nekonzistence, například nastavit takovým uživatelům jiný shell. Zde je vidět, že i pro nastavení, kdy se bavíme v podstatě o zapisování dat, je potřeba často volat čtecí dotazy ve množství výrazně přesahující ty zapisovací. 2.5 Generování dat pro služby Generováním dat je myšlen proces přípravy dat pro komponentu perun-engine, která tato data následně odešle na cílový stroj, kde se zpracují. Řekněme tedy, že máme nějakou službu, která je spravovaná systémem Perun a tato služba má nějaká nastavení pro přístup uživatelů. Pro rozumné pochopení problému je níže popsán proces průběhu nastavování. Generování začne periodicky nebo dojde-li ke změně nastavení v systému Perun. Do fronty požadavků se zařadí konkrétní úkol s definicí služby, pro kterou mají být informace získány. Jakmile je v systému volný slot a úkol je na řadě, spustí se proces generování (skrze tzv. generovací skripty). Data se generují většinou pro všechny uživatele v rámci dané služby (uživatelé jsou ke službám přiřazováni pomocí skupin a každá skupina 10

2. Systém Perun může mít vlastní nastavení požadovaných atributů), proces generování je velmi náročný na získávání dat z databáze. Jakmile se data vygenerují, uloží se do adresářové struktury a propagují se na danou službu. 2.6 Shrnutí Jelikož největší potíží systému Perun je jen jedna instance databáze, která nezvládá množství převážně čtecích dotazů, je nutné najít řešení umožňující rozložení této zátěže. Zároveň bude potřeba navrhnout řešení pro zotavení z pádu systému, které však nutně nemusí být úplně bez výpadku (neboť Push mechanismus toto cíleně nevyžaduje). Mimo to je potřeba zaměřit se na řešení, které bude podporovat vysokou konzistenci dat, neboť právě ta je jedním z klíčových pilířů systému Perun. Jelikož se o hodně kontrol stará právě databáze, mělo by nové řešení umožnit podobnou úroveň kontrol bez většího zásahu do implementace. 11

3 Očekávané vlastnosti řešení pro práci s daty Nejdříve je potřeba definovat základní požadované vlastnosti nového řešení pro práci s daty. V rámci zadání diplomové práce jsou vyzdviženy především následující čtyři vlastnosti. Výkonnost. Škálovatelnost. Robustnost. Open source řešení. 3.1 Výkonnost Řeší-li se výkonnost v rámci informačních systémů, jedná se převážně o výkonnost výpočetní, ta se běžně měří v rámci počtu operací za jednotku času. V našem případě je spíše řeč o databázovém výkonu a lépe uchopitelnou jednotkou bude např. množství provedených operací s uloženými daty. Ačkoliv ne vždy je možné získat vyšší výkon pro ten samý dotaz, je možné měřit výkon z hlediska celku. Je-li řešení schopné zpracovat za stejný čas větší množství dotazů než jiné, lze ho považovat za výkonnější. Tato vlastnost často splývá se škálovatelnosti, a proto je budu uvádět často společně [37]. 3.2 Škálovatelnost Škálovatelnost nebo též rozšiřitelnost je schopnost hardwarové nebo softwarové součásti přizpůsobit se budoucím rostoucím nárokům na zpracování dat. V tomto směru se budu zabývat škálovatelností v poměru ku množství dat. Systém Perun musí být schopen obsloužit zvyšující se množství uživatelů a jejich dat. Nyní je zde například kolem deseti tisíc uživatelů, a to způsobuje velké výkonnostní problémy. Bude-li nové řešení schopné obsloužit tyto uživatele a bude-li schopné se rozšiřovat tak, aby obsloužilo i dvojnásobek či vícenásobek takových uživatelů, lze ho považovat za dobře škálovatelné [25]. 3.3 Robustnost Robustnost je míra závislosti chování určité komponenty na okolních vlivech. V rámci systému pracujícího s daty budeme za robustnost považovat hlavně odolnost proti výpadkům, schopnost se z výpadku zotavit a dobu tohoto 12

3. Očekávané vlastnosti řešení pro práci s daty zotavování. Ideálním případem je automatické zotavení, v případě systému Perun je však vhodná i možnost omezení funkcí v průběhu výpadku tak, aby systém nebyl zcela odpojený. V textu dále zazní slova jako failover nebo failback. V obou případech se jedná o schopnost zotavit se z pádu. V případě automatického řešení je pak logicky toto zotavení možné bez manuálního zásahu [11]. 3.4 Open source řešení Open source je licence počítačového software s otevřeným zdrojovým kódem. Otevřenost zde znamená jak technickou dostupnost kódu, tak legální dostupnost licencí pro daný software, které umožňují, při dodržení jistých podmínek, uživatelům zdrojový kód využívat, například prohlížet, upravovat a případně se podílet na jeho dalším vývoji. Je to jeden z důvodů, proč do porovnání nebyla přizvána některá komerční technologická řešení a další komerční produkty například od firmy Oracle. Jelikož se celý systém Perun vyvíjí jako open source řešení, jeho jednotlivé podčásti musí být stejného typu licence [48]. 3.5 Aktuální vlastnosti systému Perun Jak již bylo popsáno v kapitole 2, systém Perun využívá k ukládání dat jednu instanci relační databáze PostgreSQL. Z hlediska výkonnosti je toto řešení tak rychlé, jak rychlá je samotná databáze. Samozřejmě také záleží na implementaci jednotlivých dotazů. Rychlost databáze je dále závislá na rychlosti stroje (jeho výpočetním výkonu), schopnosti paralelizace daného databázového řešení, rychlosti zápisu a čtení paměťových zařízení (paměť, pevný disk), síťové infrastruktuře a dalších nejen hardwarových ale i softwarových vlastností. Ačkoliv všechny testy probíhají na stejně nastavených virtuálních strojích se stejným výkonem, později v textu bude vidět, že výkon strojů při měření hraje důležitou roli. Schopnost škálovat je silně spojena s výkonem aktuálního řešení. Čím výkonnější je hardware, tím lépe lze škálovat jednotlivá spojení. Klíčovou roli hraje schopnost databáze PostgreSQL paralelizovat dotazy. Momentální řešení využívá stroj o dvou procesorech s 4GB operační paměti. Robustnost aktuálního řešení je též velmi malá. Výpadek databáze znamená úplnou nedostupnost aplikace. Ať už se jedná o výpadek stroje nebo softwarovou chybu, pokaždé se jedná o úplné vyřazení na dobu neurčitou. Tato doba navíc není nikterak garantovaná a záleží jen na velikosti chyby a ochotě servisních pracovníků, jak rychle se jim podaří chybu odstranit. 13

3. Očekávané vlastnosti řešení pro práci s daty 3.6 Minimální požadavky nového řešení Rostoucí škálovatelnost a výkonnost bez omezení, bezvýpadková robustnost takových vlastností bych u vybraného řešení v ideálním případě chtěl dosáhnout. Realita se však s teorií často rozchází, a proto bude rozumnější stanovit si minimální očekávané požadavky nového řešení. Pro dobrou výkonnost by mělo řešení zajistit adekvátní výsledky pro jednoduché dotazy i pro velké množství složitých dotazů a musí poskytnout možné řešení pro zvyšující se požadavky. Škálovatelnost by měla umožnit rozšiřovat řešení tak, aby bylo schopné obsloužit potřeby komponent systému Perun při zvyšujícím se množství uživatelů a jejich dat. Dobře škálovatelné řešení by mělo umět obsloužit i několikanásobně větší množství dat podobným způsobem jako nynější množství dat. Robustnost by v tomto případě měla zaručit alespoň parciální funkčnost systému, kdy výpadek některé části neovlivní výpadek celého systému a zotavení se z výpadku bude rozumně odhadnutelné a proveditelné. Parciální funkčnost pak může znamenat omezení pouze na možnost čtení. Nezbytností je zachování open source licence, ačkoliv na konkrétní variantě již v tomto případě nesejde. 3.7 Ostatní důležité vlastnosti nového řešení Zatímco předchozí vlastnosti jsou velmi důležité pro finální řešení, existuje ještě několik dalších dosud nespecifikovaných vlastností, které budou ve výběru technologie hrát také svou roli. Tyto vlastnosti sice nebyly stanoveny v zadání práce, ale jsou pro systém Perun výhodné. Využití existujícího datového schématu bez větších změn na straně systému Perun. Podpora funkcí zajišťujících konzistenci dat (cizí klíče, databázové transakce apod.). Jednoduše instalovatelná implementace pro další instance systému Perun (systém Perun má mnoho instancí rozesetých různě po světě a stará se o jejich udržování). Ideální variantou open source licence je Apache licence. Preference podpory systému Linux. 14

4 Technologické možnosti práce s daty 4.1 Optimalizace stávajícího řešení Jelikož se stávající řešení ukládání dat v systému Perun skládá pouze z relační SQL databáze a dotazů do ní, je jednou z možností optimalizace existujícího řešení. Tím lze vylepšit některé definované vlastnosti (hlavně výkonnost). Protože se tato diplomová práce přímo nezabývá optimalizací systému Perun jako takového, proberu zde pouze základní možnosti. Optimalizace dotazů do DB Toto řešení v sobě zahrnuje prozkoumání aplikačního kódu a zjištění, které části kódu provádí nejvíce volání do DB. Následovala by úprava tohoto kódu tak, aby celý proces byl efektivnější. Toto je často nutné naměřit na konkrétní technologii, ale obecně platí, že některé typy dotazů jsou náročnější než jiné a lze je zjednodušit při zachování vlastností. V jazyce SQL je nejznámějším příkladem vyhýbání se volání dotazu LIKE, který vyhledává shodné podřetězce. Optimalizace existujícího schématu Další z možností optimalizace je úprava existujcího schématu tak, aby lépe odpovídal nejčastěji kladeným dotazům a databáze byla schopná pro tyto dotazy provádět čtení nebo i zápis efektivněji a rychleji. Nejjednodušším příkladem je využívání správných typů sloupců pro ukládání hodnot, například nepoužívat BLOB tam, kde to není nutné. Kromě toho je možné na straně databáze předpřipravovat nejčastěji čtená data, což může zrychlit přístup k nim. Optimalizace dat pro vyhledávání Toto řešení se obecně zaměřuje na optimalizování dat v databázi a zároveň také na využívání struktur, které zrychlují práci s daty. Mohou to být indexy nad tabulkami, dělení tabulek, denormalizování, cachování (tomu se věnuji v samotné podkapitole) apod. [15]. Optimalizace hardware Nejen softwarově lze optimalizovat. Samozřejmě je možné vzít v potaz i optimalizaci hardwaru. Lze například zajistit lepší a rychlejší komunikaci 15

4. Technologické možnosti práce s daty mezi DB serverem a aplikačním serverem, pokud budou ležet na stejné vnitřní síti nebo dokonce na stejném stroji. Bude-li mít stroj více procesorů, bude schopen větší paralelizace a pokud tuto paralelizaci bude schopna podpořit i databáze, bude výsledkem větší výkon. Dále pak lze zakoupit více operační paměti pro využití databázové cache. Stejně tak lze zakoupit rychlejší disky (například SSD nebo i rychlejší plotnové), ze kterých může databáze číst data rychleji a s menším zpomalením. Vždy se vyplatí v tomto směru soustředit na tu část systému, která je nejvíce vytížená (to lze zjistit měřením paměti nebo měřením využití procesorů atd.). 4.2 NoSQL databáze NoSQL databáze jsou databáze, které využívají jiného konceptu ukládání dat, než klasické databáze (tabulková schémata) a k práci s daty většinou nepoužají jazyk SQL. Slovo NoSQL definuje typy databází, které často nedodržují principy RD- BMS 1, především většina z nich není založena na množině vlastností ACID 2, které zaručují spolehlivost jednotlivých databázových transakcí. Některé z nich se pokouší ACID dodržet například pomocí zamykání řádků a jiných technik. NoSQL databáze často využívají specifického způsobu ukládání dat např. pomocí záznamů typu klíč-hodnota a tomu přizpůsobenému a optimalizovanému vyhledávání. Specializují se na konkrétní typ dat a v rámci zpracování těchto dat jsou efektivnější než klasické SQL databáze jako PostgreSQL, Oracle a jiné. Bohužel to sebou nese mnohá omezení jako je nízká úroveň konzistence na straně databáze. Případné nekonzistence se musí řešit. 4.2.1 Garance v databázích Aby bylo možné v dalších kapitolách rozumně pochopit rozdíly mezi SQL databázemi a NoSQL databázemi s různými variantami synchronizace, je nutné nastínit, že mezi základní principy databází obecně patří garance určitých vlastností. Pro účely této práce postačí definice množiny vlastností ACID, dále pak množiny vlastností BASE 3 a ve velké míře dnes zmiňovaného CAP 4 teorému, který vysvětluje nemožnost dodržení veškerých vlastností modelu ACID v distribuovaném prostředí. 1. RDBMS Relational Database Management System 2. ACID Atomic, Consistent, Isolated, Durable 3. BASE Basically Available, Soft state, Eventual consistency 4. CAP Consistency, Availability, Partition tolerance 16

4. Technologické možnosti práce s daty ACID ACID je množina vlastností zaručující spolehlivost jednotlivých databázových transakcí. Skládá se ze čtyř vlastností a je základním stavebním kamenem relačních databází [42]. Atomicita: garantuje, že každá transakce v databázi bude buď přijata celá, nebo nebude přijata vůbec. Pokud databáze o transakci prohlásí, že je potvrzená, nesmí se stát, aby při výpadku proudu byla pouze částečně provedená. Všechna data v rámci transakce jsou buď uvnitř databázového systému, nebo v něm nejsou vůbec. Konzistence: zaručuje, že každá provedená transakce převede databázi z jednoho stavu do druhého se zachováním všech pravidel jako jsou cizí klíče, unikátní klíče apod. Nesmí se stát, aby byla databáze v nekonzistentním stavu, který neodpovídá definovaným pravidlům. Izolace: zajišťuje vzájemnou viditelnost mezi transakcemi tak, aby jedna transakce, do doby než je potvrzena, byla pro ostatní transakce neviditelná. Na základě úrovně izolace se poté definují různé zámky na řádky, tabulky apod. Odolnost: garantuje, že jakmile jsou data jednou prohlášena za potvrzená, jsou uložena v paměti, kde nedojde k jejich ztrátě (například pevný disk). BASE Jedná se o množinu vlastností velmi podobných ACID. V obsahu jednotlivých garancí se však mírně liší. Nejčastější použití je tam, kde se jednotlivé části (uzly) databáze mezi sebou asynchronně synchronizují, a tudíž nemusí mít v daný moment aktuální data na všech uzlech stejná. Na úrovni distribuovaných systémů je však tento přístup naprosto běžný a je potřeba tyto rozdíly vzít v potaz při použití [51]. Popis jednotlivých vlastností: Základní dostupnost: pro každý dotaz je garantovaná nějaká odpověď, ať už jsou to očekávaná data nebo informace o chybě. Proměnlivý stav: stav systému se mění v čase a to i bez uživatelského vstupu (například synchronizace na pozadí, přeskupování dat mezi uzly apod.). Eventuální konzistence: databáze může být krátkou chvíli v nekonzistentním stavu, ale za čas se do konzistentního stavu opět dostane. 17

4. Technologické možnosti práce s daty CAP teorém Jedná se o myšlenku popisující vlastnosti distribuovaného systému vzhledem ke konzistenci a dostupnosti dat [16]. Říká, že pokud je systém distribuovaný, pak nelze zaručit více než dvě ze tří vlastností: Konzistence: je garantováno, že na všech uzlech bude v momentě čtení vždy aktuální a poslední záznam. Dostupnost: je garantováno, že každý uzel vrátí na validní otázku validní odpověď za rozumný čas (nedojde k nečekané chybě nebo timeoutu). Parciální tolerance: je garantováno, že při výpadku na síti bude uzel dále komunikovat i v případě, že ztratí spojení s ostatními uzly. Zjednodušeně řečeno, nastane-li situace, kdy jsou dva uzly vzájemně odpojeny od sebe a nevidí se (čemuž zkrátka na síti nelze nikdy předejít a to ani při redundanci spojení) a oba jsou stále viditelné pro některou část svého okolí, mají v podstatě jen dvě možnosti, jak se zachovat: V případě preference konzistence nad dostupností během této chvíle nebudou odpovídat, dokud se opět nespojí jeden s druhým. Pro aplikace tedy budou nedostupné. V případě preference dostupnosti nad konzistencí budou odpovídat na dotazy a v případě potřeby i provádět změny, které v momentě opětovného navázání spojení budou muset sesynchronizovat a nekonzistenci vyřešit. Prakticky všechna řešení pro práci s daty využívající distribuované sdílení dat (ať už všechny uzly mají všechna data nebo každý drží jen nějaká data) musí počítat s tím, že zajištění klasického ACID jako na jednom stroji v podstatě není na 100% možné a musí si nějak poradit s nedostupností nebo momentální nekonzistencí (neaktuálním stavem). Čím složitější řešení, tím samozřejmě složitější strategie pro řešení těchto situací. Strategie řešení konfliktů Pro řešení konfliktů se používají různé strategie: Nejvyšší časové razítko vyhrává (poslední zadaná hodnota). Jeden z uzlů je dominantnější, a má tudíž vždy pravdu (právo veta). 18

4. Technologické možnosti práce s daty Největší množství uzlů se stejnou hodnotou má pravdu (síla skupiny). Možností je samozřejmě daleko více a záleží jen na konkrétních podmínkách, pro které se daná strategie nejlépe hodí. Špatně zvolená strategie může mít vliv na způsob vyhodnocování a četnost neočekávaných stavů aplikace. 4.2.2 Typy NoSQL NoSQL databází existuje hned několik typů. Nejznámější jsou sloupcově orientované databáze, dokumentové databáze, dále pak databáze se záznamy uloženými jako klíč-hodnota a grafové databáze. Speciální variantou jsou pak hybridní typy NoSQL, které kombinují více než jeden z těchto přístupů. V následujících odstavcích jsou zmíněné typy popsány blíž [51]. Sloupcově orientované databáze Sloupcově orientované databáze ukládají data do sloupců namísto klasického přístupu ukládání do řádků (v konceptu RDBMS). To umožňuje větší flexibilitu v přidávání nových sloupců podle potřeby. Zatímco klasické řádkové databáze využívají ukládání řádků coby záznamů a následně v těchto řádcích hledají, sloupcové databáze ukládají data v podobě sloupců a shlukují tedy informace v sloupcích za sebou. Pokud je nejčastější operací hledání nad množinou dat, která má nějaká kriteria, jsou sloupcové databáze mnohem rychlejší. Vhodnější jsou také v případě práce s agregovanými daty oproti práci s individuálními záznamy. Výhodou je podoba s klasickými řádkovými databázemi, ačkoliv schéma jako takové se musí dobře navrhnout. Dokumentově orientované databáze Dokumentově orientované databáze se používají se k ukládání, čtení a úpravě částečně strukturovaných dat. Dokumenty jsou zde definovány jako záznamy. Záznam nemusí být úplný a může obsahovat různé množiny položek nebo sloupců s daty. Bývá dobrým zvykem ukládat u každého dokumentu alespoň jeho identifikační číslo pro následující práci s ním. Výhodou takového typu databází je velká flexibilita a dynamická změna schématu nebo jeho úplné vynechání. Dokumentové databáze se zakládají se na nějakém dokumentovém typu jako je JSON 5, XML 6 nebo YAML 7 a ke komunikaci s touto databází 5. JSON JavaScript Object Notation 6. XML Extensible Markup Language 7. YAML Ain t Markup Language 19

4. Technologické možnosti práce s daty většinou slouží nějaké REST 8 rozhraní (podobné jako třeba perun-rpc v kapitole 2). Nejvýhodnější využití je často ve webových aplikacích, které potřebují ukládat různé typy záznamů, které v čase mění svůj obsah a rozšiřují se. V případě využití schématu je toto mnohem složitější. Podle implementace jsou pak jednotlivé databáze schopny manipulovat buď pouze s celými dokumenty, nebo i s jednotlivými záznamy v dokumentech. Při vyhledávání skrze dokumenty je pak možné vytvořit rozmanitější a benevolentnější strukturu než v případě běžných dat. Dnes se již pomalu přemísťuje práce s dokumenty i do klasických SQL databází (podpora dokumentů). Výhodou je možnost použití existujících nástrojů pro vyhledávání ve strukturovaných datech jako např. XQuery 9, XPath 10 apod. Databáze typu klíč-hodnota Databáze typu klíč-hodnota je asi nejrozšířenější verze NoSQL databází. Umožňují ukládání nějaké hodnoty oproti podstatně jednodušímu a lépe prohledávatelnému klíči. Využívá se zde stejných principů jako v hašovací tabulce (struktura pro ukládání asociativních polí, kde na základě funkce přidělím hodnotě místo a dokážu ji pak stejným způsobem hledat). Tento typ databáze stejně jako dokumentově orientované databáze nepotřebuje ke své existenci schéma. V době vzniku záznamu však musí existovat klíč, pod který se tento záznam uloží. Zároveň je také možné hodnotu z databáze získat jen tehdy, pokud je znám klíč. Tyto databáze fungují na základě konceptu tzv. hašovacích tabulek. Často se využívají společně s cachováním a čtením obsahu z rychlejší operační paměti. Ačkoliv databáze nevidí obsah hodnoty, může operovat s definicí jejího typu a díky tomu poskytovat další funkcionalitu (atomicka inkrementace, úprava více položek najednou, průnik, sjednocení nebo rozdíl pro práci s množinami a další). Díky principu hašovacích tabulek je možné v nich velmi efektivně vyhledávat podle klíče a toto vyhledávání lze dobře škálovat i přes více databázových strojů. Bohužel další vlastnosti databází jsou velmi omezené, neboť základem je potřeba hodnoty ukládat a číst, méně pak řešit jejich obsah a validitu. Samotná kontrola je navíc složitější o to, že v hodnotě může být prakticky cokoliv dle implementace třeba i dokument, a databáze si nedrží schéma. 8. REST Representational State Transfer 9. XQuery dotazovací jazyk pro čtení a transformaci dat často pro formátu XML 10. XPath jazyk pro adresování částí XML dokumentů 20

Grafové databáze 4. Technologické možnosti práce s daty Jedná se o specifickou reprezentaci NoSQL databáze, která má vazby reprezentované pomocí hran grafů a následně tyto vazby definuje a popisuje. Na základě vazeb mezi uzly je možné efektivní vyhledávání dat pomocí grafových algoritmů. Koncept je opravdu široký, ale použití je o něco složitější. Největší úspěch těchto databází je na poli sociálních sítí a mapování jednotlivých relací mezi uživateli sítě. Jednoduše lze získat všechny, kteří spolu sdílí nějakou vlastnost (záliba, kamarád atd.). Hybridní multi-storage databáze Jedná se o kombinace předchozích řešení pro dosažení lepších vlastností. Většinou je to více technologií zkombinovaných a volaných přes jedno společné API. Například kombinace relační SQL databáze a některé z NoSQL databází, nebo grafové databáze a dokumentové databáze. Ačkoliv je zde určitá režie komunikace mezi dvěma databázemi, při různorodém obsahu a správném navrhu jsou schopny dosahovat velmi dobrých výkonnostních výsledků. 4.2.3 Vhodnost použití NoSQL databází Tyto databáze jsou vhodné za předpokladu, že pro ně existuje správně navržený use case (příklad užití). Nad konkrétním typem dat jsou velmi efektivní. Ve většině aplikací však své místo najdou spíše jako podpora určité funkcionality než hlavní nástroj pro ukládání všech dat. Osobně je považuji především za prvek optimalizace konkrétního řešení než samostatnou technologii pro celou jednu aplikaci, ale záleží na konkrétním účelu. 4.2.4 Obecné výhody a nevýhody NoSQL řešení Výhody Bez schématu: mnoho NoSQL řešení neudržuje schéma dat a umožňuje tak tvořit libovolné struktury (s tím se pojí ale i nízká míra zajištěné konzistence). Rychlost: rychlejší odpovídání na dotazy do databáze je často založené na jednoduchém a efektivním ukládání a vyhledávání. Což si ale bere svou režii a složitost na straně aplikace při skládování dat a zajišťování konzistence. Vyšší škálovatelnost: lze dosahovat mnohem lepší škálovatelnosti za cenu vyšší jednoduchosti a často ztráty některých vlastností ACID. 21

4. Technologické možnosti práce s daty Nevýhody Nezachovává ACID: dnes už existuje mnoho výjimek, které v nějaké variantě vlastnosti ACID zachovávají, ale bez zachování ACID je samozřejmě zajištěna vyšší výkonnost i škálovatelnost řešení. Náročnější na aplikační část: je nutné použít více dotazů k získání stejné informace jako v relačních databázích a navíc řešit konzistenci a unikátnost dat již na straně aplikace. Nepoužívání vztahů: výjimkou jsou grafově orientované databáze, které jsou založeny právě na vztazích (často zcela chybí cizí klíče a obecné vazby mezi záznamy). Absence transakcí: se často pojí s podporou vlastností ACID. Některá řešení transakce podporují, některá ne. Absence vlastností podporujících konzistenci dat: záleží na implementaci (unikátní klíče, cizí klíče, constrainty apod.). 4.3 Cachování a databáze operující v paměti Cachováni je technika zvýšení výkonu především při čtecích operacích. Místo čtení dat z datového úložiště (například databáze) se data čtou přímo z cache počítače, když jsou potřeba. Typicky je cache uložena v rychlé paměti (operační paměti) zařízení, které s ní pracuje. Cache může mít několik úrovní, například jedna na straně databáze, jedna na straně aplikace a další na straně klienta. Často je potřeba řešit problémy s obnovováním aktuálních dat. Například cachování u webových prohlížečů může způsobovat potíže s aktuálností obsahu. Ukládání dat v operační paměti je samozřejmě rychlejší, ale data jsou při případném restartu systému ztracena. Specifickou variantou cache je tzv. databázová cache. Tu si lze představit jako mezivrstvu mezi aplikací a databází, ve které jsou uloženy některé často řešené dotazy, tabulky a jiné potřebné informace. Nejlepšího využití dosahuje hlavně v případě, že dochází k přenosu dat po síti, a tak umožní data předpřipravit nejen na serveru, ale i na cílovém stroji. Kromě výhod ale také existuje několik složitějších principů, které je potřeba při nasazování takového řešení vzít v potaz a vyřešit je [19]. Plnění databázové cache: liší se implementace od implementace a existuje mnoho variant, často se využívá takové, které je rozumně jednoduché a odpovídá očekávání dané aplikace. 22

4. Technologické možnosti práce s daty Synchronizace cache: je nutné udržovat konzistenci mezi cache a hlavním datovým úložištěm. Pokud dojde k nekonzistenci, může to vyvolat velmi nepříjemné chyby v aplikaci. Náročnost na paměť: v dnešní době je paměť relativně levná záležitost, takže se příliš často nestává, že by jí byl nedostatek. Přesto v případě cache je určitě důležité se zamyslet nad tím, kolik místa bude k uložení dat potřeba. Cache stojí výkon: využití cachování nenese vždy pouze výkonnostní výhody. Při špatném použití může naopak způsobovat zpomalení celého systému. Je potřeba si dobře promyslet k čemu a jak se bude cache používat. 4.3.1 Plnění databázové cache Prvním z řešených principů je způsob plnění cache daty. Zde existují obecně dvě metody. Proaktivní řešení (dopředné ukládání dat) a reaktivní řešení (líné ukládání dat). Tato řešení je samozřejmě možné navzájem kombinovat a část dat řešit proaktivně a část reaktivně [24]. Proaktivní plnění cache Data jsou do cache vložena už v momentě jejího spuštění a jsou tak připravena k odpovědi na konkrétní dotazy. Toto řešení samozřejmě očekává, že existuje informace o tom, jaká data bude potřeba cachovat. V případě, že je známo, která data jsou nejčastěji získávána z databáze, může toto řešení být vhodnější než reaktivní. V případě, že jsou však čtena častěji data, která v cache nejsou, nebo není dopředu známo, jaká data zde budou (například na základě statistik), nemusí být toto řešení přílis vhodné. Výhody Řešení je schopné odpovídat na konkrétní dotazy ihned po vytvoření cache a není zde tedy zpomalení způsobené synchronizací prvotních dat s databází. Řešení je velmi vhodné můžeme-li předem říci, jaká data budou nejčastěji volaná. 23

4. Technologické možnosti práce s daty Nevýhody Inicializace cache trvá nějakou dobu a je potřeba počkat, až se data načtou, to je nutné řešit při každé inicializaci aplikace. Při špatně zvoleném obsahu cache se některá data nikdy nepoužijí a pouze zabírají místo v paměti. Reaktivní plnění cache Častěji používané řešení je reaktivní plnění cache. To se zakládá na reakci na dotaz z aplikace. Ve chvíli, kdy je zavolán dotaz se zjistí, zda cache nemůže rovnou odpovědět (při prvním volání na otázku v cache není odpověď). Pokud ne, zavolá databázi, která na dotaz odpoví a samotná cache si potom tuto odpověď zapíše, aby v příštím volání již byla schopna odpovědět. Pokud je schopna odpovědět, databáze se o dotazu ani nedozví. Reaktivní plnění cache je oblíbené právě pro svou jednoduchost a dynamiku. Výhody Toto řešení cachuje jen ta data, která se aktuálně čtou nebo je bylo v nějaké fázi potřeba číst (aplikace si o ně zažádala). Není zde žádné zpoždění při inicializaci aplikace. Nevýhody Na začátku při startu aplikace se cache musí prvně postupně naplnit, než je možné využít její podpory (to často trvá déle než když cache není vůbec použita). Při častých změnách dotazů se může stát, že v cache nikdy nebudou k dispozici požadovaná data. 4.3.2 Synchronizace cache Nejsložitějším a nejdůležitějším bodem je samozřejmě synchronizování dat mezi cache a databází. V podstatě to znamená, že odpověď z cache je při nalezení dat stejná jako odpověď databáze v ten samý moment. Existuje několik variant, jak synchronizovat cache s databází, ty nejpoužívanější zde popíši [19]. 24

Write-through synchronizace 4. Technologické možnosti práce s daty Tento typ cachovací techniky umožňuje inteligentně měnit obsah cache během dotazů, aniž by bylo nutné zahodit celý obsah. Ve chvíli, kdy se provádí změna dat, změní se data v cache a následně se změna propaguje do databáze, kde se data změní též. Toto řešení lze použít jen tehdy, pokud ke změně dat dochází jen skrze cache. Když by bylo možné data upravit například i přímým přístupem k databázi, mohlo by dojít k desynchronizování obsahu mezi databází a obsahem cache. Nevýhodou je relativně složitá struktura cache. Synchronizace pomocí omezené expirace dat za daný čas Pokud lze data v databázi měnit nezávisle na cache, může docházet k desynchronizaci. Jedním z řešení tohoto problému je zajištění expirace dat v cache po určitém čase. Když data expirují, jsou z cache odstraněna. Jsou-li opět potřeba, načtou se znovu z databáze zpět do cache. Délka expirace pak odpovídá potřebám systému. Některá data není potřeba aktualizovat příliš často, například stačí jednou za hodinu nebo dokonce jednou za den. Pro často aktualizovaná data není toto řešení příliš vhodné, neboť časté mazání a znovunačítání dat může způsobit zhoršení vlastností cache. Synchronizace na základě aktivní expirace Alternativa k expiraci za daný čas je aktivní expirace. To znamená, že ve chvíli úpravy dat se pošle do cache informace o tom, že některá data expirovala a cache tato data smaže ze svého obsahu. Oproti předchozímu řešení má toto výhodu, neboť drží data synchronizovaná tak rychle, jak je jen možné. Stejně tak se neprovádí expirace takových dat, která žádnou změnou neprošla. Nevýhodou je, že musí existovat mechanismus, který bude cache informovat o každé úpravě dat. 4.3.3 Náročnost na paměť Tento problém je vždy na místě, neboť databáze může přerůst přes velikost paměti (často stroj není určen jen pro databázi a jeji cache). V moderním světě, kde jsou paměti levné, je samozřejmě možné postavit paměť i ve velikosti několika TB, ale ne každý má k dispozici takové možnosti. Za předpokladu, že je paměť menší než množství dat, která se do ní budou ukládat, je nutné navrhnout takové řešení, které bude stará data průběžně mazat. Existuje mnoho strategií, opět popíšu jen ty nejčastěji používané [19]. 25

4. Technologické možnosti práce s daty Časově omezené odstranění dat: je podobné expiraci za daný čas s krátkým časem mezi validitou a expirací dat. Může mazat data z paměti ve chvíli, kdy expirují. FIFO (first in first out) řešení: ve chvíli, kdy cache narazí na limity paměti, vymaže nejnovější volaný dotaz. FILO (first in last out) řešení: ve chvíli, kdy cache narazí na limity paměti, vymaže nejstarší volaný dotaz. Nejméně používaný: vymaže záznam, který má v daný čas nejmenší množství přístupů. Toto řešení musí udržovat informace o počtech volání konkrétních hodnot. Nejdelší čas mezi použitím: odstraněn je záznam, který byl nejdéle nepoužit. Opět je nutné udržovat záznam o posledním použití (například poslední čtení z dané tabulky). 4.3.4 Vícemístné cachování Už jsem se zmínil, že je možné cachovat na straně serveru, aplikace a klienta. Kromě toho je také možno cachovat v distribuovaném prostředí na straně několika serverů. Zatímco cachování, které probíhá na jednom místě, se může spolehnout na to, že v případě přístupu skrze cache by se data měla synchronizovat bez většího problému. V případě cachování na více uzlech, do kterých lze zapisovat, je tento problém daleko složitější. Při použití writethrough cache nelze synchronizovat všechny existující cache najednou. Je nutné používat nějakou variantu expirace dat. 4.3.5 inmemory databáze Podobný princip jako v případě cache využívá i tzv. inmemory databáze. Ta ukládá veškerý databázový obsah v operační paměti. Chceme-li zachovat vlastnosti ACID obdobně jako u běžné databáze na disku, musí se řešit zachování odolnosti. Aby bylo možné zachovat odolnost, a to i v případě vypnutí elektrického proudu, při které se operační paměť vymaže, je nutné použít některý z mechanizmů meziukládání stavu [3]. Snapshots: ukládají na disk obraz databáze k určitému času, to se děje periodicky nebo v případě očekávaného vypnutí zařízení. Ztráta části dat je ovšem možná. 26

4. Technologické možnosti práce s daty Transakční logy: ukládají stav databáze a změny v ní do žurnálových souborů. V případě výpadku je databáze schopna na základě těchto informací obnovit konzistenci. Nevolatilní paměti RAM: jsou paměti schopné přežít výpadek proudu nebo stroje, často s podporou baterií nebo záložních zdrojů. Vysoká dostupnost: znamená možnost držet více než jednu instanci téže databáze (synchronizace na úrovní hardwaru) a následné přepnutí v případě ztráty aktuálně primárního zařízení. 4.3.6 Vhodnost použití cache a inmemory databází Cache je vhodnou technikou, jak předpřipravit nejčastěji čtená data ještě před tím, než je nutné je číst z disku. Využívá rychlejší paměti, což platí i pro inmemory databáze, limitujícím faktorem je zde velikost databáze a možný problém se ztrátou dat v případě pádu stroje. Nezávisle na této diplomové práci vznikla bakalářská práce pro aplikační cachování atributů v systému Perun [17]. Využívá reaktivního write-through řešení na straně aplikace a ukládá pouze statické atributy. Je to ten správný způsob využití, neboť je možné očekávat časté čtení a jen občasnou změnu těchto dat. Prozatím není nasazená, a v měřeních se tudíž nijak neprojeví, přesto má smysl s ní počítat a proto myšlence cachování dat nebudu přisuzovat až tak vysokou váhu jako ostatním technologiím. 4.4 Replikace relačních SQL databází Jedná se o způsob distribuce informací mezí více instancemi databázových serverů. Může se jednat o distribuci mezi stejnými nebo různými typy databází, lze distribuovat veškerá data nebo jen některá. Stejně tak je možné distribuovat data pouze pro čtení nebo i pro zápis. Velkou výhodou je, že ve většině případů není nutné měnit obsah existujících dat a schématu. Z tohoto důvodu může být toto řešení použito i na již existujícím databázovém schématu včetně zachování produkčních dat. Nevýhodou je, že některá distribuovaná řešení postrádají klíčové vlastnosti samostatných databází (cizí klíče, unikátní klíče apod.) dle konkrétní implementace. 4.4.1 Vlastnosti systémů pro replikaci SQL databází Téměř všechny replikační systémy sdílí několik společných vlastností. Na základě nastavení těchto vlastností je možné provést výběr případného řešení. 27

4. Technologické možnosti práce s daty typ podporovaných DB a jejich verzí replikační metoda způsob výměny dat podpora rozdělení zátěže velkého množství připojení (každá databáze má omezené množství spojení v jeden čas) podpora rozkládání zátěže dotazů (tzv. loadbalancing) podpora zpamatování se z výpadku (tzv. failover) Typy podporovaných databází V této fázi se zabývám pouze relačními databázemi, neboť NoSQL databáze používají vlastní řešení, které bude nastíněno u jednotlivých technologií v další kapitole. Z existujících databází jsou přijatelná pouze open source řešení. Níže je uveden soupis těch, které považuji za zajímavé. MySQL 11 MSSQL 12 PostgreSQL SQLite 13 FirebirdSQL 14 Hypertable 15 HSQLDB2 16 Replikační metoda Existuje několik typů, jak data replikovat. První typ definuje vztah mezi replikami a hlavní databází, druhý pak způsob, jakým se data mezi replikou a hlavní databází předávají [23]. 11. My SQL http://www.mysql.com/ 12. Microsoft SQL http://www.microsoft.com/en-us/server-cloud/products/sql-server/ 13. SQL Lite lehká verze SQL, http://www.sqlite.org/ 14. Firebird SQL http://www.firebirdsql.org/ 15. Hypertable http://hypertable.org/ 16. Hyper SQL database http://hsqldb.org/ 28

4. Technologické možnosti práce s daty Master-slave: veškeré modifikační dotazy jsou směřovány na hlavní databázi (master), hlavní databáze pak poskytuje nebo přímo posílá data o změnách na jednotlivé repliky (slave servery), které slouží pouze pro čtecí operace. Master-master (multi-master): více hlavních databází pro zápis i čtení, všechny fungují samostatně a spolu pouze komunikují za účelem synchronizace a řešení konfliktů. Statement-Based (stavově orientované) řešení: každý modifikační SQL dotaz je poslán do všech databází naráz, zde se zpracuje a poté se globálně rozhodne o potvrzení (commit) na základě informace o tom, zda na všech serverech proběhnulo potvrzení vpořádku (například pomocí dvoufázového potvrzení). Jelikož se dotazy na jednotlivých serverech vyhodnocují samostatně, může docházet k nesourodosti některých specifických funkcí jako získání časového razítka apod. Standby-server (čekající): často ve variantě master-slave, kdy jedna nebo více replik je v režimu čekání, neodpovídá na dotazy ani čtecí ani modifikační. Ve chvíli, kdy by hlavní databáze havarovala, je schopna se z režimu čekání rychle přepnout a nahradit její místo s aktuálními daty. Sdílený disk: toto řešení se často pojí s vysokou dostupnosti, neboť spoléhá na to, že se udržuje naráz více instancí databázových serveru, ale čtení probíhá z jednoho sdíleného místa. Pokud by tedy došlo k pádu hlavní databáze, pouze se hardwarově přepne disk, což pro uživatele znamená jen krátký výpadek. Symetrická replikace: každý uzel má svá data, a tudíž je možné veškeré úpravy a čtení provádět právě na daném uzlu. Všechny uzly tedy jsou schopny provádět čtení i zápis (často se pojí s nějakou redundancí dat mezi uzly). Způsob výměny dat Obecně existují dva způsoby výměny dat. Synchronní a asynchronní [20]. Synchronní: pouze potvrzení všech synchronizovaných uzlů provede změnu. To zajistí, že jsou data v jeden moment na všech uzlech stejná. Zároveň však způsobuje velké zpomalení při ukládání dat způsobené vzájemnou komunikací a čekáním. 29

4. Technologické možnosti práce s daty Asynchronní: změna se provede ihned tam, kde je požadována, na ostatní uzly se propaguje se zpožděním. V případě replikace, kdy je možné zapisovat z více uzlů, je nutné řešit případnou nekonzistenci. Toto řešení je však výrazně rychlejší než synchronní, a právě proto se častěji používá. Kombinace: samozřejmě je možné část dat distribuovat synchronně a část asynchronně, umožňuje-li to technologie. Distribuce připojení Pokud řešení podporuje distribuci jednotlivých připojení (tzv. connection pooling), znamená to, že si udržuje některá spojení otevřená pro účely dalšího využití. Důvod udržování je minimalizace režie otevírání a zavírání spojení k databázi. Většinou jsou tato spojení specifická a nelze je tedy nabídnout každé aplikaci, proto i zde musí docházet k recyklaci spojení v případě, že nejsou využita [1]. Distribuce zátěže Máme-li k dispozici více než jeden databázový server poskytující čtení nebo zápis, je možné tímto způsobem rovnoměrně rozdělit přicházející dotazy mezi servery. Distribuce pak existuje na úrovni připojení a na úrovni dotazu. Na úrovni připojení se pro každé nové připojení přidělí nejméně zaneprázdněný uzel (nebo uzel, který má nejvyšší váhu vě výběru). V případě distribuce na úrovni dotazu se takto předává každý dotaz (zde hrozí, že se při asynchronní replikaci složí odpověď ze dvou různých stavů databáze). Volba uzlu při rozdělení zátěže může být také čistě náhodná nebo na základě nějakého algoritmu (např. Round-robin 17 ) [4]. Zotavení z pádu Jedná se o schopnost zotavení se z pádu části databáze. To lze provést znovunačtením odpojených uzlů, nahrazením novými uzly apod. Nejčastěji se v tomto kontextu jedná o zotavení z pádu hlavní databáze, neboť výpadek repliky většinou neznamená žádný velký problém, může-li ji jiná replika zastoupit. Záleží zde na implementaci a také na replikační metodě daného řešení. Ve speciálním případě, kdy se jeden ze slave serverů stane novým masterem, se jedná o tzv. failover. Ve chvíli, kdy je potřeba původní master 17. Round-robin plánovací alrogitmus přidělování zdrojů 30

4. Technologické možnosti práce s daty opět vrátit na své místo a vše uvést do původního stavu, se jedná o tzv. failback [43]. 4.4.2 Vhodnost použití replikací nad databázemi Nejvhodnější využítí replikace je v případě, že se již pro účely práce s daty používá některá ze zmíněných SQL databází a nechceme příliš měnit schéma nebo způsob uložení dat. Pro systém Perun se zdá právě tato metoda jako vhodná a věnuji ji velkou pozornost v dalších kapitolách. 4.5 Ucelená aplikační řešení (framework) Existuje několik hotových řešení, která nabízejí vlastní metodiku práce s daty. Tyto aplikace pak můžou mít různými technologiemi vyřešené cachování, replikaci dat, failover a další vlastnosti. Obecně se o nich můžeme bavit jako o datovém middleware. Aplikace komunikuje s middlewarem a ten se stará o všechny ostatní funkcionality jako je práce s databází, redundance dat apod. Jelikož se jedná o většinou několik spojených technologií, je možné využívat více benefitů, které nabízejí. Nestagnuje-li projekt, je možné počítat s podporou vývojářů. Kromě jiného často zjednodušují a zpřehledňují komunikaci s databází například objektovým přístupem k dotazům, kdy není nutné v aplikační vrstvě vytvářet například SQL dotaz, ale postačí si vyžádat objekty z databáze daného typu s danou hodnotou. SQL dotaz se pak vytvoří automaticky na základě společného schématu. Cílem těchto technologií je oprostit vývojáře od způsobu ukládání dat. Nevýhody tu samozřejmě také jsou, ať už se jedná o problém aktualizace daného softwaru ze strany vývojového týmu nebo nutnost spoléhat se na jeho funkcionalitu. To co je největší výhodou může být u některých aplikací i nevýhoda. V tomto případě myslím odtržení vývojového týmu od způsobu práce s daty. Tento koncept je dobré vzít v potaz už od vzniku projektu a vyvíjet aplikaci spolu s ním. Ve chvíli, kdy má aplikace vlastní složitý datový model a mnoho produkčních dat není toto řešení zcela ideální. Z tohoto důvodu jsem se rozhodl tuto technologii dále nerozebírat, pouze zde zmíním nejznámější představitele. jooq 18 18. Java object oriented querying http://www.jooq.org/ 31

4. Technologické možnosti práce s daty JBoss 19 Play framework 20 Active JDBC 21 19. JBoss http://www.jboss.org/ 20. Play framework https://www.playframework.com/ 21. Active Java Database Connectivity http://javalite.io/activejdbc 32

5 Konkrétní technologická řešení V této kapitole rozebírám konkrétní řešení, která jsem vybral na základě technologií z předchozí kapitoly. U každého řešení popisuji obecnou definici a následně jeho důležité výhody a nevýhody. Pro lepší srozumitelnost pak tyto vlastnosti ještě rozděluji do jednotlivých kategorií, které ještě hodnotím v tabulce na konci kapitoly. Obsáhlejší rozdělení je možné najít v tabulce v příloze A. 5.1 NoSQL Databáze 5.1.1 Sloupcové DB HBase HBase je WCS 1 databáze založena na principu sloupcových databází. Vznikla v rámci projektu Hadoop 2 firmy Apache 3 a vychází z myšlenek projektu BigTable 4. Mezi řádky a sloupci neexistuje fixní typ, a proto v každé buňce může být uložen libovolný povolený obsah. Svým způsobem se jedná spíše o datové skladiště než databázi, a proto je vhodné použít ji tam, kde je obrovské množství záznamů [47][46]. Výhody Výkonnost a škálovatelnost: Toto řešení umí rozumně škálovat data tím, že je dělí mezi jednotlivé uzly (tzv. sharding). Obsahuje vlastní blokovou cache a podporuje obsah ve velikosti desítek milionů záznamů. Robustnost: Podporuje automatické zotavení z pádu některého z uzlů a volitelný typ replikace. Nevýhody Výkonnost a škálovatelnost: Jedná se o nevhodné řešení pro malý počet záznamů. Jedná se spíše o datové skladiště. 1. Wide column store - dvoudimenzionální databáze typu klíč-hodnota 2. Hadoop http://hadoop.apache.org/ 3. Apache http://httpd.apache.org/ 4. BigTable http://andrewhitchcock.org/?post=214 33

5. Konkrétní technologická řešení Konzistence: Téměř veškerou konzistenci je nutné řešit na straně aplikace. Neřeší například typy řádků a sloupců, v každé buňce může být jiný obsah. Nezná sekundární indexy 5. Nepodporuje databázové transakce ani složitější dotazování. Ostatní: Náročné na zavedení. V případě systému Perun by bylo nutné výrazně změnit způsob práce s daty. Nepodporuje vůbec dotazování jazykem SQL. Cassandra Tato databáze opět od firmy Apache je vhodná pro použití tam, kde je potřeba vysoká škálovatelnost a dostupnost. Obdobně jako v případě HBase se jedná o databázi typu WCS. Vsází na rozdělení dat na tak malé části, aby mohla být rozmístěna mezi množství serverů a jednoduše získávana distribuovaným způsobem. Většinu konzistence a práce s ucelenými daty přesměrovává na aplikaci [44][41]. Výhody Výkonnost a škálovatelnost: Obdobně jako u HBase se data distribuují mezi uzly. Robustnost: U řešení je volitelná forma odolnosti dat podle způsobu replikace. Podporuje automatické zotavení z výpadku uzlu. Jedná se o decentralizované řešení. Nevýhody Konzistence: Podobně jako HBase nechává většinu konzistence řešit aplikaci. Nezná např. cizí klíče, nepodporuje spojování hodnot na úrovni dotazu, nepodporuje databázové transakce. Ostatní: Nepodporuje jazyk SQL, lze se dotazovat pouze velmi jednoduše. Z velké části by bylo nutné změnit způsob práce s daty systému Perun. 5. sekundární index způsob jak efektivně přistupovat k záznamům jiným způsobem než přes primární klíč 34

5.1.2 Dokumentově orientované databáze MongoDB 5. Konkrétní technologická řešení Dokumentově orientová NoSQL databáze, kterou je možné používat na různých systémových platformách. Podporuje převážně dokumenty ve formátu JSON. Umí vyhledávat v dokumentech na základě regulárních výrazů a nedrží si schéma, takže je možné mít dokumenty s různými obsahy. Zároveň umí rozumně indexovat data v dokumentech a distribuovat zátěž mezi jednotlivými uzly [28]. Výhody Výkonnost a škálovatelnost: Podporuje indexování v dokumentech a dělení dat mezi uzly. Robustnost: Podporuje master-slave replikaci a automatické zotavení z chyb. Konzistence: Transakce jsou nahrazeny zamykáním řádků. Nevýhody Konzistence: Na slave replikách je zajištěna pouze eventuální konzistence (asynchronní replikace). Nepodporuje cizí klíče. Zamykání je pomalá metoda pro zajištění konzistence. Ostatní: Nepodporuje spojování hodnot na úrovni dotazů. Z velké části by bylo nutné změnit způsob práce s daty systému Perun. CouchDB Je to dokumentová databáze od firmy Apache s podporou JSON dokumentů. Tento typ databáze je vhodný pro mobilní aplikace, kde může často docházet k výpadkům spojení a je nutné, aby aplikace běžela i při výpadku sítě. Je vhodná pro méně časté zápisy a časté čtení předem definovaných dotazů s řešením kolizí. Konzistence je zajištěna nastavením, které definuje čekání hlavní databáze na synchronizaci s replikami po změně. Očekává se eventuální konzistence [45]. Výhody 35

5. Konkrétní technologická řešení Robustnost: Podporuje master-master a master-slave replikace. Vhodná pro prostředí, kde často dochází k výpadkům (synchronizace se provede až po obnovení spojení). Konzistence: Místo transakcí využívá MVCC (Multi-version concurrency control) mechanismus, který je velmi podobný databázovým transakcím. Nevýhody Konzistence: Podporuje pouze eventuální konzistenci dat (asynchronní replikaci). Při využití master-master replikace je nutné řešit případnou nekonzistenci vzniklou zápisem do více než jednoho master uzlu naráz. Ostatní: Z velké části by bylo nutné změnit způsob práce s daty systému Perun např. převedením do formátu JSON dokumentů. Část dat by se musela denormalizovat pro správnou funkci. BaseX Dokumentová databáze, která je založená na podpoře XML dokumentů. Využívá nástrojů pro vyhledávání a parsování XML dokumentů jako XPath a XQuery. Podporuje zámky a indexy nad jednotlivými dokumenty. Bohužel toto řešení nebylo navrženo přednostně ke škálování, a tak ho samostatně nepodporuje [12]. Výhody Výkonnost a škálovatelnost: Podporuje primární i sekundární indexy nad dokumenty. Konzistence: K udržení konzistence využívá zámků nad dokumenty (čtenáři a písaři). Ostatní: Částečně podporuje jazyk SQL (konverze do XQuery). Umožňuje fulltextové vyhledávání v dokumentech. Nevýhody Výkonnost a škálovatelnost: Nepodporuje škálovatelnost (pouze jedna instance). 36

5. Konkrétní technologická řešení Robustnost: Nepodporuje robustnost nad úroveň jedné instance. Konzistence: Nepodporuje databázové transakce. 5.1.3 Databáze typu klíč-hodnota Redis Redis je NoSQL databáze se záznamy typu klíč-hodnota. Umožňuje práci s různými datovými strukturami uloženými v klíči i hodnotě. Ty mohou obsahovat např. řetězec, haš, pole nebo množinu a další speciální struktury. Mimo jiné běží tato databáze plně v operační paměti (in-memory), což některé její vlastnosti limituje, ale zvyšuje její výkonnost [13]. Výhody Výkonnost a škálovatelnost: Řešení běží plně v operační paměti (inmemory) a využívá metody snapshotů k ukládání stavu na disk. Řešení je vysoce výkonné pro malé i velké množství dat. Robustnost: Umožňuje master-slave replikaci a automatické zotavení z pádu. Konzistence: Transakce je na úrovni zámků nad záznamy. Ostatní: Pod klíčem i hodnotou lze ukládat složitější datové struktury nebo binární sekvence. Nevýhody Výkonnost a škálovatelnost: Velké objekty je nutno ukládat na disk. Jedná se o jednovláknovou aplikaci (neumí paralelizovat). Nepodporuje sekundární indexy. Konzistence: Zámky jsou pomalý způsob zajištění konzistence v databázi. Nelze používat cizí klíče. Ostatní: Z velké části by bylo nutné změnit způsob práce s daty systému Perun. Nepodporuje jazyk SQL ani žádný jiný podobný. 37

5. Konkrétní technologická řešení Oracle Barkeley DB Jedná se o databázi poskytující vysoce výkonné řešení pro ukládání dat typu klíč-hodnota. Využívá softwarové knihovny BarkeleyDB. Data ukládá jako bitová pole a podporuje více hodnot pro jeden klíč. Omezení je zde ve způsobu ukládání dat v podobě klíč-hodnota. Umožňuje používat zjednodušený jazyk SQL pro práci s databází [31]. Výhody Výkonnost a škálovatelnost: Lze dobře škálovat čtecí dotazy přidáváním nových uzlů. Robustnost: Umožňuje master-slave replikaci a manuální zotavení z pádu. Konzistence: Podporuje databázové transakce. Ostatní: Používá jazyk velmi podobný SQL (zjednodušené SQL). Nevýhody Výkonnost a škálovatelnost: Neumí rozkládat zátěž, k této činnosti je nutné využít jinou technologii. Robustnost: Zotavení z pádu je pouze na úrovni podpory nástrojů, které by bylo nutné doimplementovat. Konzistence: Nepodporuje vnořené transakce (nested transakce transakce uvnitř transakcí), které systém Perun používá. Ostatní: Z velké části by bylo nutné změnit způsob práce s daty systému Perun. Voldermort Distribuovaná databáze se záznamy v podobě klíč-hodnota. Podporuje replikaci dat a jejich rozdělení tak, aby každý server držel jen část, a tudíž se dotazování mohlo rozdělit jako společná práce (tzv. sharding). Oficiální zdroje uvádí, že se jedná o velké distribuované skladiště hašů a hodnot pod nimi uloženými. Jako úložiště klíčů a hodnot využívá podle potřeby buď BarkeleyDB nebo MySQL [6]. 38

5. Konkrétní technologická řešení Výhody Výkonnost a škálovatelnost: Distribuuje data mezi uzly (sharding). Umí přeuspořádávat data v případě nových uzlů, nebo ztrátě existujících. Má vlastní instanci cache. Robustnost: Mezi jednotlivými uzly je redundance dat, na základě těchto dat je možné obnovit vypadlý uzel. Jedná se o decentralizované řešení. Nevýhody Výkonnost a škálovatelnost: Přeuspořádávání hodnot stojí výkon všechny uzly. Konzistence: Nezná cizí klíče. Data nelze na úrovni dotazu spojovat (join). Konzistenci musí z velké části řešit aplikace. Ostatní: Z velké části by bylo nutné změnit způsob práce s daty systému Perun. Má příliš jednoduché filtrování na úrovni databázového dotazu. 5.1.4 Grafové databáze Neo4J V oblasti grafových databází se jedná o jedno z nejzajímavějších řešení. Zakládá se na získávání a ukládání dat na základě jejich vztahů (relací). Grafy obsahují uzly, ty jsou spojeny pomocí vztahů a jak vztahy tak uzly mají své vlastnosti. Používá lidsky čitelný jazyk pro dotazování. Je to silně distribuované řešení s podporou rychlého vzpamatování se z pádu některého z uzlů [29]. Výhody Výkonnost a škálovatelnost: Podporuje sekundární indexy, grafové algoritmy pro vyhledávání a škálování čtecích dotazů pomocí přidávání dalších uzlů. Robustnost: Umožňuje master-slave replikaci a automatické zotavení z pádu. Konzistence: Podporuje databázové transakce a cizí klíče. 39

5. Konkrétní technologická řešení Nevýhody Ostatní: Data je nutné navrhnout tak, aby využívala výhod grafových databází (správný způsob dotazování s využitím vztahů). Nevhodný dotaz je například průměrný plat všech zaměstnanců. Z velké části by bylo nutné změnit způsob práce s daty systému Perun. 5.1.5 Hybridní databáze OrientDB Jedná se primárně o grafovou databázi s podporou multi-master replikace a dělení dat mezi repliky (tzv. sharding). Zároveň je možné využít podporu dokumentové databáze. Podporuje SQL jako jeden z možných jazyků pro volání. Pomocí WAL 6 záznamů si udržuje stav jednotlivých uzlů a při pádu je schopna zajistit jejich rychlé znovunačtení [32]. Výhody Výkonnost a škálovatelnost: Obsahuje víceúrovňovou cache na straně jednotlivých databázových instancí. Podporuje i sekundární indexy. Dělí data mezi jednotlivé uzly (sharding). Robustnost: Podporuje master-master replikaci a automatické zotavení z pádu. Konzistence: Podporuje databázové transakce a cizích klíče. Ostatní: Podporuje ukládání dat formou grafů a dokumentů (přidány vztahy mezi dokumenty). Využívá jazyk SQL. Nevýhody Konzistence: Všechny servery jsou master, a tudíž může dojít k dočasné nekonzistenci, která se vyřeší nějakou automatickou strategií (viz. kapitola 4). Všechny uzly jsou eventuálně nekonzistentní. Ostatní: Správa databáze je složitá. Z velké části by bylo nutné změnit způsob práce s daty systému Perun a počítat s dočasnou nekonzistencí mezi jednotlivými uzly. 6. WAL write ahead operation log 40

5. Konkrétní technologická řešení ArangoDB Víceúčelová NoSQL databáze, která podporuje ukládání dat v podobě dokumentů, grafů a záznamů typu klíč-hodnota. Snaží se o možnost využívání veškerých NoSQL typů dat mezi sebou tak, aby bylo dosaženo co nejkomplexnějšího řešení [10]. Výhody Výkonnost a škálovatelnost: Distribuuje data mezi uzly (sharding). Podporuje sekundární indexy, velká část dat je ukládána do cache. Robustnost: Jedná se o asynchronní master-slave replikaci. Konzistence: Je možné volit úroveň konzistence (samozřejmě podle toho se liší i výkon). Ostatní: Jedná se o kombinace dokumentů, grafových vztahů a záznamů typu klíč-hodnota (snaha o kombinaci vlastností všech tří typů). Pro vyhledávání se používá jazyk AQL podobný jazyku SQL. Nevýhody Aerospike Konzistence: Nepodporuje cizí klíče. Data jsou kvůli asynchronní replikaci na slave serverech pouze eventuálně konzistentní. Ostatní: Z velké části by bylo nutné změnit způsob práce s daty systému Perun. Specifické NoSQL databázové řešení pro záznamy typu klíč-hodnota, které pracuje z velké části v operační paměti a snaží se využít výhod moderních technologií jako například SSD disků. Snaží se o precizní využití veškerého výkonu celého počítače (veškerých disků, procesorů, paměti atd.). Skládá se ze tří vrstev (klientská část pro aplikaci, samospravovací clusterová část, kde se řeší distribuované prostředí a optimalizovaná část s datovým skladištěm). Pro ideální vlastnosti je nutné použít doporučené hardwarové řešení s konkrétním souborovým systémem [9]. Výhody Výkonnost a škálovatelnost: Data jsou rozdělena mezi uzly a aktivně přeuspořádávána pro zvýšení výkonu. Podporuje sekundární indexy. 41

5. Konkrétní technologická řešení Robustnost: Všechny uzly jsou synchronně replikovány, data se kopírují mezi více uzly pro účely automatického zotavení z pádu. Jedná se o decentralizované řešení. Konzistence: Podporuje databázové transakce. Nevýhody Výkonnost a škálovatelnost: K dosažení nejlepších výsledků je nutné použít drahé technologické řešení (SSD disky apod.) spolu s vlastním souborovým systémem. Konzistence: Během redistribuce dat vzniká eventuální konzistence. Výraznou část konzistence musí řešit aplikace. Případná nekonzistence dat se řeší pomocí vybrané strategie. Nepodporuje cizí klíče. Ostatní: Finančně náročné řešení při úplnému nasazení. Z velké části by bylo nutné změnit způsob práce s daty systému Perun. 5.2 Cachování a in-memory databáze CSQL Cache Jedná se o open source výkonné řešení datové cache, které leží mezi aplikací a datovým úložištěm, a zajišťuje vysokou průchodnost pro aplikaci. CSQL využívá MMDB 7 pro cachování tabulek [21]. Výhody Výkonnost a škálovatelnost: Řešení zvyšuje rychlost čtení dat, která uloží do operační paměti. Robustnost: Selže-li aktuální databáze, lze ji automaticky přesměrovat na jinou databázi. Konzistence: Řešení využívá write-through přístup a zachovává konzistenci na úrovni samotné cache 1. Ostatní: Technologie je transparentní pro neřešené dotazy. Je možné cachovat jen parciální části tabulek. Podporuje PostgreSQL, Oracle i MySQL. 7. Main memory database relační in-memory databáze 42

5. Konkrétní technologická řešení Nevýhody Výkonnost a škálovatelnost: Řešení zpomaluje výkon zapisovacích dotazů. Veškeré zapisovací dotazy musí jit skrz tuto cache (omezuje případnou škálovatelnost). Konzistence: Některé klíčové vlastnosti mezi MMDB a využívánou databází se mohou mírně lišit. Ostatní: Tato technologie je dlouho neaktivní z pohledu vývoje. Memcached Jedná se o software, který aplikacím umožňuje ukládat libovolná data do paměti a potom je dále používat. Pokud dojde k přetečení paměti, záznamy se mažou podle nejstaršího časového razítka. Případně se dá nastavit expirace za určitý čas [14]. Výhody Výkonnost: Aplikace umožňuje ukládat vybraná data do operační paměti. Ostatní: Velmi jednoduché řešení práce s operační pamětí. Nevýhody Škálovatelnost/Robustnost/Konzistence: Neobsahuje žádnou další funkcionalitu pro podporu těchto vlastností. Ostatní: Bylo by nutné z velké části navrhnout práci s daty. Jsou definovány jen nástroje a několik příkazů. H2 Jednoduchá SQL databáze, která může běžet celá v paměti. Často se používá ve spoustě aplikací jako interní úložiště. V systému Perun se plánuje využítí této databáze za účelem testování kódu (dynamicky ji vytvářet pouze pro účely testů). Podporuje manuální zotavení z pádu, je kompatibilní s jinými databázemi (např. PostgreSQL, MySQL apod.) [2]. 43

5. Konkrétní technologická řešení Výhody Výkonnost a škálovatelnost: Databáze může běžet celá v operační paměti (in-memory). Podporuje sekundární indexy. Robustnost: Podporuje manuální zotavení z pádu. Konzistence: Konzistence je na úrovni relačních SQL databází (transakce, cizí klíče, unikátní klíče atd.). Ostatní: Je kompatibilní s dalšími databázemi (PostgreSQL, Oracle a další). Nevýhody Výkonnost a škálovatelnost: Se vzrůstajícím počtem tabulek klesá výkon databáze. Nepodporuje vícevláknové řešení (zatím je pouze ve fázi experimentu). Robustnost: Nepodporuje replikaci (zatím je ve fázi experimentů). Konzistence: Existuje zdokumentovaný problém s odolností dat při výpadku proudu krátce po skončení transakce. Potíž je v úmyslném nevyužívání synchronizace s diskem po každé transakci z důvodu rychlosti. MonetDB Jedná se o sloupcovou databázi, která ale svůj nejvyšší výkon dosahuje v případě, kdy je celá uložená v operační paměti, proto jsem ji zařadil spíše mezi in-memory databáze. Bohužel však sama o sobě nepodporuje škálovatelnost ani robustnost nad úroveň jedné instance [27]. Výhody Výkonnost: Celou databázi lze využívat v operační paměti s ukládáním mezistavů na disk. Podporuje sekundární indexy. Konzistence: Konzistence je na úrovni relačních SQL databází (transakce, cizí klíče, unikátní klíče atd.) 44

5. Konkrétní technologická řešení Nevýhody Škálovatelnost/Robustnost: Podporuje pouze jednu instance databáze (žádná replikace). Ostatní: Bylo by nutné změnit způsob práce s daty systému Perun. VoltDB Databáze, která běží v operační paměti s podporou jazyka SQL a transakcí. Je navržená, aby byla rychlejší než většina známých SQL databází. Mimo jiné zajišťuje vysokou škálovatelnost a dostupnost. Jejím cílem je zajistit vysokou propustnost dotazů [52]. Výhody Výkonnost a škálovatelnost: Databáze běží v operační paměťi a ukládá svůj stav na disk. Podporuje sekundární indexy. Rozděluje data mezi jednotlivé uzly. Robustnost: Jedná se o master-slave asynchronní replikaci. Konzistence: Podporuje databázové transakce. Ostatní: Podporuje jazyk SQL. Nevýhody Konzistence: Chybí podpora cizích a unikátních klíčů. Velkou část konzistence je nutné řešit na straně aplikace. Ostatní: Bylo by nutné zčásti změnit způsob práce s daty systému Perun. 5.3 Replikace relačních databází Pgpool-II Jedná se o databázový middleware mezi aplikací a databázovým serverem. Podporuje pouze PostgreSQL. Kromě jiného se může kombinovat s jinými technologiemi pro zvýšení účinnosti, například streamovací replikací přímo v implementaci PostgreSQL 9.0+ nebo Slony-I. Zároveň umožňuje použít mnoho módů replikace (master-slave, master-master) [33]. 45

5. Konkrétní technologická řešení Výhody Výkonnost a škálovatelnost: Umožňuje rozdělení zátěže na úrovni jednotlivých připojení (loadbalancing). Dobře škáluje čtecí dotazy. Robustnost: Má volitelnou úroveň replikace (master-slave, mastermaster). Podporuje automatické zotavení z pádu. Konzistence: Podporuje konzistenci na úrovni relačních databází (transakce, cizí klíče, unikátní klíče atd.) Ostatní: Podporuje databázi PostgreSQL nejnovějších verzí. Technologie neupravuje kód samotného PostgreSQL. Nevýhody Výkonnost a škálovatelnost: Řešení není vhodné pro aplikaci, která často zapisuje (zpomalení zapisovacích dotazů). Konzistence: Je nutné řešit některé příkazy na úrovni aplikace (například časová razítka) v případě použití master-master řešení. V masterslave řešení jsou slave servery pouze eventuálně konzistentní. Slony-I Je to master-slave řešení replikace PostgreSQL databáze. Jedná se o komunitou velmi oblíbené, ale na nastavení dosti složité řešení. Nejedná se ovšem o kompletní clusterové řešení a bylo by potřeba jej ještě obohatit o další funkce jako implementaci rozložení zátěže [40]. Výhody Výkonnost a škálovatelnost: Rozšiřováním uzlů je možné dobře škálovat čtecí dotazy. Robustnost: Jedná se o master-slave asynchronní replikaci. Podporuje automatické zotavení z pádu. Konzistence: Podporuje konzistenci na úrovni relačních databází (transakce, cizí klíče, unikátní klíče atd.) 46

5. Konkrétní technologická řešení Nevýhody Výkonnost a škálovatelnost: Nevhodné pro aplikaci, která často zapisuje (zpomalení zapisovacích dotazů). Počet rozšiřujících uzlů omezen na 20. Neumí automaticky rozkládat zátěž. Konzistence: Slave servery jsou jen eventuálně konzistentní. Ostatní: Nastavení je velmi složité. PostgreSQL streaming replikace Řešení slouží jako vestavěná replikace v databázi PostgreSQL verze 9.0 a vyšší. Umožňuje asynchronní replikaci master-slave za pomoci jednoduchého nastavení na úrovni jednotlivých databázových instancí. Od vyšší verze pak PostgreSQL podporuje i synchronní replikaci. PostgreSQL kromě toho nabízí i klasickou replikaci na základě logování do souboru, ale streamování umí udržet slave server mnohem rychleji v konzistentním stavu, proto zde zmíním hlavně tuto variantu [7]. Výhody Výkonnost a škálovatelnost: Dobře škáluje čtecí dotazy. Robustnost: Jedná se o master-slave replikaci. Podporuje i mastermaster ale omezeně. Podporuje manuální zotavení z pádu. Konzistence: I když je jen evenutálně konzistentní, synchronizace probíhá velmi rychle (řádově do sekundy). Nevýhody Výkonnost a škálovatelnost: Zpomaluje zapisovací dotazy. Nemá vlastní řešení rozložení zátěže. Konzistence: Slave server je pouze eventuálně konzistentní. MySQL master-slave replikace Svoje technologické řešení pro replikace má i databáze MySQL. V tomto případě je velmi podobné řešení PostgreSQL s jen pár malými rozdíly, které se týkají konkrétní implementace databáze. Složitější řešení pro MySQL například pro cluster již nejsou open source [30]. 47

5. Konkrétní technologická řešení Výhody Výkonnost a škálovatelnost: Dobře škáluje čtecí dotazy. Robustnost: Jedná se o master-slave asynchronní replikace. Konzistence: Konzistence je na úrovni relačních databází. Nevýhody Výkonnost a škálovatelnost: Zpomaluje zapisovací dotazy. Nemá vlastní řešení rozložení zátěže. Robustnost: Nepodporuje zotavení z pádu. Ostatní: Bylo by nutné vyřešit některé rozdíly mezi PostgreSQL a MySQL (například MySQL při porovnání dvou textů nevidí rozdíl mezi malými a velkými pismeny). Postgres-XL Jedná se o technologii databázového clusteru pro škálování PostgreSQL databáze. Vychází z myšlenek technologie Postgres-XC 8. Projekt je nový a drží se aktuálních verzí databáze PostgreSQL. Umožňuje migrovat z PostgreSQL na Postgres-XL [49][50]. Výhody Výkonnost a škálovatelnost: Data lze distribuovat mezi všechny uzly a tím zvýšit výkon. Robustnost: Replikace je na úrovni master-master. Data je možné nejen distribuovat, ale i replikovat, je-li cílem konzistence. Podporuje manuální zotavení z pádu uzlu. Konzistence: Z velké části konzistence leží na úrovni relačních SQL databází. 8. Postgres-XC http://postgres-xc.sourceforge.net/docs/1_1/intro-whatis.html 48

5. Konkrétní technologická řešení Nevýhody Konzistence: Cizí a unikátní klíče musí být součástí distribučního klíče (klíč, podle kterého se data rozdělují mezi uzly, často se jedná o primární klíč). Ostatní: Po implementaci jsem zjistil, že nepodporuje vnořené transakce, které jsou pro systém Perun důležité, a to ani na úrovni ukládacích bodů (tzv. savepoint). 5.4 Srovnání technologií V kapitole 5 jsem nastínil několik konkrétních řešení a některé jejich výhody a nevýhody. Aby bylo možné jednotlivé technologie lépe porovnat, vytvořil jsem tabulku se všemi sledovanými vlastnostmi a technologiemi. Tato tabulka TABULKA01 je součástí přílohy A. Na základě vlastností z kapitoly 3 (škálovatelnost a výkonnost hodnotím jako jednu vlastnost) jsem vytvořil tabulku 5.1, kde jednotlivé technologie hodnotím. K těmto vlastnostem jsem přidal ještě zmíněnou úroveň konzistence na straně DB a jednoduchost implementace do systému Perun. Hodnocení provádím pomocí známek 1 až 3, kde známka 1 znamená "zcela vyhovuje v rámci vlastnosti", známka 2 znamená "vyhovuje s výhradami"a známka 3 znamená "spíše nevyhovuje". Jméno technologie Tabulka 5.1: Hodnocení jednotlivých technologií Robustnost Škálovatelnost a výkonnost Konzistence Složitost implementace HBase 1 1 3 3 8 Cassandra 1 1 3 3 8 MongoDB 2 1 3 3 9 CouchDB 1 1 3 3 8 BaseX 3 2 3 3 11 Redis 2 2 2 3 9 Oracle Barkeley 2 2 2 3 9 DB Voldemort 1 1 3 3 8 Neo4J 1 1 2 3 7 Celkové hodnocení 49

5. Konkrétní technologická řešení OrientDB 1 1 2 3 7 ArangoDB 2 2 2 3 9 Aerosplike 1 2 2 3 8 CSQL 3 2 2 1 8 Memcached 3 2 3 2 10 H2 3 2 2 2 9 MonetDB 3 3 1 2 9 VoltDB 2 1 2 2 7 Pgpool-II 1 2 1 2 6 Slony-I 2 2 1 2 7 PSQL streaming 2 2 1 1 6 MySQL Replication 2 2 1 2 7 Postgres-XL 1 1 1 2 5 streaming+pgpool- II 1 2 1 2 6 5.5 Výběr technologie Na základě výsledku tabulky 5.1 vychází jako nejlepší řešení ta, která pouze modifikují existující datové skladiště systému Perun o další úroveň. Rozhodl jsem se tedy vydat touto cestou a zvolil si k implementaci technologii Postgres- XL. 50

6 Hodnocení vybraných technologií Na základě výsledků z kapitoly 5 jsem si k nasazení vybral technologii Postgres-XL. Tuto technologii jsem dále nasadil a postup nasazení detailně popsal. Po nasazení a po prvních testech jsem zjistil, že Postgres-XL v aktuální verzi nepodporuje některé vlastnosti technologie PostgreSQL, které jsou pro potřeby systému Perun klíčové (přesnější popis později v kapitole 6). I přesto jsem postup nasazení popsal, neboť se může jednat o vhodné řešení v případě, že budou některé vlastnosti v budoucnu do této technologie doimplementovány. Po diskuzi s týmem vývojářů jsem se dozvěděl, že prozatím tyto změny nemají prioritu. Jako náhradníka první neúspěšné technologie jsem vybral Pgpool-II v kombinaci s master-slave streamovací replikací PostgreSQL, neboť dosáhla stejného bodového ohodnocení. Opět jsem provedl nasazení a detailně jej popsal. Po stránce zachovaných vlastností serveru PostgreSQL jsem zde uspěl, ačkoliv výkonnost řešení vyšla ve většině provedených testů jako horší než při použití pouze jedné instance databáze. Po sérii optimalizací jsem zjistil, kde leží pravděpodobný problém a popsal ho, není však řešitelný bez změny implementace technologie Pgpool-II. I v tomto případě tedy záleží na dalších úpravách ze strany vývojářů této technologie. Vybral jsem tedy některé fungující části z předchozích dvou řešení a přidal třetí návrh. Tomuto návrhu se věnuji pouze okrajově a spíše se jedná o potenciální možnost využití s některými omezenými vlastnostmi. Účelem je nabídnout jednoduše implementovatelné rozšíření stávajícího řešení s podporou škálovatelnosti a částečně i robustnosti. Použitelnost řešení a rychlost jednotlivých instancí lze pak odvodit na základě výsledků měření předchozí technologie Pgpool-II. 6.1 Postgres-XL 6.1.1 Návrh Nejprve je potřeba navrhnout prostředí, ve kterém bude cluster Postgres-XL implementován. Samozřejmě, že je možné vše nasadit na jednom stroji, ale pak by některé klíčové vlastnosti mohly být zkreslené (hlavně vzhledem k výkonu stroje). Na obrázku 6.1 je vidět základní rozdělení komponent, které jsou pro účely technologie nutné. Základem jsou jednotlivé uzly (Data Nodes), které jsou v podstatě jen databázovými servery s daty. Dále pak části určené pro komunikaci s aplikacemi a provádění dotazů tzv. koordinátoři (Coordiantors). Koordinátoři 51

6. Hodnocení vybraných technologií komunikují s datovými uzly a s globálním transakčním manažerem (Global Transaction Manager) a plánují jednotlivé dotazy. Globální transakční manažer se stará o zachování konzistence transakcí v rámci celého řešení a je možné vytvořit jeho zálohu pro účely odstranění slabého článku řešení. Aplikaci nezáleží na tom, kterého koordinátora se doptává, proto je možné nad jednotlivými koordinátory vytvořit rozložení zátěže bez nutnosti definovat typ dotazů (Load Balancer). Obrázek 6.1: Pohled na jednotlivé komponenty Postgres-XL clusteru [5]. Rozložení zátěže jsem v tomto případě přeskočil, takže zbylo rozdělit role koordinátorů a transakčního manažera mezi jednotlivá testovací zařízení. Pro tyto účely jsem si vytvořil tři stejně výkonné virtuální stroje (1 procesor, 1GB operační paměti a 10GB místa na disku, systém Debian 7.7 1 ). Na první z nich jsem navrhl umístit samostatně globální transakční manažer, neboť se jedná o důležitou komponentu. Na zbylé dva uzly jsem navrhl umístit po jednom uzlu a jednom koordinátoru (zlepší se tak výkon práce s daty konkrétního uzlu při komunikaci s přiřazeným koordinátorem). K lepšímu výkonu slouží i proxy globálního transakčního manažeru, která zvyšuje výkon celého řešení zvláště v případě pomalé síťové linky. Transakční manažer tak může komunikovat s jednotlivými proxy instancemi a koordinátor má v tomto 1. Debian 7.7 http://www.debian.cz/ 52

6. Hodnocení vybraných technologií případě svůj transakční manažer lokálně na stejném zařízení. Výsledek mého návrhu je možné vidět na obrázku 6.2. Nastíněný vztah mezi datovými uzly má přiblížit potřebu jednotlivých uzlů vzájemně o sobě vědět. Koordinátoři a datové uzly si informace o svých sousedech udržuji v systémové tabulce pgxc_nodes. Obrázek 6.2: Návrh použití technologie Postgres-XL pro účely testování. 6.1.2 Instalace a prerekvizity K instalaci clusteru Postgres-XL je nutné stáhnout z oficiálních webových stránek 2 nejnovější balíček Postgres-XL pro daný systém (v mém případě ve verzi 9.2). Součástí balíčku je upravená verze běžného PostgreSQL serveru i klienta obohacená o rozšíření technologie Postgres-XL. Je potřeba nainstalovat několik prerekvizit, přičemž některé je možné nepoužívat, ale je podle toho potřeba nastavit konfiguraci tohoto balíčku pro příkaz make. Seznam prerekvizit: GNU Library readline: knihovna pro rozšíření práce s příkazovou řádkou (např. přidává historii příkazů) 2. Postgres-XL oficiální stránky http://www.postgres-xl.org/ 53

6. Hodnocení vybraných technologií ZLIB1G: knihovna pro implementaci kompresního algoritmu deflate 3 FLEX: generátor lexikálních analyzátorů BISON: generátor parserů pro LALR(1) 4 JADE: implementace stylového jazyka DSSSL Po instalaci prerekvizit lze spustit příkaz configure, následně make a make install, je-li prováděna výchozí instalace z balíčku. Pro moji verzi jsem instaloval právě výchozí nastavení, proto v konfiguraci nejsou žádné další parametry. Nejnovější balíček, který jsem k instalaci použil, byl v té době chybný a během instalace vykazoval chybu při generování dokumentace, která zabránila dokončení instalace. Musel jsem tuto část ručně odstranit a provést instalaci bez ní, podle vývojářů by však již tato chyba měla být odstraněna. Instalaci je potřeba provést na všech zainteresovaných uzlech. Výchozí cesta k binárním souborům je pak /usr/local/pgsql/bin/ a doporučuji si na ni udělat systémový odkaz kvůli množství použití těchto skriptů v další fázi spouštění clusteru. 6.1.3 Inicializace Prvním krokem je pro každý uzel, koordinátor a transakční manažer vytvořit vlastní adresář, kde budou uložena potřebná data a zároveň je nutné, aby uživatel spouštějící inicializační skripty měl k těmto adresářům plný přístup (zápis i čtení). Datové uzly mají v inicializaci přednost před ostatními komponentami. První část se provádí příkazem initdb s několika přepínači. Přepínačem se zde myslí parametr volání skriptu případně s nějakou očekávanou hodnotou. Použitým přepínačem je -D s cestou k adresáři dané komponenty. Dále následuje přepínač --nodename s vlastním pojmenováním komponenty. Příkladem: initdb -D /home/perun/datanode01 --nodename datanode01 Tento příkaz se bez rozšiřujícího přepínače s jménem uzlu běžně používá i v případě PostgreSQL pro vytvoření základní adresářové struktury nového serveru. Pro účely mého řešení jsem provedl inicializaci zvlášť pro oba datové uzly). Výsledkem je připravená adresářová struktura, nad kterou ovšem zatím neběží žádné řešení, a tudíž je nejprve nutné uzly spustit (o spouštění komponent hovořím v kapitole po inicializaci). 3. deflate kompresní algoritmus použitý v některých nástrojích 4. Look-Ahead Left to Right typ gramatiky 54

6. Hodnocení vybraných technologií Po datových uzlech je potřeba inicializovat koordinátory. Postup je úplně stejný jako v případě uzlů, proto přidávám jen příklad: initdb -D /home/perun/coordinator01 --nodename coordinator01 Jako poslední pak inicializuji globální transakční manažer a jeho jednotlivé proxy. V tomto případě se příkaz liší. K inicializaci transakčního manažeru se používá příkazu initgm s přepínačem -D, který i zde definuje cestu k adresářové struktuře. Nezbytný je i přepínač -Z, který specifikuje typ transakčního manažeru (normální, proxy apod.). Příklad inicializace transakčního manažeru a jeho jedné proxy: initgtm -D /home/perun/gtm -Z gtm initgtm -D /home/perun/gtm-proxy -Z gtm-proxy 6.1.4 Nastavení konfiguračních souborů Postgres-XL používá až na výjimky stejné konfigurační soubory jako Postgre- SQL, pouze rozšířené o některá další nastavení. Standardně se jedná o soubory postgres.conf s veškerými nastaveními jednotlivých uzlů a pg_hba.conf s nastavením přístupových práv k těmto uzlům. Jedinými výjimkami od standardu je soubor gtm.conf, který slouží k nastavení vlastností transakčního manažeru a také soubor gtm_proxy.conf pro nastavení vlastností jednotlivých proxy. Pro zjednodušení začnu s popisem nastavení od konce, neboť transakční manažer lze nastavit velmi jednoduše. Soubor gtm.conf je k nalezení přímo v adresáři, kam byl transakční manažer inicializován. Postačí nastavit následující parametry: nodename: určuje pojmenování uzlu (takto se bude v rámci clusteru jmenovat např. GTM) listen_addresses: nastavuje, ze kterých adres bude manažer přijímat požadavky, ostatní požadavky zahazuje rovnou (pro zjednodušení lze nastavit hvězdičku, což znamená, že přijímá požadavky z libovolné adresy) port: definuje na kterém portu bude manažer poslouchat (například 6666) V případě jednotlivých proxy je pak nastavení téměř totožné s jediným rozdílem, musí být definovaná správná cesta k hlavnímu transakčnímu manažeru. Příklad: 55

6. Hodnocení vybraných technologií gtm_host: IP adresa hlavního transakčního manažeru (například 127.0.0.1 v případě lokálního volání) gtm_port: port na kterém na dané adrese transakční manažer poslouchá (například dle hodnoty výše 6666) Dále popíši nastavení datových uzlů a koordinátorů. V tomto případě v adresářích jednotlivých uzlů nastavím pro konfigurační soubor postgresql.conf následující: listen_addresses: stejně jako v případě transakčního manažeru definuje, ze kterých adres bude uzel přijímat požadavky port: definice portu, na kterém uzel poslouchá max_connections: maximum naráz otevřených připojení k uzlu (například 100) pgxc_node_name: jméno uzlu obdobně jako v případě transakčního manažeru (například coordinator01 nebo datanode01) gtm_host: adresa, na které poslouchá transakční manažer nebo přidělená proxy (pro proxy v tomto případě localhost) gtm_port: port, na kterém transakční manažer nebo proxy poslouchá (pro proxy například 6666) Pro koordinátory a datové uzly je také potřeba nastavit přístupová práva v souboru pg_hba.conf. Tvar jednotlivých záznamů je typ jméno_databáze jméno_uživatele adresa metoda_autentizace, kde: typ: definuje zda jde o lokální přístup nebo přístup zvenčí sítě (hodnoty local nebo host) jméno_databáze: jméno databáze, ke které chci mít přístup (hodnoty all pro všechny nebo např. perun pro konkrétní) jméno_uživatele: jméno uživatele, pod kterým chci mít k dané databázi přístup (hodnoty např. postgres nebo perun) adresa: IP adresa včetně zkráceného tvaru masky podsítě zvlášť pro IPv4 a IPv6 (hodnoty např. 127.0.0.1/32 nebo ::1/128) metoda: bez oveření, ověření heslem, na základě identity odeslané ze stroje apod. (hodnoty například trust, md5 nebo ident) 56

6. Hodnocení vybraných technologií příklad konkrétního nastavení: local perun perun 127.0.0.1/32 trust dovoluji přístup uživatele perun k databázi perun z lokálního zařízení bez ověření V rámci pravidel by mělo platit, že uzly dovolují přístup všem koordinátorům a ostatním uzlům, koordinátoři pak ostatním koordinátorům a aplikacím. 6.1.5 Spuštění Po správném nastavení je možné provést spuštění jednotlivých instancí. Obecný doporučený postup je spustit nejdřív transakčního manažera, poté datové uzly a nakonec koordinátory. Opačný postup by pak měl být dodržen v případě vypínání, aby nedošlo ke zbytečným chybám. Transakční manažer a jednotlivé proxy spustím příkazem gtm a gtm_proxy s přepínačem -D a cestou k adresáři s inicializovanými daty. gtm -D /home/postgres/gtm gtm_proxy -D /home/postgres/gtm-proxy Datové uzly a koordinátory se spouští příkazem postgres s přepínači --datanode nebo --coordinator podle typu a přepínačem -D s cestou k adresáři s inicializací. postgres --datanode -D /home/perun/datanode01 postgres --coordinator -D /home/perun/coordinator01 6.1.6 Potíže s alokací sdílené paměti Při prvním pokusu o spuštění mi jednotlivé uzly zahlásily chybu týkající se malé velikostí sdílené paměti v systému. Toto je velmi systémově specifická věc, ale je možné ji přenastavit tak, aby odpovídala očekávanému minimu. V mém případě na systému Debian pomohlo nastavit systémovou proměnou shmall a shmmax na vyšší hodnoty. 6.1.7 Lokální nastavení konfiguračních tabulek Kromě nastavení konfiguračních souborů je ještě potřeba zajistit, aby o sobě jednotlivé uzly věděly. Toho lze docílit tak, že se na každém uzlu (koordinátoru i datovém uzlu) nastaví do tabulky pgxc_node potřebné informace o ostatních 57

6. Hodnocení vybraných technologií uzlech. Jednou z možností, jak toto provést je využít příkazu psql s přepínačem -c následovaným konkrétním dotazem, který informace do tabulky nastaví. Kromě toho je ještě nutné dalšími přepínači nastavit cestu ke konkrétnímu uzlu. Nejpoužívanější jsou přepínače -h s adresou stroje, -p s portem, na kterém uzel poslouchá, a -U se jménem uživatele, pod kterým se bude příkaz provádět. psql -c "CREATE NODE datanode01 WITH (TYPE= datanode, PORT= 15432, HOST= localhost )"-U postgres -p 15431 -h localhost psql -c "CREATE NODE coordinator01 WITH (TYPE= coordinator, PORT= 5432, HOST= localhost )"-U postgres -p 15431 -h localhost 6.1.8 Přidávání a odstraňování koordinátorů a datových uzlů Celý systém je velmi dynamický. Dovoluje přidávat nové uzly za chodu ať už se jedná o koordinátory nebo datové uzly. V obou případech je nutné mít jeden stejný typ uzlu k dispozici pro účely získání aktuálních dat. V případě koordinátoru tak dojde k dočasnému znepřístupnění jiného koordinátora a v případě datového uzlu jiného datového uzlu. Proces je ve většině případů rychlý, ale záleží na velikosti databáze. Používá se příkazu pg_dumpall, který předpřipraví veškerá data, která byla k dispozici na daném uzlu. Pak se tato data zkopírují do adresáře s novým uzlem a po zapnutí se ještě přidají informace pro ostatní uzly do tabulky pgxc_node. 6.1.9 Import dat a definice tabulek Při vytváření tabulek je potřeba definovat, jakým způsobem se budou záznamy v tabulce distribuovat. V podstatě existují dvě možnosti a to replikací nebo distribucí skrze distribuční klíč. V případě replikace dojde k duplikování tabulky na všech uzlech. V takovém případě je každý uzel schopen zodpovědět dotaz do dané tabulky samostatně bez pomoci ostatních a při výpadku některého z uzlů mohou ostatní tato data plně zastoupit. V případě distribučního klíče se na základě zvoleného sloupce (v ideálním případě primárního klíče) provádí rozdělení jednotlivých záznamů mezi uzly. Každý uzel pak nese část záznamů a koordinátoři se starají o to, aby se v případě dotazu, který zahrnuje data z více než jednoho uzlu, tato data správně sesbírala. Výhodou je, že toto řešení by mělo zvýšit výkon hlavně čtecích dotazů, neboť si databáze mezi sebe rozdělí zátěž a každá pošle jen část informací. Samozřejmě záleží na množství a náročnosti dotazu, neboť je tu daň za distribuci (je nutné všechny servery kontaktovat, data z nich spojit 58

6. Hodnocení vybraných technologií a pak teprve předat aplikaci). Pro ukázku uvádím příklad vytváření tabulky s distribuovaným klíčem a s replikací: CREATE TABLE test (int id) DISTRIBUTE BY HASH(id); CREATE TABLE test(int id) DISTRIBUTE BY REPLICATION; Samozřejmě v případě distribuce znamená pád některého z uzlů ztrátu dat, která měl k dispozici. V takovém případě je potřeba zvažovat pro každý uzel jeho zálohu (slave server), který si drží potřebná data nebo veškerá důležitá data replikovat. 6.1.10 Zjištěné problémy Jak jsem již napsal dříve v této kapitole, krátce po naplnění tabulek produkčními daty a při prvním testování jsem zjistil několik potíží, které v konečném důsledku zabránily dalšímu testování této technologie. Prvním problémem byla nemožnost použít složitější konzistenční ochrany v případě, že jsou data distribuována. Pokud mám například nastavené požadavky na unikátnost jednoho záznamu jinak než podle primárního klíče (například na unikátnost nějakého obsahu v hodnotě), nemůže mi toto řešení zaručit, že budou uložená data opravdu unikátní. Každá databáze má svůj obsah a v rámci něho bude hodnota unikátní, ale když se rozdělí mezi dva různé datové uzly, nezíská databáze žádnou informaci o tom, že se stalo něco nepovoleného. Tomu lze předejít tak, že se nepoužívá distribuování tabulek, u kterých je taková konzistence nutná. Případně lze tuto část konzistence přemístit na úroveň aplikace. Druhým problémem byla nedostatečná podpora rekurzivních dotazů. V systému Perun se používá rekurzivních dotazů k výpočtu některých hodnot. To by bylo možné v rámci aplikace opět přepracovat, takže se nejedná o problém, který by bránil nasazení. Tím zmíněným problémem byla absence ukládácích bodů (SAVEPOINT), které PostgreSQL využívá k provádění vnořených transakcí (tzv. nested transakcí). Tento proces je silně zakořeněn v momentálním fungování systému Perun a jeho změna by znamenala přepsání většiny aplikačního kódu. Ačkoliv je v dokumentaci napsáno, že tato funkce prozatím není implementována, po diskuzi s vývojáři Posgres-XL jsem se dozvěděl, že v krátkém horizontu se nasazení neplánuje, neboť má jen malou důležitost a vyžadovalo by investice do projektu. 59

6. Hodnocení vybraných technologií 6.1.11 Shrnutí Po zkušenostech s touto technologií mohu říci, že je velmi slibná. Dokumentace je zde objemná a řeší každý rozdíl mezi Postgres-XL a PostgreSQL. Bohužel jsem nenašel žádný výčet neimplementovaných částí, a tak jsem se některé informace dozvěděl až po nasazení a pečlivějším hledání. Co se samotného použití týče, byl jsem velmi mile překvapen tím, že aplikace v podstatě není schopna poznat rozdíl mezi přístupem k jedné databázi a přístupem k Postgres-XL. Stejně tak proces nastavení je v tomto případě dobře zdokumentován a jednoduše opakovatelný. Jako výhodu bych určitě zopakoval možnost distribuovat hodnoty mezi uzly a tím zvýšit výkon celého řešení, zároveň možnost určovat granularitu distribuce na úrovni tabulek, ne pouze jednotlivých databází. V případě použití veškerých vlastností pro získání vysoké dostupnosti je toto řešení velmi odolné proti výpadkům jednoho uzlu. Jako nevýhodu bych podotkl nutnost využívat pozměněné verze Postgre- SQL, takže v případě ukončení práce na projektu může dojít k zestárnutí technologie a problémům s údržbou nebo aktualizací. Zároveň je tu nutnost mnoha redundantních uzlů pro zajištění vysoké dostupnosti. V případě, že dojde k implementaci chybějících vlastností bych tuto technologii doporučil k dalšímu otestování z hlediska výkonu a podle výsledků pak rozhodl o jejím případném použití. 6.2 Pgpool-II a PostgreSQL streamovací replikace 6.2.1 Návrh Obdobně jako vpřípadě technologie Postgres-XL je i zde nejprve potřeba popsat nutné požadavky pro užívání. Ačkoliv má Pgpool-II hned několik módů, dle kterých může být celé nastavení provedeno, pro potřeby systému Perun v tomto případě nejlépe vyhovuje master-slave replikační mód využívající streamovací technologii PostgreSQL. Jako základ celé technologie je nutné mít alespoň jeden server v roli master a libovolný počet serverů v roli slave (v ideálním případě více než 1). V tomto případě není potřeba mít speciální upravenou verzi těchto serverů, a proto postačí dodržet podporovanou verzi vůči serveru Pgpool-II. Po několika testech mi jako nejideálnější prostředí pro účely měření přišlo oddělení serveru Pgpool-II od ostatních komponent z důvodu potřeby netriviálního výkonu stroje pro jeho fungování. Zároveň jsem oddělil i klientskou část na separátní stroje a výsledné prostředí je možné vidět na obrázku 6.3. Z pohledu výkonu jednotlivých strojů jsem uzel 1 s Pgpool-II serverem 60

6. Hodnocení vybraných technologií Obrázek 6.3: Návrh na použití technologie Pgpool-II v kombinaci s master-slave PostgreSQL streamovací replikací. připravil pro velkou zátěž (8CPU, 8GB RAM, 20GB disk), uzly 2 a 3 pro vyšší zátěž (4CPU, 4GB RAM, 10GB disk) a stejným výkonem jako uzly 2 a 3 jsem obohatil uzel se samostatnou PostgreSQL databází. Tu v testech používám jako poměrové řešení (simuluje momentální databázi systému Perun). Poslední uzel 4 jsem mírně výkonnostně poddimenzoval, abych tak mohl nasimulovat rozdělení zátěže na základě různé váhy jednotlivých uzlů. Co se klientských zařízení týče, musel jsem počítat s dostatečně výkonným řešením, neboť při velkém množství přenášených dat může být klient silně zatížený a zkreslovat tak výsledky testů. V tomto případě jsem si připravil 10 klientských stanic s totožným nastavením (4CPU, 3GB RAM, 10GB disk). Na všechny zmíněné virtuální stroje (klientské i provozní) jsem nainstaloval 61

6. Hodnocení vybraných technologií systém Debian 7.7 stejně jako v případě Postgres-XL. Replikace mezi koncovými uzly master a slave probíhá tak, že si master ukládá pro každou akci WAL záznam a jednotlivé slave servery z něho čtou a průběžně si doplňují svoje záznamy. Streamovací replikace je velmi rychlý proces, který bez výpadků mezi servery zajistí aktuálnost dat na slave serverech řádově do jedné sekundy. Ačkoliv se synchronizace děje periodicky, může ji vyvolat například korektně potvrzená transakce (commit). Během této doby jsou data na slave serverech pouze eventuálně konzistentní (může se stát, že v jednu chvíli vrátí na stejný dotaz master i slave server různou odpověď). 6.2.2 Instalace a prerekvizity Oproti Postgres-XL je zde daleko menší množství prerekvizit a až na pár výjimek postačí mít přístup k aktuálním instalacím PostgreSQL. V případě systému Debian 7.7 jsem se setkal s tím, že neexistuje aktuální verze Postgre- SQL vyšší než 9.1 v oficiálních repozitářích. Jelikož stabilní verze Pgpool-II podporuje PostgreSQL od verze 9.2, byl jsem nucen přidat ručně repozitář, který tyto verze PostgreSQL obsahoval. deb http://apt.postgresql.org/pub/repos/apt/ squeeze-pgdg main Ve většině novějších Linuxových distribucí tento problém nehrozí. V případě, že je tedy aktuální verze PostgreSQL k dispozici, je nutné nejprve zvolit verzi Pgpool-II. V mém případě jsem zvolil nejaktuálnější stabilní verzi 3.4.0 s podporou pro PostgreSQL server ve verzi 9.3. Jako prerekvizity tedy uvádím: postgresql-9.3: serverová verze se skripty pro databázi PostgreSQL postgresql-client-9.3: klientská část (často bývá součástí serverové) postgresql-server-dev-9.3: developerský kit pro vývoj a instalaci některých složitějších nastavení a funkcí pro PostgreSQL (Pgpool-II přidává vlastní funkce pro účely vzpamatování se uzlů z pádu a přidávání uzlů za chodu clusteru) libpcp3-dev: přidává některé skripty nutné například pro obnovování uzlů a přidávání nových uzlů Po instalaci veškerých prerekvizit je potřeba nainstalovat Pgpool-II z oficiálního zdroje. Pro tyto účely jsem využil ruční instalaci ze zdrojového balíčku. 62

6. Hodnocení vybraných technologií Tu lze provést obdobně jako v případě Postgres-XL kombinací příkazů configure, make a make install. V základním nastavení je nutné toto provést pod uživatelem s dostatečnými právy (v případě systému Debian7 pod uživatelem root) nebo změnit cesty definované v konfiguraci tak, aby k zápisu docházelo tam, kde má daný uživatel právo na zápis. 6.2.3 Inicializace V rámci inicializace je nutné připravit všechny servery, které se budou dále využívat. V mém případě se jedná o inicializaci adresáře s daty pro master server a oba slave servery. Na každém ze zmíněných strojů je potřeba pod uživatelem postgres (tento účet jsem vybral pro účely zjednodušení nastavení práv) vytvořit iniciální adresář s potřebnými daty a konfiguračními soubory. K inicializaci databázového serveru se používá opět příkaz initdb s přepínačem -D, za kterým následuje cesta k vybranému adresáři. Adresář musí v momentě inicializace existovat a uživatel spouštějící inicializaci do něj musí mít právo zápisu. Příklad inicializace: initdb -D /home/postgres/data Samotný Pgpool-II server žádnou inicializaci nepotřebuje, neboť neobsahuje žádná data. Je zde pouze potřeba nastavit několik konfiguračních souborů, které pak slouží k definici vlastností při spuštění. 6.2.4 Nastavení konfiguračních souborů Jako první volím nastavení jednotlivých PostgreSQL serverů, neboť v tomto případě je to jednodušší část. Opět se jedná o dva důležité konfigurační soubory postgresql.conf a pg_hba.conf uvnitř jednotlivých adresářů, kde byly servery inicializovány. V případě konfiguračního souboru postgresql.conf postačí nastavit na všech serverech následující hodnoty: listen_addresses: definice, ze kterých adres bude server přijímat požadavky port: port, na kterém bude server poslouchat požadavky hot_standby: je-li nastaveno jako on, dovoluje přijímat čtecí dotazy i uprostřed procesu oživování nebo přidávání jiného uzlu (zálohování apod.) 63

6. Hodnocení vybraných technologií max_wal_senders: jedná se o číslo (například 4), které v případě, že je server master, určuje maximální počet slave serverů, které od něj naráz mohou přijmat synchronizační data (vhodné nastavit na všech uzlech, aby bylo možné v případě pádu master serveru provést povýšení některého ze slave na nového mastera) max_connections: maximální počet připojení, které server dokáže naráz obsloužit (výchozí hodnota je 100) V souboru pg_hba.conf je potřeba nastavit práva přístupu k jednotlivým uzlům. Tvar zůstává stejný jako v nastavení v kapitole 6.1.4, je potřeba rozlišovat lokální a veřejnou síť a navíc ještě přidat řádek s nastavením replikace. Ten říká, jakému uživateli z jaké adresy dovoluje provádět replikaci dat. Příklad: host replication postgres 192.168.1.2/32 trust V tomto příkladě je dovoleno z adresy 192.168.1.2 s maskou podsítě 255.255.255.0 replikovat veškerá data pod uživatelem postgres. V rámci této adresy není po uživateli vyžadována žádná další autentizace. Bez tohoto nastavení by jednotlivé slave servery nemohly provádět streamovací replikaci dat z master serveru. Druhou část nastavení tvoří konfigurační soubory Pgpool-II serveru. Jedná se o soubory pgpool.conf, pool_hba.conf a pcp.conf. Výchozí varianty těchto souborů je možné najít v instalačním balíčku v adresáři src/samples/. Doporučený postup je vytvořit si kopie těchto souborů a používat ty. Soubor pcp.conf slouží k definování uživatelského jména a hesla, pod kterým bude možné kontaktovat server Pgpool-II pro přístup k administrátorským nastavením (spuštění obnovovacích procesů, vypnutí konkrétního uzlu apod.). Vše je ve tvaru UZIVATEL:MD5HESLO a tedy již v zašifrované formě. K zašifrování hesla lze použít libovolný nástroj k tomuto účelu určený. Příklad: postgres:e8a48653851e28c69 Soubor pool_hba.conf je v tomto případě stejný jako pg_hba.conf a slouží k nastavení přístupových práv k serveru Pgpool-II. Nastavení je stejné jako v předchozích zněních a není potřeba žádného speciálního tvaru. Nejnáročnějším na nastavení je soubor pgpool.conf, ve kterém jsou všechny potřebné definice pro běh celého clusteru. Pro lepší přehlednost tato nastavení rozdělím na jednotlivé částí. První část definuje základní vlastnosti obdobně jako v případě serverů PostgreSQL. 64

6. Hodnocení vybraných technologií listen_addresses: již několikrát zmíněné nastavení pro výběr adres, ze kterých bude server číst příkazy port: na tomto portu bude server poslouchat pcp_listen_addresses: obdobně jako v případě listen_addresses s tím rozdílem, že se jedná o přístup k administrátorskému rozhraní pcp_port: stejně jako port, pouze pro administrátorské rozhraní Druhá část se týká nastavení jednotlivých uzlů, které bude Pgpool-II řídit a kterých se bude doptávat na uživatelské dotazy. Zde záleží na zvoleném módu (master-slave, master-master a jiné), který bude následně vybrán. V případě módu master-slave je první uzel s označením 0 automaticky považován za master a ostatní pak za slave servery. Pro každý z nich je pak nutné nastavit několik vlastností. Za X v parametrech nahrazuji číslo uzlu, které musí být unikátní. backend_hostnamex: adresa, na které poslouchá daný PostgreSQL server backend_portx: port, na kterém poslouchá daný PostgreSQL server backend_weightx: váha daného serveru v podobě čísla (vyšší číslo znamená vyšší váha), pro účely testování jsem nastavil hodnotu 2 pro master a první slave, hodnotu 1 pak pro druhý výkonnostně slabší slave backend_data_directoryx: adresář s daty daného serveru, v tomto adresáři by se měly nacházet všechny vzdáleně spouštěné skripty (například skript pro obnovu uzlu a jiné), například /home/postgres/data backend_flagx: speciální označení uzlu, lze tak říci např. zda daný uzel bude v pádu master serveru vhodným kandidátem za jeho náhradu (hodnota ALLOW_TO_FAILOVER") Další nastavení se týká množství spojení, které je schopen Pgpool-II server obsluhovat zaráz. Zatímco v případě PostgreSQL existovala jedna hodnota definující maximální počet spojení, zde jsou pro tyto účely hodnoty dvě. num_init_children: maximální počet souběžných množin spojení, každá množina obsahuje několik spojení, které je možné využívat několikrát a nedochází k jejich zavření dokud to není vynuceno (výchozí nastavení je 32) 65

6. Hodnocení vybraných technologií max_pool: maximální počet spojení v rámci jedné množiny (výchozí hodnota je 4) Pro zjednodušení má Pgpool-II server k dispozici právě num_init_children * max_pool spojení. Ve výchozím nastavení tedy 128. Pro tyto spojení navíc systém musí mít dostatek paměti, jinak start serveru skončí s chybou. Velmi důležitou částí je volba módu replikace. V tomto případě popisuji mód master-slave a nutná nastavení. master_slave_mode: pro použití master-slave módu je nutné mít tento parametr nastavený na hodnotu on master_slave_sub_mode: definuje typ technologie použité k replikaci v režimu master-slave (lze nastavit buď stream nebo slony) delay_treshold: definuje maximální množství bajtů, o které smí být slave pozadu za masterem, aniž by to ještě vadilo při odpovídání na dotazy (v případě nastavení 0 se tato funkce vypíná), v případě překročení je slave server odpojen z clusteru sr_check_period: perioda, jak často Pgpool-II server kontroluje, zda je slave aktuální s masterem sr_check_user: uživatel, pod kterým se kontroly aktuálnosti slave s masterem provádí (nutno zadat i když je kontrola vypnuta) sr_check_password: heslo, pod kterým se prokazuje uživatel za účelem kontroly aktuálnosti slave s masterem (nutné zadat i když je kontrola vypnuta) Další speciální nastavení se týkají hlavně rozdělení zátěže a jednotlivých připojení (tzv. loadbalancing). connection_cache: v případě nastavení na hodnotu on umožňuje schovávat některá spojení pro další použití (ihned po vykonání je nezavírá) load_balance_mode: rozkládání zátěže mezi všechny servery (v tomto případě čtecích dotazů), v případě nastavení na hodnotu on je rozložení zátěže povoleno, v opačném případě s nastavením off se všechny dotazy posílají na master server 66

6. Hodnocení vybraných technologií Pgpool-II server umí sám kontrolovat, zda nedošlo k výpadku některého ze serverů a v případě, že ano, už na něj dál dotazy neposílá. Je-li tato funkce vypnuta, dozví se o pádu serveru až v momentě, kdy na něj pošle dotaz a ten vrátí zpět chybu (to může způsobovat zpoždění v odpovědi). health_check_period: perioda, za kterou se provádí kontrola dostupnosti jednotlivých serverů v sekundách health_check_timeout: čas v sekundách, za který kontrola přestává čekat na odezvu serveru (například v případě výpadků na síti apod.) health_check_user: uživatel, pod kterým se provádí test dostupnosti serveru health_check_password: heslo uživatele, pod kterým se provádí test dostupnosti serveru health_check_max_retries: počet opakování kontrol, než prohlásí server za nedostupný health_check_retry_delay: čas v sekundách definující pauzu mezi jednotlivými novými pokusy o zkontaktování serveru poté, co přestal komunikovat connection_timeout: definuje čas v milisekundách, za jak dlouho Pgpool-II server obecně uzná, že nějaký uzel mu již neodpoví Poslední zajímávou částí nastavení jsou cesty ke skriptům a příkazy, které se mají spustit, pokud dojde k specifickým událostem. Takovými událostmi je obnovení master serveru (failback) nebo nahrazení master serveru jedním ze slave serverů (failover). failover_command: cesta k příkazu, který se spustí v případě, když dojde k pádu master serveru a je vybrán nový slave server (skriptu je možné předat mnoho různých hodnot) failback_command: cesta k příkazu, který se spustí pokud je potřeba obnovit vypadnutý master server Specifickou událostí, kterou je možné nastavit, je přidávání nového slave uzlu (tzv. online recovery). V takovém případě je několik nastavení, které se provedou, je-li vyžadováno přidání nového uzlu, nebo znovuspuštění již vypadlého uzlu. Zde je prvně potřeba popsat, jak proces obnovy probíhá: 67

1. BODOBNOVY 1 6. Hodnocení vybraných technologií 2. První fáze procesu obnovy (spouští se 1st_stage_command skript). 3. Vyčká se, až všichni klienti dokončí svoje dotazy a pro další je nastaveno čekání. 4. BODOBNOVY 2 5. Druhá fáze procesu obnovy (spouští se 2nd_stage_command skritp). 6. Spuštění nového uzlu (spouští se skript pgpool_remote_start). 7. Přidání nového uzlu. Nejprve se tedy vytvoří bod, do kterého je možné se v případě chyby vrátit a poté se provede první ze dvou skriptů. Vyčká se, až se všichni klienti odpojí od serveru Pgpool-II. Veškerá další spojení se drží ve frontě a čekají, až proces obnovy skončí. Následně se vytvoří druhý bod obnovy, ke kterému by se v případě chyby dalo vrátit a provede se druhý skript. Následně se nový uzel spustí a přidá se do clusteru. Nyní se všechna volání uvolní a Pgpool-II server bude v případě úspěchu využívat i tento nový uzel pro svoje dotazování. Zatímco první fáze je povinná a slouží ke kopírování dat z nějakého stávajícího uzlu na nový uzel, druhá fáze je zde spíše pro účely synchronizace a není vždy nutná. Potřebná nastavení v konfiguračním souboru pak jsou: recovery_user: uživatel, pod kterým se bude celý proces obnovy nebo přidání uzlu provádět recovery_password: heslo pro uživatele, pod kterým bude probíhat proces obnovy nebo přidání uzlu recovery_1st_stage_command: cesta ke skriptu, který bude spuštěn v první fázi procesu obnovy z datového adresáře na master serveru recovery_2nd_stage_command: cesta ke skriptu, který bude spuštěn v druhé fázi procesu obnovy z datového adresáře na master serveru Nastavení a možnosti fungování jednotlivých skriptů budou popsány v následující podkapitole. Tato nastavení jsou pouze nutná (z pohledu řešení), samozřejmě je zde spousta dalších (vlastní cache, logování, omezení a další), která jsou již nad rámec této práce. 68

6.2.5 Podpůrné skripty 6. Hodnocení vybraných technologií V předešlé části jsem se zmínil o možnostech nastavení některých skriptů vzhledem k přidávání nových uzlů, obnově chybujících uzlů, náhradě stávajícího master serveru za nový a případné vrácení chybujícího master serveru opět jako hlavní uzel. Všechno toto je v Pgpool-II možné nastavit a k tomu jsou zde navrženy procesy, ty však nejsou přímo součástí samotného řešení a je na uživatelích a jejich znalostech, jakým způsobem je implementují [18]. Pro spouštění skriptů je nutné mít nejprve nainstalované některé specifické funkce. Tyto funkce lze instalovat až do již spuštěných databázových serverů, takže je popíši až v části o spouštění. Zotavení nebo přidání uzlu Pro účely zotavení a přidávání nového uzlu byl použit skript basebackup.sh, který jsem umístil do adresáře s daty master serveru. Tento skript získá na vstup od serveru Pgpool-II tři informace přesně v tomto pořadí: 1. cesta k adresáři, kde jsou data master serveru 2. adresa serveru, který vyžaduje obnovu 3. cesta k adresáři, kde jsou data serveru, pro který se provádí obnova Pro účely vysvětlení zjednoduším postup. Nejprve se připraví master databáze k procesu obnovy jiného uzlu. Pomocí příkazu rsync se zkopíruje obsah adresáře z master serveru na nový uzel (s výjimkou některých konfiguračních souborů), připraví se veškeré potřebné informace, aby databáze věděla, odkud má synchronizovat další data (nastavení replikace) a ukončí se proces obnovy. Po prvním skriptu by následoval skript z druhé části procesu obnovení. V tomto případě však není potřeba (u streamovací replikace), neboť uzel si dodatečně stáhne chybějící data už z master serveru. Z toho důvodu se tento krok přeskakuje a rovnou se volá skript pro spuštění nového uzlu pgpool_remote_start, který pouze vzdálěně spustí nový uzel. Po tomto procesu je ještě nutné provést přidání uzlu do konfiguračního souboru Pgpool-II serveru pgpool.conf a zavolat znovunačtení konfiguračních souborů pomocí příkazu pgpool s hodnotou reload a všemi potřebnými odkazy na konfigurační soubory. Povýšení slave na master V případě pádu master serveru je možné požadovat pokračování všech funkcí. V takovém případě je vhodné využít této funkce nastavením skriptu pro tzv. 69

6. Hodnocení vybraných technologií failover. Co se využití pro systém Perun týče, některé dopady by nemusely být žádoucí. Vzhledem k očekávané vysoké konzistenci by tak pád master serveru mohl znamenat ztrátu některých nových dat, která se nemusela včas sesynchronizovat s jednotlivými slave servery. Kromě toho v případě selhání síťového spojení může tento proces zbytečně přinést nechtěné potíže při odpojování a následném připojování master serveru. Pokud je pád způsoben nějakou chybou vzniklou na straně databáze, může tato chyba eskalovat na každý nový master uzel a takto způsobit pád i zbytku clusteru. V případě systému Perun tedy doporučuji raději počítat s možností pádu master serveru a během jeho nepřítomnosti obsluhovat pouze čtecí dotazy. Master server poté ručně nahodit nebo jeden ze slave serverů ručně povýšit, je-li pád opravdu zapříčiněn chybou stroje. I přes toto doporučení se jedná o zajímavou funkcionalitu, a proto zde fungování skriptu zjednodušeně popíši. Ve chvíli, kdy Pgpool-II server zjistí, že master server neodpovídá a prohlásí jej za nefunkční, přestane jej používat pro účely odesílání dat. Poté si vybere ze slave serverů takový, na kterém je povoleno provést povýšení na master a spustí odpovídající skript, jehož cesta je definována v nastavení failover_command. Ten musí provést veškeré potřebné změny (většinou se jedná o spuštění souboru, který přepne vybraný slave server na nový master a pro ostatní slave servery přepne cíl synchronizace). Důležité je, aby nový master dovoloval zbylým slave serverům replikovat svá data. Podobným způsobem funguje příkaz pro navrácení chybujícího master serveru zpět. Ve chvíli, kdy je opět dostupný, spustí se failback_command, který musí zajistit, aby se synchronizoval s novým master serverem, převzal od něj veškerá data a opět přenastavil všechny uzly na původní hodnoty replikace. 6.2.6 Spuštění Spuštění tohoto řešení může probíhat několika způsoby, nejbezpečnější je nejprve spustit všechny uzly (master i slave) v libovolném pořadí a následně spustit Pgpool-II server. Pro spuštění jednotlivých serverů se používá příkazu pg_ctl obdobně jako v případě technologie Postgres-XL s přepínačem -D a cestou k adresáři, kde je daný server inicializovaný. pg_ctl -D /home/postgres/data Skript pgpool pro spuštění Pgpool-II serveru doporučuji používat s přepínači definujícími cestu k přednastaveným konfiguračním souborům, v opačném případě se použije výchozí nastavení. Zmíněné přepínače jsou -f s cestou 70

6. Hodnocení vybraných technologií k souboru pgpool.conf, dále pak -F s cestou k souboru pcp.conf a -a s cestou k souboru pool_hba.conf. Příklad volání: pgpool -F pgpool.conf -f pcp.conf -a pool_hba.conf Pro bezchybné ukončení je doporučeno používat stejný postup jen s hodnotou stop na konci příkazu, případně -m fast stop pro okamžité ukončení stále otevřených spojení. Obdobným způsobem se také provádí načtení nové konfigurace, kdy se na konec příkazu přidá hodnota reload. Po spuštění jednotlivých instancí je potřeba nainstalovat na všechny uzly několik funkcí, které Pgpool-II využívá při přidávání a obnovování uzlů. Tyto funkce lze nalézt přímo v balíčku s instalací Pgpool-II v různých adresářích podle verze. Před verzí 3.4.0 se tyto funkce nacházeli v adresáři /sql/ a od verze 3.4.0 se nacházeji v adresáři /src/sql/. Instalaci lze provést stejným způsobem jako v případě samotného Pgpool-II, tedy./configure, make a make install v adresáři s funkcemi. Poté je nutné na každém uzlu provést přidání rozšíření jednou z následujících možností: psql -c "CREATE EXTENSION jmeno_rozsireni"postgres psql -f rozsireni.sql postgres První varianta je z pohledu PostgreSQL preferovaná, přesto jsem měl netriviální potíže s jejím provedením a nakonec jsem po úprave volil možnost druhou. Týká se to hlavně funkce pgpool-recovery, která se v momentě obnovy uzlu vyvolá a spustí skript pro obnovu uzlu. Dalším krokem je obnova uzlů a připojení slave serverů do clusteru. Do této chvíle byly pro Pgpool-II server neplatné, neboť nebyly nastaveny jako slave, ale chovaly se jako samostatné databáze. Proces přidávání uzlů se spouští příkazem pcp_recovery_node a požaduje několik parametrů v přesně daném pořadí: timeout: číslo, které definuje za jak dlouho se skript automaticky ukončí hostname: adresu uzlu, na které leží Pgpool-II server port: port na kterém poslouchá rozhraní PCP (správa pro administrátory) username: jméno uživatele, který má právo přístupu k administrátorskému rozhraní PCP 71

password: heslo uživatele výše 6. Hodnocení vybraných technologií nodeid: číslo uzlu, nebo-li X, které jsem definoval v sekci o nastavení jednotlivých uzlů v konfiguračním souboru pgpool.conf (master má očekávaně 0, slave servery 1 a víc) Příklad příkazu: pcp_recovery_node 60 127.0.0.1 9999 postgres heslo 1 Po připojení obou uzlů je Pgpool-II schopen rozdělovat zátěž jednotlivých připojení mezi veškeré uzly (master i slave) s váhou dle nastavení. 6.2.7 Importování dat a komunikace s Pgpool-II serverem Podmínkou pro měření výkonnosti, je mít v databázi připravená nějaká data. Já jsem v tomto případě využil obsah produkční databáze ze systému Perun, který mi byl k těmto účelům zapůjčen, abych mohl demonstrovat měřitelné vlastnosti nad reálnými daty. Data jsem dostal v podobě schématu a velkého množství zapisovacích dotazů. Jednotlivé přepínače pro volbu cílové databáze jsem již uváděl, jedná se o - U (uživatel), -h (adresa) a -p (port). Posledním zajímavým přepínačem je -d se jménem databáze. Tímto způsobem je možné přistupovat i ke konkrétním vzdáleným serverům, ke kterým má uživatel povolený přístup. Ačkoliv tedy dále nebudu tyto parametry uvádět, v příkazech je nutné je používat, neboť v opačném případě se použijí výchozí hodnoty. Nejprve jsem tedy musel vytvořit novou databázi. K tomu slouží příkaz createdb. createdb perun Po vytvoření databáze je možné importovat schéma systému Perun příkazem psql s přepínačem -f a cestou k souboru, ze kterého bude proveden import: psql -f perun-postgres-schema.sql Posledním krokem je import samotných dat. Tento proces je totožný s předchozím, pouze se změní zdrojový soubor. psql -f perun-data.sql 72

6.2.8 Měření výkonnosti a hodnocení 6. Hodnocení vybraných technologií K účelům měření výkonnosti jsem využil kombinace unixového příkazu time pro měření času běhu aplikace a v předchozí kapitole zmíněného příkazu psql s přepínačem -c následovaným SQL příkazem. Příkazy byly spouštěny na klientských stanicích a byly cíleny střídavě na Pgpool-II server a samostatnou PostgreSQL databázi. Tímto způsobem jsem naměřil základní chování. Pro pokročilejší měření simulující zatížení v provozu jsem využil zjednodušené verze perun-core s upraveným obsahem hlavní (main) metody tak, aby volala nejčastější příkazy pro generování dat. V těchto testech se měří pouze doba provedení konkrétní metody a na výsledku se mohou částečně projevovat některé automatické optimalizace jazyku Java. K měření času provedení metody využívám proces měření systémového času před a po spuštění. V textu jednotlivých měření používám definování tří základních parametrů. První z nich je parametr klient, který říká, na kolika klientských zařízeních naráz byl test spuštěn. Dále je zde použit parametr volání, který říká buď kolik po sobě jdoucích volání nebo samostatných souběžných volání příkazu bylo z jednoho klienta provedeno. Posledním parametrem je dotaz nebo metoda. V obou případech definuje, co se na daném klientovi provedlo v rámci jednoho volání. Příklad: 1 klient, 1 volání, 1000 čtecích dotazů: testuje se jedno samostatné volání 1000 stejných čtecích dotazů za sebou 5 klientů, 3 samostatná volání, 1000 čtecích dotazů: z každého klienta jsou zavolány 3 samostatná volání a pro každé volání se čte 1000 čtecích dotazů (v rámci klienta se pak bere průměrná doba dokončení všech třech volání) 10 klientů, 3 volání v řadě, 100 zapisovacích dotazů: každý z 10 klientů provede sérii tří po sobě jdoucích volání, kdy každé z nich provede 100 zapisovacích dotazů (výsledkem pro každého klienta je sečtená doba provedení všech 3 volání) Při měření jsem se soustředil především na porovnání rozdílu výkonu clusterového řešení s technologií Pgpool-II oproti samostatné databázi Postgre- SQL, kterou systém Perun momentálně využívá. Ty nejzajímavější výsledky uvádím v této kapitole, ostatní měření jsou součástí přílohy B. Prvním měřením jsem si dal za cíl stanovit rozdíl mezi voláním jednoho složitého dotazu nad Pgpool-II a samostatnou databází. Na obrázku 6.4 je vidět, že v takovém případě jsou rozdíly mezi oběma variantami velmi podobné. Už zde se ale projevují občasné výkyvy ve výkonu Pgpool-II řešení, 73

6. Hodnocení vybraných technologií které se zdají být způsobeny režií za práci s daty. Pgpool-II server totiž nejprve překopíruje obsah výsledku k sobě a teprve potom jej překopíruje ke klientovi. Ačkoliv vše probíhá na lokální síti a tedy bez větších časových ztrát, může se tento způsob práce s daty na výsledku negativně projevit. V kontrastu s tímto samostatným dotazem jsem udělal test, kdy z několika různých klientů odesílám několik totožných požadavků naráz. Na obrázku 6.5 je viditelný rozdíl v rychlosti zpracování a také zde Pgpool-II platí výkonnostní daň za množství přenesených dat. Samostatná databáze tak z tohoto měření vychází výrazně lépe. Obrázek 6.4 Jako druhý cíl měření jsem zvolil velké množství malých čtecích dotazů v sérii. Na obrázku 6.6 je na první pohled patrný rozdíl mezi výkonem Pgpool- II a samostatnou databází pro 3 samostatná volání po 10000 dotazech. Graf na obrázku 6.7 pak znázorňuje fakt, že ani se zvyšujícím se počtem klientů a volání se řešení Pgpool-II nedostává do lepší pozice než samostatná databáze. V tomto případě bylo z 10 klientů odesláno po 3 samostatných voláních, z nichž každý provádí 10000 malých čtecích dotazů v sérii. V tomto případě svou roli jistě hraje i databázová cache, kterou ovšem mohou využít i jednotlivé instance databázových uzlů v Pgpool-II. Samotné zpomalení tu tedy způsobuje právě Pgpool-II server. Měření soustředěná pouze na master databázi z clusteru Pgpool-II vykazují velmi podobný výkon jako pro samostatnou databázi. Další měření na obrázku 6.8 a 6.9 se týkají provádění změn v existujících záznamech v databázovém řešení. První z měření provádí 10000 dotazů v rámci jednoho volání a druhé měření provádí 1000 dotazů z 10 klientů zaráz. 74

6. Hodnocení vybraných technologií Obrázek 6.5 Obrázek 6.6 Ačkoliv je očekávané, že obě hodnocení budou souběžná volání řešit výrazně rychleji, v případě Pgpool-II se ukazuje výrazně lepší práce se souběžnými vlákny. Výkyvy jsou zde způsobeny rozkládáním výpočetních zdrojů databáze mezi jednotlivá vlákna. V čem Pgpool-II v nastavení master-slave opravdu nevyniká je vkládání dat. Zpomalení v tomto případě probíhá už na straně streamovací technologie, která se stará o aktualizaci slave serverů po změně na master serveru. Ačkoliv jsem v tomto případě provedl dvě různá měření, první z nich, které veškeré vkládání dat soustředilo z jednoho klienta, vykazovalo v případě streamovací 75

6. Hodnocení vybraných technologií Obrázek 6.7 Obrázek 6.8 technologie velké narůstající výkyvy ve výkonu. V jednu chvíli dokonce narostlo až na dvojnásobek původního a nepodařilo se mi prokázat, čím byl tento nárůst prováděcí doby způsoben. Lépe uchopitelný tedy je graf na obrázku 6.10 ukazující průměrnou dobu vkládání 1000 nových záznamů z 10 klientů zaráz. Pgpool-II s master-slave streamovací technologií zde vykazuje zpomalení řádově 25 až 30 procent. Pro zneplatnění databázové cache je možné střídavě zapisovat a číst nějakou hodnotu. Naměřené hodnoty při volání 10000 takových střídavých dotazů jsou vidět na obrázku 6.11 a volání 2000 střídavých dotazů z 10 76

6. Hodnocení vybraných technologií Obrázek 6.9 Obrázek 6.10 klientů naráz je vidět na obrázku 6.12. Potvrdilo se, že samostatná databáze rovnoměrněji rozkládá veškerou zátěž. Pgpool-II některá volání zpracuje rychleji, zatímco jiná naopak pomaleji. Jako velmi zajímavé se ukázalo měření série agregačních dotazů. Zde Pgpool-II plně ukázal svou výhodu několika souběžných databází. Rozložení výkonu napomohlo rychlejšímu zpracování a právě tento výsledek nasvědčuje tomu, že Pgpool-II nejlépe zpracovává dotazy náročné na výpočet v rámci databáze, ale jednoduché v poměru množství vracených dat. Výsledky je možné pozorovat na obrázku 6.13. 77

6. Hodnocení vybraných technologií Obrázek 6.11 Obrázek 6.12 Předposlední série měření se zabývá simulováním ostrého provozu z hlediska generování dat pro komponentu perun-engine. Vybral jsem několik klíčových funkcí z perun-core a změřil jejich dobu provedení pro samostatnou databázi a Pgpool-II. Především jsem použil jednu funkci, která dává dohromady data ze zhruba 10000 databázových záznamů oproti druhé, která má téměř desetinásobný obsah dat (kolem 100000 záznamů). Na měřeních 6.14 a 6.15 lze vypozorovat doby provedení zmíněných dvou metod v případě samostatných volání z jednoho klienta. Pgpool-II v obou případech vykázal horší výkonnostní vlastnosti při malém klientském zatížení. 78

6. Hodnocení vybraných technologií Obrázek 6.13 Obrázek 6.14 Ještě zajímavějším je pak volání obou těchto funkcí naráz z 10 klientů. To lépe simuluje běžný provoz, kdy je 10 souběžných generování považováno za momentální výkonnostní strop produkční databáze systému Perun. Výsledky lze vidět na obrázcích 6.16 a 6.17. Ani v těchto měřeních si Pgpool-II oproti samostatné databázi nepolepšil. Poslední z měření na obrázku 6.18 se zaměřuje na opravdu výrazné zatížení formou 10 klientů, kteří naráz provedou každý 5 samostatných volání (5 různých generování s odlišnou velikostí vracených dat). V jeden moment je tedy nad databází zavoláno 50 samostatných shluků čtecích dotazů (simulující 79

6. Hodnocení vybraných technologií Obrázek 6.15 Obrázek 6.16 generovací skripty systému Perun). V tomto případě je již patrné zlepšení Pgpool-II řešení, které rozloží zátěž generování na jednotlivé servery. Zároveň se ale ukazuje obrovská náročnost na operační paměť a procesorový čas a pro další zvyšování počtu připojení by bylo nutné zvýšit výkon stroje, na kterém server Pgpool-II běží. Pokusil jsem se ještě simulovat souběžný požadavek 10 klientů s 10 samostatnými voláními pro každý klient. V tomto případě samostatná databáze i přes velké zatížení data po čase vrátila, Pgpool-II však pro některá volání zcela ztratil spojení. Z míry zatížení stroje usuzuji, že v tomto případě vý- 80

6. Hodnocení vybraných technologií Obrázek 6.17 konnostně nestačil a působil mimo jiné jako nejužší bod průtoku dat (tzv. bottleneck). Při pokusu zvýšit počet udržovaných spojení jsem se setkal s chybou nedostatku paměti stroje. Ostatní měření jsou, jak jsem již zmínil, součástí Přílohy B. 6.2.9 Shrnutí Technologie Pgpool-II mne zaujala hlavně pro svoji rozmanitost vzhledem k různým možnostem nastavení. Zdánlivě však s množstvím možností stoupá i složitost a režie dané technologie. Ačkoliv dosahuje dobrých vlastností v rámci robustnosti a vysoké dostupnosti, výkonnost a škálovatelnost jsou zde slabými místy. Problém se škálovatelností je způsoben společným vstupním bodem, který lze přetížit (server Pgpool-II) a výkonnost zde ubíjí především způsob práce s daty (kopírování dat na server a teprve poté ke klientovi). Od určité úrovně se Pgpool-II začal výkonem přibližovat jedné instanci databáze, ale s mnohem většími nároky na paměť, procesorový výkon a množství souběžných spojení. Za účelem odstranění potíží s výkonem jsem provedl několik optimalizací (odstranění veškerého logování, odstranění zpoždění v rámci sítě, oddělení klientů od serveru apod.) ovšem ani jedna z nich v konečném důsledku nepomohla výkonnostní propad vyřešit. Vlivem využití streamovací technologie se projevilo očekávané zpomalení při zapisování. V rámci agregačních dotazů pak Pgpool-II také splnil očekávání a předčil jednu instanci databáze díky malému množství návratových hodnot 81

6. Hodnocení vybraných technologií Obrázek 6.18 a velkému zatížení na straně jednotlivých datových uzlů. Jako celek vzhledem k očekávaným vlastnostem toto řešení neuspělo. Pokud zde v budoucnosti dojde k opravě výkonnostních potíží, doporučil bych uvažovat o produkčním využití této technologie pro účely systému Perun. 6.3 Rozšíření master-slave streamovací replikace Toto řešení jsem navrhl jako potenciální náhradu za Pgpool-II, kdy se využije replikace na pozadí a zvolí se způsob rozložení pouze čtecích dotazů mezi jednotlivé slave servery. V takovém případě se zmenší zpoždění práce s daty na straně Pgpool-II serveru a využije se zmíněné rozložení zátěže pro čtecí 82