Západočeská univerzita v Plzni Fakulta aplikovaných věd Katedra informatiky a výpočetní techniky Bakalářská práce Analýza DB knihoven a technologií pro Javu Plzeň, 2015 Jaroslav Medek
Prohlášení Prohlašuji, že jsem bakalářskou práci vypracoval samostatně a výhradně s použitím citovaných pramenů. V Plzni dne 25. června 2015 Jaroslav Medek
Abstrakt Práce je zaměřena na analýzu databázových systémů, které je možné používat jako embedded (in-process) v jazyce Java. Čtenář by měl nejprve získat základní přehled o existujících datových modelech, jejich základních odlišnostech, výhodách případně nevýhodách plynoucích z použití dané technologie. V další části je uveden přehled 18 vybraných databázových systémů s embedded funkcionalitou a představení jejich základních charakteristik funkce udávané tvůrci systému, podpora, cena, historii vývoje a podobně. Vybrány byly 4 open-source databázové systémy SQLite, Apache Derby, H2 a HyperSQL, jejichž možnosti jsou podrobněji rozebrány v další části práce. Pro tyto čtyři databázové systémy je dále připraven základní benchmark pro otestování, jak rychlé jsou. Benchmark je založen na vybraných základních vlastnostech TPC-C transakčního testu. Abstract The work is focused on analysis of database systems that supports embedded (in-process) funcionality for Java programming language. The readers should gain an overview of existing data models their fundamental differences, advantages, disadvantages possibly arising when using them. The next section provides an overview of 18 selected database systems with embedded functionality and their basic characteristics - function declared by the creators of the system, production support, price, history of development etc. four open-source database systems were selected for detailed comparsion SQLite, Apache Derby, H2 a HyperSQL. Their functionality is discused in the second section of this work. These four systems were also tested and compared by basic transctional TPC-C like test implemented in this work.
Obsah 1. Úvod... - 1-2. Základní pojmy a teorie... - 2-2.1 Databázový systém... - 2-2.2 Transakce... - 2-2.3 Relační databáze... - 3-2.4 Objektové databáze... - 6-2.5 Objektově-relační databáze, ORM... - 7-2.6 Nosql databáze... - 8-3. Představení vybraných databázových systémů... - 11-3.1 Relační databáze... - 11-3.2 Objektové databáze... - 14-3.3 Key/Value databáze... - 16-3.4 Sloupcové databáze... - 18-3.5 Grafové databáze... - 19-3.6 Dokumentové databáze... - 21-4. HyperSQL... - 22-4.1 Databáze... - 22-4.2 Možnosti provozu... - 23-4.3 Tabulky... - 24-4.4 Další nástroje... - 26-4.5 Víceuživatelský přístup... - 26-5. SQLite... - 28-5.1 Dotazování... - 28-5.2 Datové typy... - 28-5.3 Zamykání... - 29-5.4 Pragma příkazy... - 30-5.5 Nástroje... - 31-6. TPC-C test... - 35 -
6.1 Neimplementované vlastnosti... - 35-6.2 Testovací databáze... - 36-6.3 Business Transakce... - 37-6.4 Metrika... - 37-7. Implementace a průběh testu... - 38-7.1 Fungování testovací aplikace... - 38-7.2 Testovací konfigurace... - 39-7.3 Parametry testování... - 39-8. Výsledky měření... - 40-8.1 Souborový režim databáze... - 41-8.2 In-memory režim databáze... - 44-9. Závěr... - 47 - Seznam zkratek... 48 Literatura... 51 A. Srovnání parametrů vybraných databázových systémů... 58 B. ERA diagram testovací databáze... - 65 - C. Připojení k testovaným SŘBD... - 66 - D. Ovládání testovacího programu... - 69 - E. Naměřené hodnoty MQTh... - 72 -
1. Úvod Cílem této práce je dohledat co největší množství knihoven, které umožňují tvorbu embedded databází v Javě, nebo databázových serverů se kterými Java může komunikovat přímo - jinými metodami než přes ODBC / JDBC. Nejprve by měly být uvedeny jen funkce udávané tvůrci systému, podpora, cena, historii vývoje a podobně. U několika vybraných systémů bude provedeno podrobnější srovnání a dále připraven základní benchmark pro otestování, jak rychlé jsou. Benchmark by měl být založen na technologiích, které jsou používány pro testování výkonnosti databázových systémů. V závěru by měl být připraven stručný návod pro použití jednotlivých databází v Javě. Cílem není rozhodnout o tom, který databázový systém je nejlepší pro konkrétní použití, ale spíše poskytnutí základních informací o možnostech, které se nabízejí. Výstup práce je určen každému, kdo hledá jednoduchý, snadno použitelný embedded databázový systém a nemá dostatečnou představu o možnostech, které se v dané oblasti nabízejí. - 1 -
2. Základní pojmy a teorie 2.1 Databázový systém Pojem databázový systém bývá nesprávně zaměňován s databází. Databáze (označovaná také báze dat, nebo zkratkou db) je množina souvisejících, logicky uspořádaných dat uložených v paměti počítače. Aby mohli uživatelé s daty manipulovat, musí databázový systém obsahovat potřebné programové vybavení (například dotazovací jazyk). Takové softwarové vybavení, které umožňuje vkládat, mazat, editovat a dále zpracovávat data uložená v databázi, se nazývá systém řízení báze dat (SŘBD). Každý databázový systém je tvořen nejen vlastní databází, ale také systémem řízení báze dat. [Ott12] Obrázek 2.1: Databázový systém je složen z databáze systému řízení báze dat (vlastní zpracování podle [Ott12]). 2.2 Transakce Databázová transakce je jistá posloupnost nebo specifikace posloupnosti akcí, jako jsou čtení, zápis, výpočet, se kterou se zachází jako s jedním celkem [Pok97]. Počet a rozsah operací proveditelných v rámci jedné transakce není omezen. Od provádění činnosti celého programu, provedení posloupnosti několika, nebo jednoho SQL příkazu. Transakce se v databázových systémech používají, pokud je nutné provést více příkazů pro SŘBD v jednom nedělitelném celku. Klasickým příkladem je převod peněz mezi dvěma bankovními účty. Vždy musí být zajištěno, že dojde k odečtení částky z jednoho účtu a následně přičtení stejné částky na druhý účet. Nikdy nesmí dojít k situaci, že by - 2 -
peníze byly z prvního účtu odečteny a na druhý nepřičteny. Pokud bude převod peněz vykonán v rámci databázové transakce, změny proběhnou na obou účtech, nebo neproběhnou vůbec a databáze bude navrácena do stavu před započetím transakce [Man05] [Pok97]. 2.1.1 ACID Aby nedošlo k porušení konzistence dat, musí každá databázová transakce splňovat tyto vlastnosti: Atomicita: Transakce musí být provedena jako nedělitelná (atomická) operace. Operace v rámci transakce jsou provedeny všechny, nebo se neprovede žádná z nich. Konzistence: Databáze se vždy nachází v konzistentním stavu, během vykonávání transakce nesmí dojít k porušení žádného z integritních omezení. Pokud transakce selže, nesmí být uloženy žádné změny. Izolovanost: Pokud probíhá více transakcí souběžně, jsou na sobě nezávislé. Výsledek paralelního zpracování transakcí bude stejný, jako když proběhnou sekvenčně. Trvalost: Po úspěšném průběhu transakce jsou provedené změny uloženy v databázi natrvalo. Je zaručeno, že nedojde ke ztrátě nebo poškození dat v důsledku selhání aplikace, nebo databázového systému. Transakce, které tyto vlastnosti splňují, se obvykle označují zkratkou ACID (Atomicity, Consistency, Isolation, Durability). Databázový systém, který takovéto transakce podporuje, se označuje za silně konzistentní [Pok97] [Staff 14]. 2.3 Relační databáze Model relační databáze vychází z práce Dr. E. F. Codda 1, který v roce 1970 publikoval článek A relational data model for large shared data banks, v němž popsal databázový model založený na operacích relační algebry. [Sum07] [Codd70]. Základním prvkem relační databáze jsou uspořádané n-tice řádků (záznamů) a sloupců (atributů). Takto uspořádané n-tice se označují jako relace. Relaci si můžeme představit jako tabulku, kde každý řádek uchovává data o jednom objektu a každý atribut odpovídá jednomu sloupci. V praxi je potřeba mít nějaký způsob, jak jednoznačně identifikovat záznamy každé tabulky. Docílit toho lze použitím tzv. primárního klíče relace. Jde o atribut, nebo množinu atributů, jejichž hodnota je pro každý řádek tabulky unikátní. Dalším 1 Anglický matematik a programátor. Pracoval v laboratořích IBM, kde se zabýval především výzkumem v oblasti relačního modelu dat. Je po něm pojmenována jedna z normálních forem Boyce-Coddova normální forma. [Wik15] - 3 -
speciálním atributem relace je cizí klíč, který se používá pro zachycení vztahů mezi tabulkami, a stejně jako primární klíč, může být složen z hodnot více sloupců. Pro vytvoření vazby mezi dvěma záznamy z různých tabulek musí být hodnota cizího klíče relace stejná, jako hodnota primárního klíče v domovské relaci [Sum07] [Šar03] [Con05]. Další vlastnosti relačního modelu dat jsou následující: V jedné databázi nesmí být dvě tabulky se stejným názvem. Požadavek na jedinečnost názvu platí také pro názvy atributů (sloupců) v rámci jedné tabulky [Sum07]. V relaci nezáleží na pořadí jednotlivých řádků ani sloupců. Jejich záměnou vznikne ta samá relace. Každý atribut má předem určenou množinu hodnot, kterých může nabývat. V této souvislosti se používá termín doména atributu [Šar03]. Hodnota atributu ve sloupci je dále nedělitelná (atomická). Primární klíč nemusí být v tabulce obsažen. Pokud ho tabulka obsahuje, musí být jeho hodnota pro každý řádek unikátní, a žádný z klíčových atributů nesmí obsahovat hodnotu NULL [Con05]. V sedmdesátých letech proběhl v IBM výzkum zaměřený na možnosti využití relačních databází, jehož součástí bylo vytvoření speciálního neprocedurálního jazyka pro práci s daty pojmenovaného SEQUEL (Structured English Query Language). SEQUEL byl později přejmenován na SQL (Structured Query Language) a díky vzrůstajícímu využití relačních databází došlo v roce 1986 k jeho standardizaci 2. [Dat04][Šim99] Příkazy jazyka SQL se dělí do čtyř základních skupin [Con05]: DDL (Data Definition Language) Příkazy sloužící k definici dat, tvorbě a úpravě struktury databáze (například: CREATE, DROP, ALTER). DML (Data Manipulation Language) příkazy pro základní manipulaci s daty. Jedná se především o čtení, zápis, editaci a mazání dat, v literatuře označované Anglickou zkratkou CRUD (Create, Read, Update, Delete). DCL (Data Control Language) Příkazy pro správu uživatelských rolí a oprávnění (například: GRANT, REVOKE). TCL (Transaction Control Language) příkazy sloužící ke správě databázových transakcí (například: COMMIT, ROLLBACK). Konkrétní možnosti jazyka SQL závisí na tom, jaký standard nebo jeho části jsou v databázovém systému implementovány a mohou se výrazně lišit. Nejčastěji jsou podporovány starší standardy SQL-92 a SQL-99, které bývají doplněny o některé 2 První byl standard SQL86 vydaný organizací ANSI. Aktuálně již osmou verzí jazyka SQL je standard ISO/IEC 9075:2011, vydaný v prosinci roku 2011. Úplný popis zmíněného standardu lze zakoupit na stránkách organi-zace ISO. Více na: http://www.iso.org/iso/home/search.htm?qt=9075&sort=rel&type= simple&published=on - 4 -
vybrané funkce z novějších verzí jazyka SQL. Mnoho SŘBD obsahuje také řadu vlastních příkazů, které nejsou součástí SQL standardů. Odlišnosti SQL dialektů v závislosti na výrobci databáze způsobují problémy s přenositelností dotazů, potažmo celé aplikace mezi jednotlivými SŘBD. [Dat04] [Šar03] Důležitou roli při udržování databáze v konzistentním stavu hraje správný návrh databáze. Jednou z technik používaných při návrhu databáze je normalizace dat, při které zkoumáme funkční závislosti mezi jednotlivými atributy s cílem nalezení optimální struktury jednotlivých relací (tabulek). Správně provedená normalizace snižuje nebezpečí vzniku nekonzistence, jako důsledku redundance dat, nebo jiných tzv. anomálií, ke kterým může docházet při manipulaci s daty. Existuje celkem šest stupňů normalizace, které se souhrnně označují jako normální formy. Doporučena je normalizace alespoň do třetí normální formy, která je dostačující pro eliminaci aktualizačních anomálií. Transformace do vyšších normálních forem většinou není nutná, neboť řeší pouze velmi vzácně se objevující situace [Šar03] [Con05]. Změna rozložení databáze, aby splňovala vyšší normální formy, navíc vede ke složitějším dotazům selecty pak musí spojovat víc a víc tabulek. Některé databáze proto nesplňují ani první normální formu. Porušení hned první normální formy se často týká i databází obsahujících sloupce s datovým typem BLOB (Binary Large OBject např. XML soubory, obrázky, videa, pokud jejich obsah není zpracováván jako atomická hodnota. Během návrhu relačního modelu určujeme povolené hodnoty atributů, vztahy mezi tabulkami, nebo primární klíč každé relace. Při manipulaci s daty je potřeba zajistit, že navržené schéma nebude porušeno vložením nesprávných dat nebo poškozením, případně ztrátou dat stávajících. K tomu se používá sada pravidel, která se nazývají integritní omezení. [Con05][Dat04] V rámci referenční integrity jsou kontrolovány hodnoty cizích klíčů relace. Existuje-li v relaci cizí klíč, musí jeho hodnota odpovídat primárnímu klíči v domovské relaci, nebo musí být hodnota všech atributů cizího klíče NULL. Entitní integrita musí zajistit jedinečnost primárního klíče relace. Toto pravidlo říká, že žádný z atributů primárního klíče nesmí obsahovat hodnotu NULL. Každý atribut může obsahovat pouze hodnoty z určitého intervalu, definovaného při návrhu databáze. Toto pravidlo se označuje jako Doménová integrita. [Con05] [Ott04] Bez dodržení těchto pravidel je v praxi téměř nemožné udržet databázi v konzistentním stavu. Většina relačních databází kontroluje dodržení definovaných integritních omezení automaticky, je však vhodné si ověřit, zda není kontrola integritních omezení ve výchozím nastavení databázového systému vypnuta. V takovém případě totiž platí, že SŘBD definovaná omezení ignoruje. Bohužel, ne všechny databázové systémy je podporují v plném rozsahu, a tak musí být implementovány v rámci aplikace. [Con05] Relační model dat poskytuje díky pevně stanovené datové struktuře, ACID transakcím a mocným nástrojem v podobě integritních omezení konzistentní, spolehlivý databázový systém. Existence standardizovaného dotazovacího jazyka a velkého množství sofistikovaných nástrojů pro zálohování, reportování, administraci, migraci dat, jsou další z důvodů, proč jsou relační databáze nejrozšířenějším datovým uložištěm. - 5 -
Použití relačních databází je však spojeno s řadou nevýhod. Mezi ty nejčastěji zmiňované patří zejména následující: Špatná reprezentace objektů reálného světa [Tiw11]. Homogenita ukládaných dat. Každý řádek musí obsahovat stejné atributy, hodnoty každého sloupce jsou omezeny doménou atributu [Con05]. Problematické změny databázového schématu. Provedení takových změn se často neobejde bez výrazných zásahů do celé aplikace [Tiw11]. Nedostatečná podpora integritních omezení ze strany poskytovatelů relačních databázových systémů. Kontrolu integrity dat je potřeba zajistit v rámci aplikace [Con05]. špatná škálovatelnost [Tiw11]. Kvůli výše zmíněným a některým dalším nedostatkům byly vytvořeny další databázové modely, které jsou alternativou v případech, kdy klasické relační databáze neposkytují dostatečnou flexibilitu a škálovatelnost [Tiw11]. 2.4 Objektové databáze Na začátku 90. let došlo ke změně programovacího paradigmatu, a ve vývoji aplikací postupně převládly objektově orientované jazyky. Pro ukládání dat jsou však téměř výhradně používány relační databáze, které mají velké množství nedostatků. Některé z nich byly již zmíněny obtížné modelování komplexních vztahů mezi objekty reálného světa, homogenní struktura ukládaných dat, omezené datové typy apod. Problematické je samotné použití relačních databází s objektově orientovanými jazyky, protože se často neobejde bez implementace složitého mechanismu mapování mezi záznamy v tabulce a objekty příslušných tříd. Nákladnost vývoje takového procesu byla hlavním impulzem pro vznik objektových databázových systémů (ODBS), které umožňují ukládat data do objektů přímo tak, jak s nimi pracujeme. Kromě toho nabízí všechny základní principy objektově orientovaného programování, jako jsou dědičnost, abstrakce či polymorfismus, které navíc doplňují o možnosti dotazování, transakčního zpracování apod. [Con05] [Bat] [Zím14] [Šve03] [Mer04] Objektové databáze jsou složeny ze dvou základních prvků objektů a literálů. Objekty jsou instance určité třídy, která definuje společnou množinu vlastností (atributů) a operací (metod), které lze nad objekty příslušné třídy provádět. Každý objekt má systémem přidělený, unikátní identifikátor (OID Object IDentifier). OID funguje jako ukazatel na objekt, jeho hodnota je neměnná a naprosto nezávislá na atributech objektu. Vztahy mezi objekty mohou být stejně jako v relačních databázích pouze binární 1:1, 1:N a M:N. Vytvářejí se pomocí referenčních atributů, typicky s využitím OID. Literál je datová struktura, která může být atomickou hodnotou (atomický literál), kolekcí literálů stejného typu, nebo komplexní strukturou více elementů, kde každým typem může být opět literál, případně objekt. Základní rozdíl mezi objekty a literály je ten, že literál nemá vlastní identitu. Hodnota datových složek - 6 -
literálu je konstantní a nelze jej jednoznačně identifikovat. Proto se literály nepoužívají samostatně, ale pouze jako součást objektů. [Šve03] [Con05] [Mer04] [Cat00] Od objektových databází se očekávalo, že postupně nahradí zastaralý relační model. Nestalo se tak především z důvodu vysokých nákladů s tím spojených, a také faktu, že pro relační databáze existuje řada sofistikovaných nástrojů umožňujících zálohování, reportování, migraci dat, administraci apod., které objektové databáze většinou nenabízejí. Dalším problémem objektových databází je nedostatečná podpora integritních omezení. Většina ODBS neumožňuje vytváření a automatickou kontrolu integritních omezení v hierarchii dědičnosti a u kompozitních objektů. [Zaq08] I přes tyto problémy je použití objektových databází v řadě aplikací velmi výhodné. Jedná se především o systémy, které se vyznačují vysokou komplexitou zpracovávaných dat, jako například geografické informační systémy (GIS), multimediální systémy, CAD systémy apod. [Con05] 2.5 Objektově-relační databáze, ORM Jak již bylo zmíněno, entity objektového programovacího jazyka nelze ukládat do relační databáze přímo. Je potřeba implementovat proces mapování objektů příslušné třídy na záznam relační tabulky a zajistit perzistenci (trvalé uložení) dat. Proto se na trhu objevily objektově-relační databázové systémy (ORDBS), které zajišťují mapovací mechanismus automaticky. Základem ORDBS je klasický relační model dat, doplněný o vybrané funkcionality objektových databází jako OID, dědičnost, polymorfismus, abstraktní datové typy, zapouzdření a další. K dotazování se používá jazyk SQL, rozšířený o možnosti práce s objekty. [ODBMS05] Nevýhodou ORSŘBD je složitost celé technologie a s tím spojené vyšší náklady. Navíc platí, že proces převodu objektů do relační databáze je spojen se značnou režií, a může snižovat výkonnost databázového systému. [ODBMS05] Druhou možností, jak zajistit automatické mapování záznamů relační databáze na objekty a jejich perzistenci jako objektu příslušné třídy, jsou nástroje pro objektově relační mapování (ORM). Použitím ORM nástrojů lze dosáhnout odstínění programátorů i uživatelů od konkrétní relační databáze. Díky tomu je zajištěna bezproblémová přenositelnost aplikace mezi podporovanými SŘBD. Nejpopulárnějším ORM nástrojem je Hibernate, který je v této oblasti považován defacto za standard. Aktuální verze podporuje mapování a perzistenci objektů pro zhruba 30 relačních databází. Hibernate disponuje vlastním objektovým dotazovacím jazykem Hibernate Query Language (HQL), který je syntakticky velmi podobným jazyku SQL. Použití HQL usnadňuje přenositelnost aplikace mezi jednotlivými databázovými systémy, které mohou používat odlišné dialekty jazyka SQL. [Len09] [Hib15] Nevýhody nasazení ORM jsou podobné jako v případě ORDBMS. Komplexní nástroje jako Hibernate vyžadují další náklady spojené s osvojením a nasazením technologie. [Len09] [Hib15] - 7 -
2.6 Nosql databáze Každé dva roky se objem vznikajících dat přibližně zdvojnásobí, přičemž v roce 2020 bude až 33 % dat (oproti dnešním cca 25%) obsahovat informace, které by mohly být komerčně využity. [Gan12] Problémem je, že pro zpracování takového objemu často nestrukturovaných, komplexních a značně propojených dat, nejsou relační databáze vhodné; z důvodu špatné škálovatelnosti a požadavku na (alespoň částečnou) předvídatelnost a strukturovanost dat. První zareagovala společnost Google, která nejprve v roce 2003 zveřejnila principy souborového systému pro ukládání distribuovaných dat GFS (Google File System), a poté v roce 2006 představila sloupcové úložiště BigTable. [Chan08] U projektu BigTable se inspiroval internetový prodejce Amazon a v roce 2007 zveřejnil koncept key/value databáze DynamoDB, [Dec07] kterou začal využívat ve svých distribuovaných systémech. [Pok12] Na základě zveřejněných konceptů projektu BigTable a Dynamo vzniklo velké množství open-source databázových systémů, pro které se dnes používá označení Nosql (Not only sql) [Neu10]. Hlavní charakteristiky Nosql databázových systémů jsou následující: Podporují nerelační datový model (key/value, sloupcové, dokumentové, grafové) [Neu10]. ACID model konzistence je většinou podporován pouze částečně. Místo něj je podporován alternativní model zajištění konzistence dat BASE (Basic Availability, Soft-state, Eventual consistency). Jsou primárně určeny pro použití v distribuovaných systémech (obsahují podporu pro snadnou replikaci a distribuci dat) [Tiw11]. Jsou vysoce horizontálně škálovatelné [Neu10]. K dotazování nepoužívají jazyk SQL (práce s daty je řešena vlastním jednoduchým API, někdy je k dispozici vlastní dotazovací jazyk, který může syntakticky vycházet z SQL) [Tiw11]. Nevyžadují dodržení pevného schéma databáze (umožňují ukládání nestrukturovaných dat) [Tiw11]. 2.1.2 BASE Nosql databáze jsou primárně určeny pro použití v distribuovaných databázových systémech, kde je většinou preferována výkonnost a zajištění vysoké dostupnosti dat na úkor konzistence dat. Místo silně konzistentních systémů s ACID transakcemi se zde často setkáváme s přístupem označovaným zkratkou BASE [Bro09] [Staff14]: Basic Availability: Data jsou neustále k dispozici, systém je vysoce odolný proti poruchám. - 8 -
Soft-state: Data nemusí být v každém okamžiku konzistentní, zajištění konzistence dat je zodpovědností vývojářů klientské aplikace a neměla by být řešena databázovým systémem. Eventual Consistency: Konzistence není zajištěna okamžitě, ale je garantováno, že se v budoucnosti databáze dostane do konzistentního stavu. 2.1.3 Klíč/hodnota databáze Nejjednodušším typem Nosql databází jsou databáze klíč/hodnota (key/value), které fungují na stejném principu jako hash tabulky. Záznamy tvoří dvojice klíč/hodnota, kde klíč (nejčastěji řetězec) slouží k jednoznačné identifikaci hodnoty v databázi. Hodnota může být libovolná, strukturovaná i nestrukturovaná (typicky BLOB). Key/value databáze nevyžadují pevné schéma dat, takže dvojice klíč-hodnota nemusí být stejných typů a není nutné ukládat hodnoty NULL (na rozdíl od záznamů v relačním modelu). Záznamy jsou většinou ukládány v pořadí seřazeném podle hodnoty klíče, pro zrychlení vyhledávání v databázi. Možnosti pro další zpracování dat jsou v key/value databázích velmi omezené. Typicky jsou implementovány pouze operace pro ukládání, získávání a odstranění hodnoty na základě znalosti klíče put(key), get(key), delete(key). [Pok12] [Dec07] [Tiw11] Většina dnes používaných klíč/hodnota databází vychází z distribuovaného databázového systému DynamoDB, navrženého pro potřeby internetového obchodu Amazon. Nejčastěji se využívají ve webových aplikacích pro správu informací u jednotlivých spojení (nastavení uživatelských profilů, monitorování aktivity, ukládání nákupních košíků v on-line obchodech apod.). V těchto případech nabízí klíč/hodnota databáze vysoký výkon a škálovatelnost i při desítkách milionů současně připojených uživatelů. Nevýhodou key/value uložišť je příliš jednoduchý datový model a s tím spojené omezené možnosti práce s daty. [Dec07] [Chan08] [Ree13] 2.1.4 Sloupcové databáze Datový model je velmi podobný relačním úložištím, ale záznamy jsou na místo po řádcích ukládány po jednotlivých sloupcích. Každý záznam je složen z dvojice (klíč, hodnota), kde klíč udává název sloupce a hodnota může být libovolná, jako je tomu v key/value úložištích. Často se spolu s každým záznamem uchovává také časový údaj o době vzniku, nebo poslední editaci záznamu. Sloupce se souvisejícími hodnotami jsou slučovány do skupin a každá skupina sloupců obsahuje množinu unikátních klíčů, které zajišťují jednoznačnou identifikaci každého řádku ve skupině sloupců. Datový model nevyžaduje dodržování pevného schématu sloupce nemusí být definovány předem a řádky v rodině sloupců mohou obsahovat různé sloupce. [Tiw11] [Pok12] [Bry14] Výhodou organizace dat po sloupcích je možnost pracovat přímo pouze s daty z vybraných sloupců. To výrazně zvýší výkonnost zejména těch aplikací, které často čtou pouze malé množství sloupců z velké tabulky, protože nemusí vybírat celé řádky a požadované sloupce z nich extrahovat. Vzhledem k velkému množství shodných - 9 -
hodnot v jednotlivých sloupcích provádí většina sloupcových databázových systémů kompresi dat. Kompresí lze výrazně snížit velikost dat a urychlit tím jejich čtení z disku. Běžný je kompresní poměr 5:1, v některých případech je možné dosáhnout i 10ti násobného zmenšení velikosti dat oproti jejich nekomprimované podobě. Většinu sloupcových databází tvoří klony distribuovaného úložiště BigTable od společnosti Google. Využívají se především v datových skladech a analytických systémech, které potřebují velké množství dat. [Tiw11] [Swa13] [Bry14] [Staff14] 2.1.5 Dokumentové databáze Datový model je velmi podobný s databázemi klíč/hodnota, ale hodnotou je zde semistrukturovaný dokument. Dokumenty jsou obvykle složeny z párů klíč-hodnota, mohou obsahovat indexy, případně do nich mohou vnořeny další dokumenty. Nejčastěji se dokumenty ukládají ve formátech JSON, XML, nebo jako objekt. Některé dokumentové databáze používají vlastní formáty pro reprezentaci dat, například databázový systém MongoDB převádí ukládané dokumenty do interního formátu BSON. Dokumenty obsahující související data se obvykle seskupují do tzv. kolekcí, které si lze představit jako ekvivalent tabulky v relačních databázích. V rámci kolekce mohou mít jednotlivé dokumenty vzájemně odlišnou strukturu, která nemusí být definována předem a lze ji kdykoliv změnit. [Tiw11] [Bry14] [Pok12] Velkou výhodou dokumentových databází je právě formát JSON. Do něj lze snadno převést objekty většiny programovacích jazyků, a vkládat je přímo do databáze, bez složitého mapování mezi záznamy a objekty příslušných tříd, jako je tomu v případě relačních databází. Využití dokumentových databází je obdobné jako v případě key/value databází, ale dokumenty lze snadno využít pro ukládání velkého množství dat, a pracovat s nimi pomocí jediného klíče. Například se může jednat o ukládání informací o konkrétním produktu, uchovávání logovacích dat, údaje z uživatelských profilů apod. [Tiw11] [Pok12] [Bry14] 2.1.6 Grafové databáze Výše zmíněné Nosql databáze typicky pracují s obrovským množstvím nestrukturovaných dat, které je potřeba co nejrychleji ukládat a následně ve stejné podobě získat. Pokud však potřebujeme analyzovat vztahy mezi daty, neobejdeme se bez dalšího zpracování. Proto je výhodné ukládat data do grafových struktur, které poskytují náhled do propojenosti dat přímo, bez komplikovaných analytických výpočtů. [Bach14] V grafových databázích jsou dva druhy entit uzly (vrcholy grafu) a hrany. Nejčastěji pracují s tzv. grafem vlastností (property graph), kde každý vrchol obsahuje další údaje objektu, který reprezentuje, a hrany obsahují popis vztahů mezi vrcholy, které propojují. Data v uzlech a hranách jsou typicky ukládány jako páry klíč/hodnota a mohou být prohledávány indexovaným způsobem jako v relačních databázích. Po nalezení požadovaného vrcholu lze přistupovat ke všem jeho sousedům v konstantním čase, bez ohledu na rozsáhlost grafu. Při průchodu grafem je možné využívat množství grafových algoritmů. Například algoritmus vyhledávání nejkratších cest mezi uzly, Dijkstrův algoritmus, algoritmus minimální kostry grafu a řadu dalších. [Hol12] [Bach14] [Rob13] - 10 -
Grafové databázové systémy jsou v současnosti velice populární, rychle se rozšiřující databázovou technologií. Ředitel společnosti Neo Technology Emil Eifrem předpokládá, že do konce roku 2020 bude nejméně čtvrtina z 2000největších společností světa využívat ve svých systémech grafové databáze. Typické příklady pro využití grafové databáze jsou doporučovací systémy a sociální sítě. Například obchodní řetězec Wall-Mart využívá grafovou databázi pro analýzu nákupního chování zákazníků; oblíbenost jednotlivých výrobků u specifických skupin zákazníků, jaké kombinace produktů jsou nakupovány společně atd. Získané údaje se pak využívají k cílené reklamě. Naopak pro obyčejné ukládání velkého objemu agregovaných dat, nejsou grafové struktury vhodné. V těchto případech je výhodnější použít jiné Nosql databáze, s jednodušším schématem, které poskytují lepší výkonnost a škálovatelnost. [Hol12] [Bach14] [Woo15] 3. Představení vybraných databázových systémů Následuje stručný popis 18 vybraných SŘBD, které je možné používat jako embedded (in-process) v jazyce Java. Srovnání některých parametrů a další doplňující informace jsou uvedeny v souhrnných tabulkách v příloze této práce. Další databázové systémy (nejen pro jazyk Java), lze dohledat například na webu db-engines.com 3. 3.1 Relační databáze 3.1.1 Firebird Projekt Firebird 4 vznikl v roce 2000 po uvolnění zdrojových kódů databázového systému InterBase 6.0 od společnosti Borland. Prvotní verze byla napsána v jazyce C, ale od verze 1.5 byl kód Firebirdu z velké části přepsán do C++. Firebird je k dispozici ve čtyřech variantách: Classic, Superclassic, Superserver a Embedded. Hlavní rozdíl mezi nimi je ten, že Classic používá pro každé spojení samostatný, nezávislý proces, zatímco Superserver a Superclassic sdílí svoji cache paměť se všemi spojeními, které jsou obsluhovány v samostatných vláknech. Verze Superclassic a Classic je možné použít také jako embedded server spravující lokální databázi. Připojit se k databázi lze pomocí nativního 3 http://db-engines.com/en/ranking 4 http://www.firebirdsql.org/ - 11 -
API, dostupné jsou ovladače pro JDBC, ODBC a rozhraní pro použití Firebirdu v.net, PHP, Python a dalších jazycích. Dostupné jsou oficiální i neoficiální nástroje pro správu zabezpečení, replikaci, administraci databáze a další. [Can10] [Fir14] [Fir11] 3.1.2 Apache Derby Apache Derby 5 je relační databáze, vycházející ze zdrojového kódu projektu Cloudscape společnosti IBM. Na vývoji Apache Derby se podílí také společnost Oracle, která jí pod názvem JavaDB distribuuje jako součást standardních JDK od verze 1.6. Derby je napsána kompletně v Javě a je možné ji používat pouze s jazyky, které pracují v Javovském virtuálním stroji. Připojení k databázi je možné pomocí JDBC ovladače, a také jednoduchým nástrojem ij, se kterým lze spouštět SQL dotazy a skripty z příkazové řádky. V případě potřeby sdílení databáze s více uživateli může být databázový stroj spuštěn v režimu server, komunikující se vzdálenými klientskými aplikacemi pomocí TCP/IP a protokolu DRDA 6. Databáze může být perzistentně uložena na lokální diskové úložiště, nebo je možné použít in-memory databázi, která uchovává data v operační paměti pouze po dobu běhu programu. Transakce splňují ACID vlastnosti a mohou probíhat vícevláknově s použitím zamykání na úrovni řádků, nebo tabulek. Použitý dialekt jazyka SQL splňuje všechny požadavky standardu SQL- 92. Z ostatních standardů je implementována pouze část vybraných funkcionalit 7. Přístup k datům uloženým na disku je možné šifrovat s využitím algoritmů z knihovny JCE (Java Cryptography Extension). [Apa14] 3.1.3 Hyper SQL DataBase Relační databázový systém napsaný v Javě, dostupný pod open-source BSD licencí. Využívá se ve více než 1700 open-source projektech a řadě komerčních produktů. Mezi nejznámější patří výpočetní software Mathematica, balík kancelářských programů OpenOffice a distribuovaná relační databáze Voltdb, která používá HyperSQL při zpracování SQL dotazů. Databázový stroj může být spuštěn jako samostatně běžící server obsluhující klientské aplikace (Client-Server), nebo jako součást Javovské aplikace (embedded mód). V embedded režimu lze pracovat s více databázemi spuštěnými v jedné JVM. V HyperSQL je možné uchovávat data pouze dočasně, po dobu spuštění aplikace (TEMP tabulky), nebo perzistentně s ukládáním na disku 5 http://db.apache.org/derby/ 6 https://collaboration.opengroup.org/dbiop/ 7 http://wiki.apache.org/db-derby/sqlvsderbyfeatures - 12 -
(CACHED a TEXT tabulky), případně uložené v operační paměti (MEMORY tabulky). U MEMORY tabulek je perzistence dat zajištěna použitím souboru s příponou.script, který obsahuje definici tabulek a všechny další SQL dotazy provedené v databázi. Po opětovném spuštění databáze se MEMORY tabulky z tohoto souboru znovu vytvoří. Tento logovací soubor lze využívat také v kombinaci s CACHED a TEXT tabulkami, kde slouží především pro obnovení databáze do konzistentního stavu v případě chyby. Na rozdíl od většiny relačních databází podporuje HyperSQL mnoho standardů jazyka SQL, včetně posledního standardu SQL:2011. Transakce splňují ACID vlastnosti a mohou být zpracovávány vícevláknově. Součástí aplikačního balíku HyperSQL je knihovna SQLTool, umožňující provádění SQL dotazů z příkazového řádku a nástroj Database Manager, poskytující grafické rozhraní pro správu databáze. Obě tyto knihovny mohou být použity pro správu libovolného databázového systému, který umožňuje připojení přes JDBC rozhraní. [Sim14] 3.1.4 H2 H2 (Hypersonic2) pochází od stejného autora jako HyperSQL, nicméně zdrojový kód je napsán zcela od začátku. Z hlediska funkcí jde o velmi podobný SŘBD, doplněný o možnost nativního nebo Apache Lucene fulltextového vyhledávání a přímou podporou clusterování i replikace databáze. Stejně jako v HyperSQL může být databáze spuštěna jako samostatný server, nebo být součástí stejného procesu jako klientská aplikace. Kromě toho je možné pracovat v tzv. mixed módu, kdy lokální aplikace pracuje s embedded databázi a zároveň spustí serverový proces pro obsluhu vzdálených spojení. Kromě Javy může být h2 použita i na platformě.net pomocí rozhraní ADO.NET z projektu h2sharp 8. Transakce jsou atomické, konzistentní a podporují tři různé úrovně izolace. Nicméně, trvalost dat v případě výpadku napájení není zaručena. Při paralelním zpracování transakcí je izolovanost zajištěna exkluzivním zamykáním tabulek pro zápisové operace, alternativně je možné použít mechanismus MVCC, který umožňuje sdílení zámků u vybraných zápisových transakcí, nebo zamykání pouze na úrovni řádků. Databáze může spuštěna v tzv. compatibility módu, kdy se emuluje chování některých vybraných SŘBD s cílem poskytnout přenositelnost aplikace pracující s H2 databází na jiný databázový systém. Podporovány jsou režimy kompatibility pro HyperSQL, Derby, DB2, MySQL, PostreSQL, Oracle a MS SQL. Kompatibilita však rozhodně není absolutní a pokrývá pouze malé množství rozdílných funkcionalit, zejména v oblasti SQL jazyka jednotlivých SŘBD. S databází H2 je k dispozici také nástroj H2 Console. Funguje jako samostatná aplikace a obsahuje vlastní webový server s databází H2 přístupný přes libovolný webový prohlížeč. Aplikaci H2 Console je možné používat také pro přístup k H2 databázi v embedded režimu, nebo libovolné databázi, která podporuje JDBC rozhraní. [H2d15] 8 https://code.google.com/p/h2sharp/ - 13 -
3.1.5 SQLite SQLite 9 je malá databázová knihovna, napsaná v jazyce C, kterou stačí přilinkovat k aplikaci a pomocí jednoduchého rozhraní s ní pracovat. Rozhraní pro přístup k databázi je implementováno pro jazyky C++, Java, Perl, PHP, C# a řadu dalších. Pro použití v Javě je nejvhodnější použít JDBC ovladač xerial 10, který je dostatečně otestován a pravidelně aktualizovaný. Celá databáze je uložena v jediném souboru, který má univerzální formát a může být přenášen mezi libovolnými operačními systémy i nezávisle na endianitě použitého stroje. Podporována je velká část symtaxe standardu SQL-92, indexované vyhledávání, triggery i ACID transakce. Mezi relačními SŘBD uvedenými v této práci je SQLite jediným systémem, umožňujícím sdílení jedné databáze více procesy (v embedded režimu). Nicméně, zápisová operace vyžaduje exkluzivní zamčení databáze pro všechny ostatní transakce včetně čtecích, což se nehodí v aplikacích, které požadují zpracování velkého množství zápisových transakcí. Nasazení SQLite v takových aplikacích se ani nepředpokládá, a proto ani neumožňuje klient-server režim využití databáze. Nejčastěji se používá ve webových aplikacích a embedded zařízeních 11. Je součástí webového prohlížeče Firefox a operačního systému Android [Sqlite15]. 3.2 Objektové databáze 3.1.6 Perst Open-source, embedded objektová databáze s duální licencí, distribuovaná samostatně pro jazyk Java a platformu.net, která je konverzí Java verze do jazyka C#. Pro Javu je na výběr ze tří verzí: Perst 1.5 pro JDK 1.5 a vyšší, Perst 1.4 používaná s JDK 1.4, a Perst Lite, určená pro Java ME 12. Persistence objektů je zajištěna vlastním API, které implementuje část standardu JDO. Perst 13 Nabízí fulltextové vyhledávání, XML import/export objektů, master-slave replikaci i šifrování databáze. K dotazování používá objektový jazyk JSQL, syntakticky vycházející z SQL. Více transakcí může být zpracováváno současně ve vlastních vláknech, umožněno je i sdílení jedné transakce více vlákny. Izolace transakcí je dosažena zamykáním na úrovni objektů. Vyhledávání v 9 https://sqlite.org/ 10 https://bitbucket.org/xerial/sqlite-jdbc 11 https://www.sqlite.org/famous.html 12 Java Micro Edition Verze Javy určená primární k vývoji softwaru pro zařízení s omezenými prostředky. 13 http://www.mcobject.com/perst_eval - 14 -
databázi je založeno na indexovacích algoritmech. Při prohledávání vícerozměrných dat je použit R-tree algoritmus, pokud je potřeba prohledávání podle více kritérií, používá se K-dimensional tree algoritmus. Nejčastěji se databáze Perst využívá v mobilních zařízeních s OS android, nebo webových aplikacích. Společnost McObject nabízí výukové kurzy i placenou technickou podporu. [McO14] [Mco12] 3.1.7 Objectivity DB Distribuovaný, objektový databázový systém plně splňující požadavky standardu ODMG 3.0. K databázi se přistupuje rozhraním ODBC, podporovány jsou jazyky C++,C#, Java, Python, Smalltalk. Objectivity/DB 14 nepracuje jako databázový server. Jedná se o aplikační knihovnu a dva server procesy, které zajišťují obsluhu zámků a manipulaci s daty. K dotazování v jazyce Java je možné použít nativní API, případně samostatně licencovatelný engine pro paralelní zpracování dotazů. Konzistence databáze při souběžném přístupu více uživatelů je zajištěna exkluzivním zamykáním při modifikaci objektů, čtení obsahu objektu může probíhat souběžně z více transakcí. V nabídce je pouze komerční verze systému, jehož možnosti lze otestovat zdarma dostupnou, 60denní trial verzí. V rámci samostatných licencí je nabízena řada sofistikovaných nástrojů např. pro usnadnění vývoje, optimalizaci výkonu, import/export dat mezi databází a XML soubory, replikaci databáze, a mnoho dalších. Zdarma je k dispozici rozsáhlá dokumentace, včetně množství ukázkových příkladů. Mezi společnosti využívající Objectivity/DB se řadí například Ericsson, Siemens nebo Lockheed Martin. [Objectivity15] 3.1.8 ObjectDB V Javě napsaný objektový databázový systém, podporující klient-server, i embedded režim provozu. Nabízena je pouze komerční licence, nicméně v omezené podobě může být využívána bezplatně pro libovolné účely, s omezením velikosti databáze na maximální počet deseti entitních tříd a jednoho milionu objektů. Pro výzkumné a studijní účely lze získat plnou verzi zdarma. ObjectDB umožňuje přístup k datům pomocí rozhraní JDO, nebo JPA. Obě rozhraní nabízí ACID transakce i souběžný přístup více uživatelů. K izolaci transakcí se využívá optimistický / pesimistický model zamykání objektů. Použití rozhraní JPA je výhodné s ohledem na přenositelnost aplikace. Stejné rozhraní totiž typicky implementují ORM nástroje, a tak lze v případě nutnosti snadno přejít na relační databázi. Vzhledem k objektovému modelu odpadá režie spojená s mapováním Java objektů, které provádí ORM nástroje, díky čemuž 14 http://www.objectivity.com/products/objectivitydb/ - 15 -
dosahuje ObjectDB výrazně lepších výkonnostních výsledků, než ostatní poskytovatelé JPA. 15 Dotazovací jazyk záleží na použitém rozhraní. Pro JDO se nabízí JDOQL, s rozhraním JPA je spojen jazyk JPQL. [Obj15] [Obje15] Hlavní nevýhody spojené s použitím ObjectDB jsou následující: Chybějící podpora integritních omezení. Je na zodpovědnosti programátora zajistit kontrolu integrity databáze na straně aplikace. Absence oficiální dokumentace. Na webových stránkách projektu je pouze stručný popis systému, a elementárních příkladů užití. Podporovány jsou pouze JVM programovacími jazyky Java, Groovy, Scala, Jruby apod. Ve vývoji je verze pro platformu.net. [Obj15] [Obje15] 3.3 Key/Value databáze 3.1.9 Oracle Berkeley DB Java Edition Původní verze byla vydána v roce 1994 na univerzitě v Berkeley, a je napsána kompletně v jazyce C. V současnosti patří Oracle Berkeley DB pod společnost Oracle, která ji nabízí ve třech různých verzích původní Oracle Berkeley DB, v Javě napsanou verzi Oracle Berkeley DB Java Edition a Oracle Berkeley DB XML, která je určena pro práci s XML dokumenty. Všechny tři verze jsou pro nekomerční využití dostupné pod open-source licencí. K použití v rámci proprietárního softwaru je nutné koupit licenci, která se pohybuje od 26000 Kč/procesor 16. Pro práci s databází jsou v Java Edition (JE) určena dvě různá rozhraní: Direct Persistence Layer (DPL) pro práci s POJO objekty. Rozhraní pro práci s libovolnými daty jako s páry klíč/hodnota. Přenositelnost databázových souborů mezi JE a původní verzí Berkeley DB není možná z důvodu jejich odlišných formátů. Nicméně, součástí API jsou funkce umožňující import/export dat mezi nimi. [Oracle15] 15 Srovnání výkonu ObjectDB s vybranými relačními databázemi a ORM nástroji: http://www.jpab.org/. 16 https://shop.oracle.com/pls/ostore/f?p=dstore:2:0::no:rir,rp,2:prod_hier_id:4509887109971805 720003-16 -
3.1.10 BangDB Open-source key/value úložiště od společnosti Iqlect, kompletně napsané v jazyce C++. Klient Pro použití v jazyce Java je zatím dostupný pouze pro platformu Linux. BangDB je nabízena ve dvou rozdílných verzích BangDB embedded, která může fungovat jako perzistentní, nebo cache úložiště a BangDB Client-server, pro síťové sdílení databáze. API pro práci s daty podporuje základní CRUD operace, tvorbu dotazů na základě omezení rozsahem vybrané hodnoty (range query), třídění a další zpracování výsledků dotazů. Součástí API jsou různé možnosti pro analýzu dat, například třídění podle doby vzniku, sledování TopK 17 položek a některé další. Transakce splňují ACID vlastnosti a mohou probíhat paralelně ve více vláknech. Izolovanost souběžně zpracovávaných transakcí zajišťuje optimistický model zamykání (OCC). Pro zvýšení odolnosti vůči ztrátě dat je možné zapisovat veškeré změny v databázi, před jejich provedením, do speciálního souboru, který se použije pro obnovu konzistence dat v případě, že dojde k nečekané havárii databáze. Obě verze BangDB jsou dostupné zdarma v rámci BSD licence. Do budoucna plánuje společnost Iqlect vydání placené verze databázového systému. [Iqlect14] 3.1.11 LevelDB Embedded key/value uložiště od společností Google, která jej v roce 2011 uvolnila pod BSD licencí. [Dea11] Využívá se například v prohlížeči Google Chrome, pro ukládání bitcoinových transakcí (verze LevelDB pro Node.js), a také v key/value databázi Riak. Level DB je napsána v jazyce C++. Pro použití s Javou je nutné použít dostupné Java API 18, nebo do Javy přepsaný port Dain Leveldb 19, který ale neposkytuje všechny funkcionality originálu. Data jsou ukládána v seřazeném pořadí podle klíče a automaticky kompresována použitím kompresního algoritmu z knihovny Snappy 20. Pro manipulaci s daty je určeno vlastní jednoduché API, LevelDB nemá žádný dotazovací jazyk a neumožňuje indexaci (ani automatickou). Databáze nemůže být sdílena více procesy, nicméně transakce mohou probíhat souběžně v různých vláknech. Automatická synchronizace vláken je prováděna pouze pro čtecí a některé zápisové operace. U ostatních zápisových operací musí být zajištěna externě. [LevelDB] [Sin12] [Dea] 17 Analýza top položek za vybrané časové období. Například 10 nejčastěji vykonávaných dotazů, uživatelé s největším počtem položek v nákupním košíku, nejčastěji vyhledávané produkty apod. [Iqlect14] 18 https://github.com/fusesource/leveldbjni 19 https://github.com/dain/leveldb 20 https://code.google.com/p/snappy/ - 17 -
3.4 Sloupcové databáze 3.1.12 HBase HBase se nejčastěji využívá v kombinaci s HDFS 21 a dalšími nástroji z frameworku Apache Hadoop 22, jako distribuovaná databáze. Kromě toho může být využita i jako embedded databáze (stand-alone mod), kdy se místo HDFS používá lokální datové úložiště. HBase je napsána pro použití v jazyce Java, procesy z jiných programovacích jazyků se mohou k databázi připojit prostřednictvím rozhraní Apache Thrift 23. V distribuované verzi je podporována master-slave replikace i sharding 24 databáze mezi jednotlivé uzly clusteru. K manipulaci s daty slouží čtyři základní operace get, put, scan, delete. SQL jazyk není podporován, nicméně je možné použít například Apache Hive 25, umožňující automatický převod SQL dotazů v rámci platformy Apache Hadoop. Hbase je použita v celé řadě známých projektů, například Facebook ji využívá při uchovávání zpráv (SMS, emaily, chatovací systém 26 ). Vyhledávač Yahoo! u systému na detekci duplicitních dokumentů, Twitter pro vyhledávání uživatelů, zálohu dat a některé další operace. [Apa15] [ApaW15] 3.1.13 Cassandra Cassandra původně vznikla pro sociální síť Facebook, kde se využívala při vyhledávání v příchozích zprávách (později nahrazeno HBase). [Str11] V roce 2008 byl zdrojový kód zveřejněn a nyní je k dispozici v rámci opensource licence Apache 27. Mimo to existují také dvě distribuce od společnosti Datastax základní Community Edition a komerční Enterprise Edition, která je doplněná o řadu sofistikovaných nástrojů pro analýzu dat a optimalizaci výkonu 28. Společnost Datastax nabízí také výukové kurzy a další komerční podporu pro svoji Entreprise distribuci Cassandry. 21 Hadoop Distributed Filesystem. Souborový systém pro distribuované zpracování souborů. Je součástí frameworku Apache Hadoop. 22 https://hadoop.apache.org/ 23 http://wiki.apache.org/hadoop/hbase/thriftapi 24 Používá se při horizontálním škálování databáze s cílem rozložit zátěž mezi více serverů a zlepšit tak rychlost přístupu k datům. Na rozdíl od replikace má každý uzel pouze část dat, nikoliv celou kopii databáze. [CodeF14] 25 https://hive.apache.org/ 26 https://code.facebook.com/posts/321111638043166/hydrabase-the-evolution-of-hbase-facebook/ 27 http://cassandra.apache.org/ 28 http://www.datastax.com/download/dse-vs-dsc - 18 -
Datový model Cassandry je kombinací mezi key/value a sloupcovým úložištěm, inspirovaný distribuovanými systémy Amazon Dynamo a Google BigTable. Jednotlivé uzly v clusteru mohou být použity i jako embedded server 29, s perzistentním ukládáním dat na lokální disk nebo jejich udržováním v operační paměti. Cassandra nemá ACID transakce, místo toho se zaměřuje na eventuální konzistenci, která poskytuje lepší škálovatelnost. Používá vlastní dotazovací jazyk Cassandra Query Language (CQL), syntakticky vycházející z SQL. V současnosti patří Cassandra mezi nejpopulárnější distribuované databázové systémy. Je využívána více než 1500 30 společnostmi, mezi nimiž jsou například ebay, Netflix, Spotify nebo Adobe. [Str11] [Dat15] 3.5 Grafové databáze 3.1.14 Neo4j Společnost NeoTechnology je s produktem Neo4j jedničkou na poli grafových databázových systémů. Do vývoje technologie bylo investováno přes 20 milionů dolarů, počet komerčních i open-source projektů využívajících Neo4j roste. Odhaduje se, že v roce 2017 bude Neo4j využívat alespoň 25 % všech globálních společností. Na oficiálních stránkách NeoTechnology jsou ke stažení dvě edice Neo4j Community a Enterprise. Obě jsou dostupné zdarma pod open-source licencí. Použití Neo4j Enterprise pro komerční účely vyžaduje zakoupení licence, zdarma lze vyzkoušet 30denní trial verzi. Ukládání dat je ve formě tzv. property graphs, kde každý vrchol i hrana může obsahovat další údaje (vlastnosti) a může mít přidělen typ (label), který se využívá například pro indexované prohledávání grafu. Maximální velikost grafu je omezena na 34 miliard uzlů, stejný počet hran a 68 miliard vlastností. Databázový systém může být spuštěn jako server přístupný přes REST API rozhraní, nebo v embedded režimu pro lokální připojení k databázi. V distribuovaném systému může každý stroj v Neo4j clusteru fungovat jako Clientserver, nebo embedded instance. Transakce provádějící čtení mohou probíhat souběžně ve více vláknech bez použití zámků. Zapisovací transakce používají pro zajištění konzistence dat zamykání vrcholů nebo hran, které modifikují. Čtecí transakce mohou přistupovat k objektům grafu i v případě, že jsou uzamčeny pro zápis. Pro práci s grafem lze použít nativní deklarativní jazyk Cypher, jehož syntaxe se velmi podobá jazyku SQL. Kromě jednoduchých CRUD operací se Cypher používá pro hledání vzorů v grafové struktuře (pattern matching dotazy), správu indexů a integritních omezení. Druhou možností je imperativní jazyk Gremlin, který využívá rozhraní Blueprints 31 a je tak nezávislý na použité grafové databázi. Celý graf je uložen perzistentně na disku, v operační paměti jsou udržovány nejčastěji zpracovávané části grafu. Transakce 29 http://wiki.apache.org/cassandra/embedding 30 http://planetcassandra.org/companies/ 31 https://github.com/tinkerpop/blueprints - 19 -