Západočeská univerzita v Plzni Fakulta aplikovaných věd Katedra informatiky a výpočetní techniky

Za´padoˇceska´ univerzita v Plzni Fakulta aplikovanyćh vˇed Katedra informatiky a vy´poˇcetn´ı techniky

Diplomov´ a pr´ ace Modelov´ an´ı v grafov´ e nerelaˇ cn´ı datab´ azi

Plzeˇ n 2013

Milan Beˇcváˇr

Prohl´ aˇ sen´ı Prohlaˇsuji, ˇze jsem diplomovou práci vypracoval samostatnˇe a v´ yhradnˇe s pouˇzit´ım citovan´ ych pramen˚ u. V Plzni dne 16. kvˇetna 2013 Milan Beˇcváˇr

Podˇ ekov´ an´ı Dˇekuji vedouc´ımu diplomové práce panu Ing. Romanovi Mouˇckovi, Ph.D. za vstˇr´ıcn´ y pˇr´ıstup, uˇziteˇcné rady a pˇripom´ınky pˇri zpracován´ı mé diplomové práce.

Abstract This master thesis looks into non-relational databases focused on graph databases and choice of the most suitable of them. After that, an analysis of EEG/ERP data model is made and suitable subset is chosen. Then a data model is designed and implemented in the selected non-relational database. Finally, the selected non-relational database is tested together with the relational one and the attained results are evaluated. Neo4j is evaluated as the suitable non-relational database from the viewpoint of flexibility and speed of executing queries. That is why it was recommended for deployment at EEG/ERP portal. Tato diplomová práce se zab´ yvá nerelaˇcn´ımi databázemi se zamˇeˇren´ım na grafové databáze a následn´ ym v´ ybˇerem nejvhodnˇejˇs´ı z nich. Posléze je provedena anal´ yza datového modelu EEG/ERP portálu a v´ ybˇer vhodné podmnoˇziny. Následnˇe je ve vybrané nerelaˇcn´ı databázi navrˇzen a implementován datov´ y model. Nakonec je vybraná nerelaˇcn´ı databáze otestována s databáz´ı relaˇcn´ı a zhodnot´ı se dosaˇzené v´ ysledky, které vyhodnotily jako vhodnou nerelaˇcn´ı databázi z hlediska flexibility a rychlosti vykonán´ı dotaz˚ u právˇe Neo4j, a ta byla doporuˇcena pro nasazen´ı v rámci EEG/ERP portálu.

Obsah ´ 1 Uvod

1

2 NoSQL datab´ aze 2.1 Charakteristika a motivace . . . . . . 2.2 ACID . . . . . . . . . . . . . . . . . 2.3 CAP Teorém . . . . . . . . . . . . . 2.4 Dotazován´ı . . . . . . . . . . . . . . ˇ alován´ı . . . . . . . . . . . . . . . 2.5 Sk´ 2.6 Pouˇzit´ı v praxi . . . . . . . . . . . . 2.7 Srovnán´ı s relaˇcn´ımi databázemi . . . 2.8 Datov´ y model . . . . . . . . . . . . . 2.9 Grafové databáze . . . . . . . . . . . 2.9.1 Neo4j . . . . . . . . . . . . . 2.9.2 OrientDB . . . . . . . . . . . 2.9.3 DEX . . . . . . . . . . . . . . 2.10 Obecné srovnán´ı nerelaˇcn´ıch databáz´ı 3 Neo4j 3.1 Základn´ı charakteristika . . . . 3.2 Datov´ y model . . . . . . . . . . 3.2.1 Vrcholy (nodes) . . . . . 3.2.2 Hrany (relationships) . . 3.2.3 Vlastnosti (properties) . 3.3 Procházen´ı grafem a dotazován´ı 3.3.1 Cypher . . . . . . . . . . 3.3.2 Gremlin . . . . . . . . . 3.3.3 Traversal Framework . . 3.3.4 Grafové algoritmy . . . . 3.4 Integrace a nasazen´ı . . . . . . 3.4.1 Instalace . . . . . . . . . 3.4.2 Licence . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

2 2 3 4 5 5 5 6 7 8 10 10 10 11

. . . . . . . . . . . . .

12 12 13 13 13 14 15 16 16 17 19 20 20 20

3.5

3.4.3 Systémové poˇzadavky 3.4.4 Nasazen´ı . . . . . . . . Vizualizaˇcn´ı nástroje . . . . . 3.5.1 Web admin Neo4j . . . 3.5.2 Neoclipse . . . . . . . 3.5.3 Gephi . . . . . . . . .

. . . . . .

4 EEG/ERP port´ al 4.1 Vize portálu . . . . . . . . . . . 4.2 Popis portálu . . . . . . . . . . 4.2.1 Role portálu . . . . . . . 4.3 Anal´ yza datového schématu . . 4.4 V´ ybˇer vhodné podmnoˇziny . . . 4.4.1 Popis vybran´ ych tabulek

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

21 21 22 22 22 23

. . . . . .

24 24 24 25 27 28 30

5 Generov´ an´ı testovac´ıch dat 32 5.1 Datanamic Data Generator for Oracle . . . . . . . . . . . . . . 32 5.1.1 Postup vygenerován´ı dat . . . . . . . . . . . . . . . . . 32 6 N´ avrh datov´ eho modelu v Neo4j 34 6.1 Mapován´ı z datového schématu relaˇcn´ı databáze . . . . . . . . 34 6.2 Schéma datového modelu . . . . . . . . . . . . . . . . . . . . . 35 6.3 Popis datového modelu . . . . . . . . . . . . . . . . . . . . . . 36 7 Implementace datov´ eho modelu v Neo4j 37 7.1 Pouˇzité technologie . . . . . . . . . . . . . . . . . . . . . . . . 37 7.2 Popis implementace . . . . . . . . . . . . . . . . . . . . . . . . 37 8 Testov´ an´ı a zhodnocen´ı v´ ysledk˚ u 8.1 Testován´ı . . . . . . . . . . . . . . 8.1.1 Flexibilita datového modelu 8.1.2 Rychlost vykonán´ı dotaz˚ u . 8.2 Zhodnocen´ı v´ ysledk˚ u . . . . . . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

40 40 41 42 50

9 Z´ avˇ er

52

Literatura

53

A Uˇ zivatelsk´ a dokumentace 55 A.1 Pˇr´ıprava nástroj˚ u pro testován´ı . . . . . . . . . . . . . . . . . 55 A.2 Spuˇstˇen´ı testován´ı . . . . . . . . . . . . . . . . . . . . . . . . . 56 A.2.1 Testován´ı databáze Oracle . . . . . . . . . . . . . . . . 56

A.2.2 Testován´ı databáze Neo4j . . . . . . . . . . . . . . . . 57 B Sch´ ema grafov´ e struktury v Neo4j

59

C Obsah pˇ riloˇ zen´ e CD 61 C.1 Struktura aplikace Neo4j Graph Database Creating . . . . . . 61

´ 1 Uvod V praxi mohou nastat situace, kdy nám jiˇz pˇrestane vyhovovat stávaj´ıc´ı datov´ y model relaˇcn´ı databáze. D˚ uvodem m˚ uˇze b´ yt pevnˇe stanovené datové schéma, které je v pˇr´ıpadˇe relaˇcn´ıch databáz´ı tvoˇreno tabulkami nebo velk´ y objem uchovávan´ ych dat. Z tohoto d˚ uvodu je vhodnˇejˇs´ı zvolit nerelaˇcn´ı databáze. Nerelaˇcn´ı neboli NoSQL databáze mohou ukládat data do r˚ uzn´ ych struktur (graf, xml dokument, kl´ıˇc / hodnota, apod.) a jsou schopné pracovat s obrovsk´ ym mnoˇzstv´ı dat (zejména Big data1 ). V souˇcasné dobˇe se vyuˇz´ıvaj´ı hlavnˇe v oblasti cloud computingu, sociáln´ıch s´ıt´ı, apod. Nápln´ı této diplomové práce je prostudovat moˇznosti, které nab´ızej´ı nerelaˇcn´ı databáze a prorovnat je s databázemi relaˇcn´ımi. Zamˇeˇrit se na databáze umoˇzn ˇuj´ıc´ı pˇr´ımo ukládat grafové struktury (dále jen grafové databáze) a vybrat jednu z nich pro návrh a implementaci podmnoˇziny datového schématu EEG/ERP portálu. Takto vytvoˇrenou grafovou databázi otestovat s databáz´ı relaˇcn´ı a zhodnotit dosaˇzené v´ ysledky. Na základˇe zhodnocen´ı dosaˇzen´ ych v´ ysledk˚ u rozhodnout, která databáze je vhodnˇejˇs´ı a proˇc. Práce je ˇclenˇena do nˇekolika kapitol. Prvn´ı kapitola se vˇenuje nerelaˇcn´ım databáz´ım, napˇr. moˇznost´ı dotazován´ı, ˇskálován´ı a pouˇzit´ı v praxi. Dále je uveden pˇrehled základn´ıch typ˚ u nerelaˇcn´ıch databáz´ı a následné zamˇeˇren´ı na grafové databáze, ze kter´ ych jsou vybrány tˇri zástupci a u kaˇzdého z nich je uvedena základn´ı charakteristika. Druhá kapitola se zab´ yvá v´ ybˇerem vhodné grafové databáze a detailn´ı seznámen´ı se n´ı. Dalˇs´ı ˇctyˇri kapitoly jsou vˇenovány anal´ yze datového schématu EEG/ERP portálu a v´ ybˇerem vhodné podmnoˇziny. Souˇcást´ı anal´ yzy je generován´ı testovac´ıch dat do datového schématu EEG/ERP portálu. Na základˇe této anal´ yzy se v dalˇs´ı kapitole navrhne datov´ y model grafové databáze a poté naimplementuje. Posledn´ı se zab´ yvá samotn´ ym otestován´ım relaˇcn´ı databáze s databáz´ı nerelaˇcn´ı. Testuj´ı se dva hlavn´ı poˇzadavky - flexibilita datového modelu a rychlost vykonán´ı dotaz˚ u. Na konci této kapitoly jsou zhodnoceny dosaˇzené v´ ysledky, podle nichˇz se rozhodne, která z testovan´ ych databáz´ı je vhodnˇejˇs´ı. Dodatek k této diplomové práci tvoˇr´ı kapitoly pˇr´ıloh, které obsahuj´ı uˇzivatelskou dokumentaci popisuj´ıc´ı cel´ y postup testován´ı, dále schéma grafové databáze vˇcetnˇe rozˇs´ıˇren´ı datového modelu a popis obsahu pˇriloˇzeného CD. 1

Big data - oznaˇcuje soubory dat, jejichˇz velikost je mimo schopnosti zachycovat, spravovat a zpracov´ avat data bˇeˇznˇe pouˇz´ıvan´ ymi softwarov´ ymi prostˇredky v rozumném ˇcase.

1

2 NoSQL databáze Pojem NoSQL oznaˇcuje velmi poˇcetnou skupinu nerelaˇcn´ıch databáz´ı. Tyto databáze na rozd´ıl od relaˇcn´ıch databázé nepouˇz´ıvaj´ı dotazovac´ı jazyk SQL. Neznamená to tedy, ˇze by vˇsechna datová u ´loˇziˇstˇe spadaj´ıc´ı do této skupiny odm´ıtala SQL, jak by mohl název NoSQL naznaˇcovat. Ve skuteˇcnosti pojem NoSQL b´ yvá databázovou komunitou vysvˇetlován jako no only SQL” (v ” pˇrekladu nejen SQL”). ” Pˇredevˇs´ım se jedná o alternativn´ı pˇr´ıstup ukládán´ı dat do databáze jin´ ym zp˚ usobem neˇz jak´ ym ho ukládaj´ı databáze relaˇcn´ı, kter´ y m˚ uˇze b´ yt v nˇekter´ ych pˇr´ıpadech vhodnˇejˇs´ı. Z tohoto d˚ uvodu nemus´ıme pouˇz´ıvat jen zabˇehlé relaˇcn´ı databázové systémy, ale v urˇcit´ ych pˇr´ıpadech, kdy se nehod´ı relaˇcn´ı (tabulkov´ y) model databáze, vyuˇz´ıt nerelaˇcn´ı databáze. Pˇresnˇejˇs´ı definice je takováto: ”NoSQL datab´ aze je software pro persistenci dat, kter´ y je alternativou ke klasick´ ym relaˇ cn´ım datab´ az´ım”.[6]

2.1

Charakteristika a motivace

• Vysoká ˇskálovatelnost (vertikálnˇe, horizontálnˇe) • Snadná podpora replikac´ı a distribuce dat • Flexibiln´ı schéma, semistrukturovaná data ˇ asteˇcné vyuˇzit´ı ACID1 (transakˇcn´ıho zpracován´ı) • C´ • Podpora systému transakc´ı BASE2 (opakem ACID) • CAP teorém3 • Asynchronn´ı vkládán´ı, aktualizace dat • Vˇetˇsina NoSQL databáz´ı jsou Open Source

1

ACID (Atomicity, Consistency, Isolation, Durability) BASE (Basically Available, Soft-state, Eventually Consitent) 3 CAP teorém (Consistency, Availability, Partition Tolerance) 2

2

NoSQL databáze

ACID

Bezschémové nerelaˇcn´ı databáze jsou stavˇené tak, aby byly rychlé, dokázaly zvládnout obrovské objemy dat a dokázaly tolerovat v´ ypadek s´ıtˇe. Na u ´kor datové konzistence, tzn. data nejsou pro vˇsechny uˇzivatele v jednu chv´ıli stejná, ale ˇcasem” se srovnaj´ı, tzn. uˇzivatelé maj´ı k dispozici stejná data. ” Hlavn´ı motivac´ı NoSQL databáz´ı je dosaˇzen´ı horizontáln´ı ˇskálovatelnosti4 databázového zpracován´ı v dynamickém prostˇred´ı distribuovan´ ych databáz´ı, které obsahuj´ı semistrukturovaná data bez pevného databázového schématu. V nerelaˇcn´ıch databázov´ ych systémech se obvykle neˇreˇs´ı transakˇcn´ı zpracován´ı (ACID), referenˇcn´ı integrita, atd. Rychlost vykonáván´ı dotaz˚ u u NoSQL databáz´ı je v´ yraznˇe lepˇs´ı neˇz u robustnˇejˇs´ıch relaˇcn´ıch databáz´ıch.

2.2

ACID

Jedná se o základn´ı funkcionalitu databázového systému zajiˇst’uj´ıc´ı transakˇcn´ı zpracován´ı, kdy je potˇreba, aby data byla konzistentn´ı a pˇri v´ yskytu chyby bylo moˇzné vrátit celou operaci do p˚ uvodn´ıho stavu. Mezi hlavn´ı vlastnosti transakˇcn´ıho zpracován´ı patˇr´ı: • Atomicita (Atomicity) - v transakci probˇehnout bud’ vˇsechny operace nebo ˇza´dná (kaˇzdá transakce je atomická) • Konzistence (Consistency) - systém mus´ı zajistit, aby data byla konzistentn´ı (v´ ysledkem transakce jsou platná data) • Izolace (Isolation) - transakce se nevzájem neovlivˇ nuj´ı, napˇr. pˇri paraleln´ım zpracován´ı • Trvalost (Durability) - zmˇeny zapsané u ´spˇeˇsnou transakc´ı jsou v databázi uloˇzeny natrvalo Databázov´ y systém splˇ nuj´ıc´ı vˇsechny ˇctyˇri vlastnosti ACID transakc´ı se naz´ yvá silnˇe konzistentn´ı”. Tyto databázové systémy jsou potˇreba jen v ur” ˇcit´ ych pˇr´ıpadech, napˇr. pˇri pouˇz´ıt´ı v bankách a obchodech. Systémy, které ne zcela podporuj´ı ACID vlastnosti se naz´ yvaj´ı pˇr´ıpadnˇe konzistentn´ı”. V ” pˇr´ıpadˇe u ´myslného zanedbán´ı silné konzistence” lze z´ıskat v´ıce dostupnosti a ” t´ım i v´ yhodu lepˇs´ı ˇskálovatelnosti. Tento pˇr´ıstup bez silné konzistence”, ˇcasto ” vyuˇz´ıvaj´ı právˇe NoSQL databáze. [6] 4

Horizont´ aln´ı ˇsk´ alov´ an´ı - rozdˇelen´ı v´ ypoˇctu na paraleln´ı u ´lohy mezi v´ıce server˚ u

3

NoSQL databáze

2.3

CAP Teorém

CAP Teor´ em

CAP teorém se pouˇz´ıvá pˇri navrhován´ı distribuovaného systému a obsahuje tˇri základn´ı poˇzadavky na konzistenci, dostupnost a odolnost proti v´ ypadku s´ıtˇe. CAP teorém ˇr´ıká, ˇze neexistuje distribuovan´ y systém, kter´ y by splˇ noval vˇsechny tˇri poˇzadavky najednou. Poˇzadavky na distribuované prostˇred´ı: • Konzistence (Consistency) - znamená, ˇze v urˇcitém ˇcase vˇsechny uzly distribuovaného systému vid´ı stejná data. • Dostupnost (Availability) - znamená, ˇze kaˇzd´ y klient po svém dotazu dostane informaci o tom, zda-li byla operace u ´spˇeˇsná, nebo ne´ uspˇeˇsná. • Tolerance rozdˇelen´ı s´ıtˇe (Partition Tolerance) - znamená, ˇze pokud ˇca´st s´ıtˇe vypadne (pˇreruˇs´ı se spojen´ı, anebo dojde ke ztrátˇe pˇrenosu mezi uzly), systém bude stále schopn´ y odpov´ıdat na dotazy. Ve skuteˇcnosti je nemoˇzné vytvoˇrit návrh distribuovaného systému, kter´ y splˇ nuje dvˇe z vlastnost´ı CAP teorému. Tuto skuteˇcnost dokazuje Obrázek 2.1, kde je vyznaˇceno nˇekolik databázov´ ych systém˚ u, pˇredevˇs´ım z ˇrad pˇredn´ıch zástupc˚ u NoSQL databáz´ı, které spadaj´ı do skupiny splˇ nuj´ı dvˇe ze tˇr´ı vlastnost´ı CAP teorému. [3]

Obrázek 2.1: Obecné znázornˇen´ı CAP Brewerova teorému v NoSQL.[12]

4

NoSQL databáze

2.4

Dotazován´ı

Dotazov´ an´ı

V NoSQL databáz´ıch je dotazován´ı nejménˇe propracovanou ˇcást´ı. Nad nˇekter´ ymi NoSQL databázemi se lze dotazovat jazykem SQL, avˇsak pouze jeho omezenou formou (SimpleDB, OrientDB). V této omezené formˇe nen´ı k dispozici napˇr. operace spojen´ı, agregace a zanoˇrován´ı dotaz˚ u, které lze nalézt u dotazovac´ıch jazyk˚ u GOL (Google Query Language) nebo HQL (Hypertext Query Language). Oba tyto dotazovac´ı jazyky jsou podmnoˇzinou jazyka SQL. Operace spojen´ı (JOIN) a ˇrazen´ı (ORDER BY) nejsou v NoSQL podporovány, a to z d˚ uvodu horizontáln´ıho ˇskálován´ı dat (viz ˇskálován´ı). Do budoucna je v´ıce neˇz pravdˇepodobné, ˇze bude vytvoˇren nˇejak´ y standardizovan´ y dotazovac´ı jazyk pouˇziteln´ y pro celou skupinu NoSQL.[6]

2.5

ˇ alov´ Sk´ an´ı

Relaˇcn´ı databáze jsou ve vˇetˇsinˇe pˇr´ıpad˚ u um´ıstˇeny na jednom serveru a provád´ı se tzv. vertikáln´ı ˇskálován´ı (scale-up), které funguje na principu pˇridán´ı v´ıce procesor˚ u nebo v´ıce vnitˇrn´ı ˇci vnˇejˇs´ı pamˇeti. Druh´ ym zp˚ usobem je ˇskálovat data horizontálnˇe (scale-out), coˇz pˇrináˇs´ı v´ yhodu v rozdˇelen´ı v´ ypoˇctu na paraleln´ı u ´lohy mezi v´ıce server˚ u. Tento prostˇredek ˇskálován´ı se obzvláˇstˇe pouˇz´ıvá ve spojitosti s NoSQL databázemi. Data v NoSQL databáz´ıch mohou b´ yt ˇskálována i vertikálnˇe a to tak, ˇze se rozdˇel´ı záznam na ˇcásti, pˇriˇcemˇz kaˇzdá z nich je uloˇzena na jiném uzlu. Horizontáln´ı ˇskálován´ı zároveˇ n komplikuje dosaˇzen´ı ACID vlastnost´ı.[6]

2.6

Pouˇ zit´ı v praxi

Rozhodován´ı, kdy pouˇz´ıt ovˇeˇrené relaˇcn´ı databáze nebo neznámou NoSQL databázi, nen´ı jednoduché. V tomto pˇr´ıpadˇe hraje roli jak technická tak i ekonomická stránka. D˚ uvodem je také to, ˇze NoSQL databáze jsou relativnˇe mladou technologi´ı, která se poˇrád vyv´ıj´ı. NoSQL databáze nemaj´ı takové moˇznosti pˇri dotazován´ı jako databáze relaˇcn´ı, napˇr. pokud aplikace podporuje jedinou DB operaci, a to uloˇzen´ı ˇrádku a jeho naˇcten´ı podle nˇejakého ID. To vede k tomu, ˇze na aplikaci je pˇrenáˇsena odpovˇednost v podobˇe generován´ı sekundárn´ıch index˚ u, která je (vˇetˇsinou) souˇca´st´ı databázového enginu. V pˇr´ıpadˇe pouˇzit´ı NoSQL by muselo doj´ıt k pˇredˇelán´ı celé aplikace. 5

NoSQL databáze

Srovnán´ı s relaˇcn´ımi databázemi

NoSQL databáze je doporuˇceno pouˇz´ıvat v situaci, která nám umoˇzn ˇuje snadné vytvoˇren´ı datového modelu, nejlépe od zaˇcátku v´ yvoje. Jelikoˇz náklady spojené s pˇrechodem na NoSQL databáze mohou b´ yt vysoké (ˇskolen´ı programátor˚ u, správa SW v infrastruktuˇre, záloha, apod.). Databázové systémy patˇr´ıc´ı do NoSQL nacházej´ı uplatnˇen´ı nejˇcastˇeji v cloud computingu, aplikac´ıch web 2.05 a hlavnˇe v sociáln´ıch s´ıt´ıch (Facebook, Twitter), kde horizontáln´ı ˇskálován´ı zahrnuje obrovské mnoˇzstv´ı uzl˚ u. Mezi klienty vyuˇz´ıvaj´ıc´ı NoSQL patˇr´ı spoleˇcnosti Adobe, Mozilla, Google a LinkedIn. U vˇsech tˇechto zm´ınˇen´ ych oblast´ı pouˇzit´ı lze oˇcekávat velk´ y provoz, tud´ıˇz velk´ y objem ukládan´ ych dat, které je nutné zpracovat, a proto je v´ yhodnˇejˇs´ı pouˇz´ıt právˇe NoSQL databáze.

2.7

Srovn´ an´ı s relaˇ cn´ımi datab´ azemi

Relaˇcn´ımi databázemi jsou naz´ yvané takové databázové systémy, u kter´ ych ˇ jsou data organizována a ˇr´ızena SRBD (Systém ˇr´ızená báze dat). Datové schéma pro ukládán´ı dat reprezentuje tabulka, která obsahuje ˇrádky, sloupce a vztahy mezi jednotliv´ ymi tabulkami. Relaˇcn´ı databáze vycházej´ı z datov´ ych model˚ u a schémat, do nichˇz ukládáme data z reálného svˇeta. Jeho dotazovac´ım jazykem je SQL, kter´ y je standardizován. Nejvˇetˇs´ı v´ yhodou relaˇcn´ıch databáz´ı je snadná transformace objekt˚ u z reálného svˇeta (tak, jak je vid´ı ˇclovˇek) do tabulkového schématu. I relaˇcn´ı databáze maj´ı své nev´ yhody. Nad urˇcitou mez´ı objemu poˇzadavk˚ u lze narazit na zásadn´ı v´ ykonnostn´ı limit, kter´ y má za následek horˇs´ı ˇskálovatelnost a sn´ıˇzen´ı rychlosti vykonan´ ych dotaz˚ u nad databáz´ı. Sloˇzitˇeji se distribuj´ı (sharding) a pro velké weby (Facebook, Google, Twitter) jiˇz nestaˇc´ı z d˚ uvodu uchováván´ı a zpracován´ı velkého objemu dat, kter´ y roste exponenciálnˇe. Nejvˇetˇs´ım u ´skal´ım relaˇcn´ıch databáz´ı jsou samotné vztahy mezi tabulkami, a to v pˇr´ıpadˇe, kdy se dotazujeme databázového serveru na data z v´ıce tabulek, kdy je potˇreba dané tabulky mezi sebou propojit. K propojen´ı v´ıce jak jedné tabulky se pouˇz´ıvá pˇr´ıkaz JOIN, kter´ y je souˇca´st´ı dotazovac´ıho jazyka SQL. Pˇri nadmˇerném pouˇzit´ı tohoto pˇr´ıkazu m˚ uˇze docházet k v´ yraznému sn´ıˇzen´ı rychlosti pˇri vykonán´ı dotazu nad v´ıce tabulkami.

5

Web 2.0 - webové str´ anky obsahuj´ıc´ı prostor pro sd´ılen´ı a spoleˇcnou tvorbu obsahu.

6

NoSQL databáze

Datový model

NoSQL databáze byly popsány na zaˇcátku této kapitoly. V této ˇca´sti se budu zab´ yvat sp´ıˇse v´ yhodami oproti relaˇcn´ım databáz´ım. V souˇcasné dobˇe se mus´ıme pot´ ykat s problémem, jak´ ym zp˚ usobem uchovávat a zpracovávat velké mnoˇzstv´ı dat, které poˇrád nar˚ ustá. Pˇr´ıkladem zpracován´ı a uchován´ı velkého objemu dat jsou napˇr. osobn´ı u ´daje o uˇzivatel´ıch (napˇr. Facebook), sociáln´ı grafy, geolokace, uˇzivatelsky generovan´ y obsah, atd. Problém je v tom, ˇze zpracovávat takové mnoˇzstv´ı dat v relaˇcn´ıch databáz´ıch je velmi nákladné a ˇcasto to má neblah´ y vliv na v´ ykon celé databáze. Pro tyto u ´ˇcely byla vytvoˇrena nová skupina nerelaˇcn´ıch databáz´ıch zvaná NoSQL. NoSQL databáze nemaj´ı oproti klasick´ ym relaˇcn´ım databázov´ ym systém˚ um pevnˇe stanovéná schémata pro ukládán´ı dat. Pro kaˇzdou situaci se hod´ı pouˇz´ıt jinou nerelaˇcn´ı databázi, která obsahuje jin´ y datov´ y model, napˇr. grafová, dokumentovˇe orientovaná, sloupcová, atd. Nev´ yhodou je pouˇzit´ı r˚ uzn´ ych dotazovac´ıch jazyk˚ u pro r˚ uzné nerelaˇcn´ı databáze oproti standardizovanému dotazovac´ımu jazyku SQL, kter´ y pouˇzivá vˇetˇsina relaˇcn´ıch databáz´ı.

2.8

Datov´ y model

Ve svˇetˇe databáz´ı se k popisu databáze vyuˇz´ıvá datov´ y (logick´ y) model. NoSQL uznává jin´ y pˇr´ıstup, kter´ y je intuitivn´ı a bez pˇredepsan´ ych norem, podle kterého se r˚ uzn´ı i terminologie. V NoSQL existuje nˇekolik datov´ ych model˚ u, které se l´ıˇs´ı svoj´ı strukturou. • Grafové databáze (Graph database) • Typ kl´ıˇc/hodnota (Key-value database) • Dokumentovˇe orientované (Document Oriented database) • Objektovˇe orientované (Object database) • Sloupcové orientované (Column Oriented database) • XML (XML database)

7

NoSQL databáze

2.9

Grafové databáze

Grafov´ e datab´ aze

Grafové databáze pˇredstavuj´ı jednu z kategori´ı NoSQL systém˚ u pro uchováván´ı dat reprezentovateln´ ych prostˇrednictv´ım grafu, tj. element˚ u s nedeterminovan´ ym poˇctem vzájemn´ ych propojen´ı. Pracuj´ı na obdobném principu jako s´ıt’ové databázové systémy. Pouze jejich vrcholy a hrany pˇredstavuj´ı data strukturovaná jako mnoˇziny dvojic kl´ıˇc/hodnota. T´ımto odpadaj´ı problémy s uloˇzen´ım grafu / stromu do relaˇcn´ı databáze, která nen´ı pro tyto u ´ˇcely pˇr´ıliˇs vhodná. V porovnán´ı s relaˇcn´ımi databázemi jsou grafové databáze pˇri zpracován´ı asociatvn´ıch dat ˇcasto rychlejˇs´ı, jelikoˇz se obejdou bez v´ ypoˇcetnˇe drah´ ych operac´ı JOIN. Nav´ıc jsou schopné mnohem lépe mapovat strukturu objektovˇe orientovan´ ych aplikac´ı bez pevnˇe stanového datového schématu. Grafové databáze pˇredstavuj´ı mocn´ y nástroj pro ˇreˇsen´ı grafov´ ych u ´loh, jak´ ymi jsou napˇr´ıklad nalezen´ı nejkratˇs´ı cesty mezi dvˇema vrcholy. Na obrázku 2.2 je vidˇet rozd´ıl mezi datov´ ym modelem relaˇcn´ı databáze (vlevo), kde jednotlivé obdeln´ıˇcky” reprezentuj´ı dan´ y ˇra´dek v tabulce a ” grafové databáze (vpravo), kde jednotlivé obdeln´ıˇcky reprezentuj´ı vrcholy spojené hranou.

Obrázek 2.2: Srovnán´ı datového modelu relaˇcn´ı a grafové databáze. [9]

Vrchol v grafu reprezentuje jeden konkrétn´ı záznam z tabulky relaˇcn´ı databáze. Hrana reprezentuje dan´ y vztah mezi dvˇema tabulkami, napˇr. 1:N, M:N, atd. Graf m˚ uˇze napˇr. reprezentovat trojice pouˇz´ıvané v datovém modelu RDF známém z webov´ ych aplikac´ı a sociáln´ıch s´ıt´ı. Grafová data mohou b´ yt ˇ jistˇe implementována pomoc´ı relaˇcn´ıho SRDB, nicménˇe jejich zpracován´ı, zejména rekurzivn´ıch dotaz˚ u je sloˇzité a pro zjiˇst’ován´ı cest v grafu je tˇreba pouˇz´ıt mnoho operac´ı spojen´ı. V´ yhodou grafov´ ych databázov´ ych systém˚ u je, ˇze velmi mnoho situac´ı ˇci model˚ u lze snadno popsat grafovou strukturou. 8

NoSQL databáze


Na obrázku 2.3 je zobrazen datov´ y model grafu popisuj´ıc´ı vlastnosti vrchol˚ u a hran. Vrchol m˚ uˇze b´ yt reprezentován nˇejak´ ym objektem (ˇclovˇek, auto) a mezi dvˇema vrcholy je hrana (relace). Kaˇzd´ y vrchol nebo hrana m˚ uˇze obsahovat tzv. vlastnost (popis objektu). Relace mezi dvˇema vrcholy mohou b´ yt r˚ uzného charakteru. Základn´ı typy relac´ı jsou pˇr´ımé a nepˇr´ımé. U pˇr´ımé relace smˇeˇruje ˇsika od rodiˇce k potomkovi a vrcholy jsou ve vztahu odpov´ıdaj´ıc´ı relaˇcn´ım databáz´ım, napˇr. 1:N, M:N, 1:1. U nepˇr´ımé relace jsou ˇsipky na obou stranách vrchol˚ u a t´ım jsou vrcholy ve vzájemné relaci.

Obrázek 2.3: Terminologie pro popis vlastnosti grafu.[10] Na obrázku 2.4 je vidˇet pˇr´ıklad jednoduchého modelu grafové databáze skládaj´ıc´ı se napˇr. z nˇekolika vrchol˚ u, hran a vlastnost´ı. Kaˇzd´ y vrchol obsahuje vlastnosti (Id, Name, Age). Mezi dvˇema vrcholy existuje alespoˇ n jedna hrana, která obsahuje vlastnosti (Id, Label, Since). Vlastnosti lze pˇrirovnat k atribut˚ um (sloupc˚ um) u relaˇcn´ıch databáz´ı. [10]

Obrázek 2.4: Ukázka jednoduchého modelu grafové databáze.[9]

9

NoSQL databáze

2.9.1


Neo4j

Jedná se o grafov´ y databázov´ y systém se vˇsemi vlastnostmi robustn´ı databáze. Pˇri pouˇzit´ı knihovny Neo4j lze dosáhnout zv´ yˇsen´ı rychlost dotazován´ı aˇz v ˇrád˚ u tis´ıc˚ u oproti konveˇcn´ım relaˇcn´ım databáz´ım (podle autora).[9] • Splˇ nuje ACID vlastnosti transakc´ı • Podpora jazyk˚ u Java, .NET, Ruby, Python, ... • Automatické indexován´ı, fulltext, Apache Lucene • Dotazován´ı - Cypher (deklarativn´ı), Gremlin (imperativn´ı), Java API • Licence - GPL (nekomerˇcn´ı pouˇzit´ı), AGPL (komerˇcn´ı pouˇzit´ı)

2.9.2

OrientDB

Open source ˇreˇsen´ı databázového systému s vlastnost´ı dokumentu a grafu, kter´ y je napsán v jazyce Java. Dokumentovˇe orientovaná databáze je zaloˇzena na grafové struktuˇre s pˇr´ım´ ym spojen´ım mezi jednotliv´ ymi záznamy. [5] • Splˇ nuje ACID vlastnosti transakc´ı • Dotazován´ı pomoc´ı SQL (bez JOIN) • Jazyk Java, HTTP, RESTful s JSON formátem • Hooks - alternativa k trigger˚ um • Open source (zdarma)

2.9.3

DEX

Vysoce v´ ykonná a ˇskálovatelná grafová databáze napsaná v jazyce Java a C++. Implementace knihovny obsahuje funkce pro analyzován´ı a dotazován´ı ˇra´dovˇe bilion˚ u objekt˚ u, které vyˇzaduj´ı malé mnoˇzstv´ı u ´loˇzného prostoru na disku a to d´ıky kompresi. [14]

10

NoSQL databáze

Obecné srovnán´ı nerelaˇcn´ıch databáz´ı

• Splˇ nuje ACID vlastnost´ı transakc´ı • Export do formátu - graphml, grahviz, ygraphml • Podpora jazyk˚ u Java, .NET a C++ • Optimalizace vykonáván´ı dotaz˚ u (poskytované kompilátorem) • Kompatibilita s OS - Windows, Linux, Mac, iOS • Licence - komerˇcn´ı a nekomerˇcn´ı (v´ yvoj, testován´ı, v´ yzkum)

2.10

Obecn´ e srovn´ an´ı nerelaˇ cn´ıch datab´ az´ı

Posledn´ı podkapitola v NoSQL databáz´ıch se zab´ yvá obecn´ ym srovnán´ım hlavn´ıch zástupc˚ u této skupiny. Na obrázku 2.5 je graf závislosti sloˇzitosti dat na velikosti dat, se kter´ ymi zvládne daná databáze pracovat. Jak je patrné z grafu databáze typu Key-Value stores” poskytuj´ı nejmenˇs´ı sloˇzitost, ale ” maj´ı nejvyˇsˇs´ı kapacitu. Naproti tomu grafové databáze poskytuj´ı nejvˇetˇs´ı sloˇzitost, ale nejmenˇs´ı kapacitu dat.

Obrázek 2.5: Obecné srovnán´ı hlavn´ıch zástupc˚ u NoSQL databáz´ı. [8]

11

3 Neo4j Neo4j spadá do skupiny NoSQL databáz´ı. Jedná se o grafov´ y databázov´ y systém vytvoˇren´ y spoleˇcnost´ı Neo Technology se vˇsemi vlastnostmi robustn´ı databáze. Práce s n´ı spoˇc´ıvá v programován´ı objektovˇe orientované s´ıt’ové struktury oproti tradiˇcn´ım statick´ ym tabulkám, které se bˇeˇznˇe uˇz´ıvaj´ı v relaˇcn´ıch databáz´ı. Podle autor˚ u lze dosáhnout pouˇzit´ım knihovny Neo4j zv´ yˇsen´ı rychlosti dotazován´ı aˇz v ˇra´d˚ u tis´ıc˚ u, oproti konveˇcn´ım relaˇcn´ım databáz´ım. Potvrdit nebo vyvrátit toto tvrzen´ı m˚ uˇzeme aˇz po testován´ı databáze Neo4j. Neo4j se vyuˇz´ıvá v situac´ıch, kdy potˇrebujeme modelovat ˇcetné v´ıcenásobné vztahy, tzn. spojen´ı mezi jednotliv´ ymi entitami a nevyhovuje nám klasick´ y model relaˇcn´ıch databáz´ı. [9]

3.1

Z´ akladn´ı charakteristika

• Splˇ nuje ACID vlastnosti transakˇcn´ıho zpracován´ı • Vysok´ y stupeˇ n odolnosti a ochrany, kter´ y zaruˇcuje, ˇze ˇza´dná vloˇzena data se neztrat´ı • Podpora jazyk˚ u Java, .NET, Ruby, Python, ... • Autoˇri zmiˇ nuj´ı, ˇze kl´ıˇcov´ ym faktorem dobrého v´ ykonu je m´ıt hodnˇe pamˇeti RAM (odpov´ıdaj´ıc´ı velikosti grafu) • Databáze je limitována poˇctem 32 bilión˚ u vrchol˚ u, 32 bilión˚ u hran a 64 bilión˚ u vlastnost´ı • Vynikaj´ıc´ı podpora technologie Spring • Automatické indexován´ı, Apache Lucene, fulltextov´ y index • Procházen´ı grafem - Cypher, Gremlin, Java API a grafové algoritmy (Shortest paths, Dijkstra, A*), • Pˇripojen´ı k databázi - embedded, REST API • Licence - GPL (nekomerˇcn´ı), AGPL (komerˇcn´ı)

12

Neo4j

3.2

Datový model

Datov´ y model

Neo4j je databázov´ y systém, kter´ y reprezentuje uloˇzená data prostˇrednictv´ım grafové struktury, a proto je vhodn´ y v situac´ıch, kdy lze data jednoduˇse pˇrevést do grafové struktury. Data uvnitˇr grafu jsou uloˇzena do generick´ ych struktur, napˇr. List, Tree, Map. Datov´ y model, kter´ y Neo4j pouˇz´ıvá se skládá z vrchol˚ u (nodes), hran (relationships) a vlastnost´ı (properties). [9]

3.2.1

Vrcholy (nodes)

Vrcholy v datovém modelu reprezentuj´ı danou entitu v grafu a kaˇzd´ y z nich m˚ uˇze obsahovat jednu ˇci v´ıce vlastnost´ı, která jej bl´ıˇze specifikuje. Nejjednoduˇs´ı graf je tvoˇren jedn´ım vrcholem a od kaˇzdého vrcholu mus´ı vést minimálnˇe jedna hrana. Vrcholy mohou b´ yt seskupené do pojmenovan´ ych ˇcást´ı grafu a ty, které patˇr´ı do stejné skupiny, jsou oznaˇcené stejn´ ym ˇst´ıtkem (label). Pˇri vytváˇren´ı dotazu je jednoduˇs´ı a efektivnˇejˇs´ı pracovat s pojmenovan´ ymi ˇcástmi grafu nam´ısto celého grafu.[9]

Obrázek 3.1: Ukázka reprezentace vrchol˚ u v datovém modelu Neo4j.[5]

3.2.2

Hrany (relationships)

Hrana spojuje vˇzdy dva vrcholy u nichˇz mus´ı b´ yt platn´ y zaˇca´tek a konec. Hrany jsou popsány jednou ˇci v´ıce vlastnostmi a mohou b´ yt orientované nebo rovnocené (neorientované) v obou smˇerech. Kaˇzdá hrana mus´ı m´ıt typ

13

Neo4j

Datový model

(relationship type) prostˇrednictv´ım nichˇz je moˇzné naj´ıt urˇcité vrcholy, do kter´ ych smˇeˇruje hrana s dan´ ym typem. [9]

Obrázek 3.2: Ukázka reprezentace hran v datovém modelu Neo4j.[5]

3.2.3

Vlastnosti (properties)

Vlastnosti popisuj´ı jak vrcholy tak i hrany a jsou definovány jako dvojice kl´ıˇc/hodnota, kde kl´ıˇcem je vˇzdy nˇejak´ y ˇretezec a hodnotou m˚ uˇze b´ yt libovoln´ y primitivn´ı datov´ y typ (viz obrázek 3.3). [9]

Obrázek 3.3: Ukázka reprezentace vlastnost´ı v datovém modelu Neo4j.[5]

14

Neo4j

3.3

Procházen´ı grafem a dotazován´ı

Proch´ azen´ı grafem a dotazov´ an´ı

V pˇredchoz´ı ˇca´sti jsme popsali datov´ y model grafové databáze Neo4j. Nyn´ı je tˇreba popsat, jak´ ym zp˚ usobem lze procházet vytvoˇren´ y graf a jaké prostˇredky na to pouˇz´ıt. Pˇri procházen´ı grafu plat´ı, ˇze data jsou uloˇzena ve vrcholech, které bl´ıˇze specifikuj´ı jejich vlastnosti. Vrcholy jsou spojeny pomoc´ı hran, které mohou b´ yt bl´ıˇze specifikovány sv´ ymi vlastnostmi. Hrany se nejˇcastˇeji znázorˇ nuj´ı ve smˇeru od nadˇrazeného uzlu k podˇr´ızenému, tzn. od rodiˇce” k potomkovi” apod. Nˇekteré hrany nen´ı potˇreba zdvojovat obˇema ” ” smˇery. Napˇr´ıklad pokud máme typ hrany zná se s”, tak pokud se Martin ” zná s Janou, tak logicky plyne, ˇze i Jana mus´ı znát Martina. V tomto pˇr´ıpadˇe staˇc´ı hrana jedn´ım smˇerem. Avˇsak u hrany typu miluje” to vzájemné b´ yt ” nemus´ı a potom tuto vlastnost lze uvést v rámci relace. Vlastnosti vrchol˚ u a hran jsou d˚ uleˇzit´ ym faktorem pˇri procházen´ı grafu, jelikoˇz obsahuj´ı informace o hledaném vrcholu nebo hrany. Napˇr´ıklad máme graf (viz obrázek 3.4) skládaj´ıc´ı se z vrchol˚ u, které uchovávaj´ı informace o lidech (Name, Age, Gender) a hran popisuj´ıc´ı vlastnost KNOWS”. V ” tomto grafu chceme naj´ıt osoby, které se znaj´ı s osobou nazvanou Tho” mas Anderson”. Postup je následuj´ıc´ı, zaˇcneme procházet graf od vrcholu s vlastnost´ı Thomas Anderson” a hledat vrcholy, které jsou s t´ımto vrcholem ” spojeny pˇr´ımo hranou s vlastnost´ı KNOWS” a nebo nepˇr´ımo pˇres nˇejak´ y ” dalˇs´ı vrchol. Neo4j nab´ız´ı nˇekolik mechanism˚ u na procházen´ı grafem (Cypher, Gremlin, Java API).

Obrázek 3.4: Pˇr´ıklad na procházen´ı grafem v Neo4j.[5]

15

Neo4j

3.3.1


Cypher

Jedná se o deklarativn´ı grafov´ y dotazovac´ı jazyk, jehoˇz zp˚ usob dotazován´ı je podobn´ y dotazovac´ımu jazyku SQL pouˇz´ıvanému v relaˇcn´ıch databáz´ıch. T´ımto prostˇredkem lze dosáhnout vysoce efektivn´ıho procházen´ı grafem bez nutnosti pouˇzit´ı sloˇzit´ ych mechanism˚ u, které nab´ız´ı Java API ˇci Gremlin. Cypher je navrˇzen tak, aby bylo moˇzné jednoduˇse a efektivnˇe klást dotazy bez nutnosti znalosti sloˇzit´ ych pˇr´ıkaz˚ u. Cypher je inspirován ˇradou r˚ uzn´ ych pˇr´ıstup˚ u, které navazuj´ı na zavedené postupy pro expresivn´ı dotazován´ı (napˇr. jazyk SPARQL). Vˇetˇsina kl´ıˇcov´ ych slov jako napˇr. WHERE a ORDER BY jsou inspirovány jazykem SQL. Jak uˇz bylo zm´ınˇeno, Cypher patˇr´ı do skupiny deklarativn´ıch programovac´ıch jazyk˚ u, které jsou zaloˇzeny na myˇslence programován´ı pomoc´ı definic, tzn. co se má udˇelat” a nikoliv jak se to má udˇelat”. Pˇr´ıkladem pouˇzit´ı do” ” tazovac´ıho jazyka Cypher je n´ıˇze a pouˇz´ıvá graf z pˇredchoz´ıho pˇr´ıkladu (viz Obrázek 3.4), kde je u ´kolem naj´ıt osoby, ke kter´ ym vede identická hrana s vlastnost´ı KNOWS”. ” // Pˇ rı ´klad pouˇ zit´ ı jazyka Cypher START n = node(*) MATCH n-[:KNOWS]->person RETURN person.name, person.age Pˇr´ıkaz START specifikuje jaké vrcholy se maj´ı prohledat, ve vˇetˇsinˇe pˇr´ıpad˚ u pouˇzijeme znak *”, kter´ y reprezentuje vˇsechny vrcholy. MATCH slouˇz´ı pro ” identifikaci hran, které se maj´ı zahrnout do procházen´ı grafu. Posledn´ı pˇr´ıkaz RETURN oznaˇcuje mnoˇzinu, která se má zobrazit na v´ ystupu. V tomto pˇr´ıpadˇe se jedná o název a vˇek osoby. Person je pojmenovaná skupina vrchol˚ u, do kter´ ych vede hrana uvedená v pˇr´ıkazu MATCH.

3.3.2

Gremlin

Gremlin je doménovˇe specifick´ y jazyk pro procházen´ı graf˚ u, zaloˇzen´ y na jazyku Groovy. Jedná se imperativn´ı programovac´ı jazyk, u kterého se definuje postup jak´ ym se má vykonat dan´ y dotaz. V´ yhodou jazyka Gremlin je nezávislost na grafové databázi Neo4j a vyuˇz´ıvá Blueprints (analogie JDBC pro grafové databáze). Skripty dotazu poslané od klienta jsou spuˇstˇeny na serveru, kde je um´ıstˇena databáze a v´ ysledky jsou vráceny jako mnoˇziny uzl˚ ua 16

Neo4j


hran, které jsou kompatibiln´ı s rozhran´ım Neo4j. Tento zp˚ usob udrˇzuje kon1 zistentn´ı typy v celém REST API. Skripty je moˇzné pos´ılat ze serveru i ve formátu JSON. Gremlin umoˇzn ˇuje spustit samovolnˇe kód z jazyka Groovy, coˇz m˚ uˇze pˇredstavovat v hostovaném otevˇreném prostˇred´ı bezpeˇcnostn´ı riziko. Pˇr´ıklad na pouˇzit´ı jazyka Gremlin bude stejn´ y jako v pˇredchoz´ım pˇr´ıkladˇe. // Pˇ rı ´klad pouˇ zit´ ı jazyka Gremlin g.v(0).out("KNOWS") T´ımto jednoduch´ ym pˇr´ıkazem lze zobrazit mnoˇzinu vrchol˚ u, do kter´ ych vede hrana s názvem KNOWS a pomoc´ı pˇr´ıkazu out vyp´ıˇseme informace o nalezen´ ych vrcholech na v´ ystup.

3.3.3

Traversal Framework

Dalˇs´ı moˇznost´ı procházen´ı grafu v Neo4j je vyuˇz´ıt´ı vestavˇeného rozhran´ı API, které je nativnˇe napsáno pro jazyk Java, ale existuje i podpora pro dalˇs´ı jazyky prostˇrednictv´ım REST API, napˇr. .NET, Ruby, Python. Traversal Framework se skládá z nˇekolika hlavn´ıch ˇcást´ı (viz Obrázek 3.5), kde je znázornˇeno blokového schéma rozhran´ı Traversal Framework. • TraversalDescription - hlavn´ı rozhran´ı pro inicializaci procházen´ı grafem • Evaluator - pouˇzivá se pˇri rozhodován´ı na kaˇzdém vrcholu v grafu (reprezentováno cestou), zda-li v cestˇe pokraˇcovat nebo vrchol zahrnout do v´ ysledku • Traverser - objekt Traverser je v´ ysledkem volán´ı TraversalDescription reprezentuj´ıc´ı pr˚ uchod v grafu a specifikuje formát zobrazen´ı v´ ysledku • Uniqueness - mnoˇzina pravidel pro u ´pravu jiˇz navˇst´ıven´ ych vrchol˚ u bˇehem procházen´ı • Expander- definuje, co se má procházet, obvykle smˇer hrany vstupuj´ıc´ı do vrcholu a typ 1

REST (Representational State Transfer) je architektonick´ y styl navrˇzen´ y pro distribuované prostˇred´ı

17

Neo4j


Obrázek 3.5: Ukázka konceptu rozhran´ı Traversal Framework.[5] • Path - základn´ı rozhran´ı, které je souˇcást´ı Neo4j API, umoˇzn ˇuje dva odliˇsné zp˚ usoby procházen´ı: – Rozhran´ı traverser m˚ uˇze vracet v´ ysledky nalezené cesty v podobˇe navˇst´ıven´ ych vrchol˚ u v grafu, které jsou oznaˇcené za vrácené – Objekty cesty pouˇz´ıvaj´ı hodnocen´ı pozic v grafu pro zjiˇstˇen´ı zda pokraˇcovat v cestˇe od urˇcitého bodu nebo ne, a zda je urˇcit´ y vrchol zahrnut do v´ ysledku ˇci nikoliv Dále uvedu jednoduch´ y pˇr´ıklad pouˇzit´ı rozhran´ı Traversal Framework pro nalezen´ı osoby z pˇredchoz´ıho pˇr´ıkladu (viz Obrázek 3.4). Nejprve se inicializuje rozhran´ı TraversalDescription a poté se nastav´ı potˇrebné parametry, napˇr. depthFirst (hloubka procházen´ı), relationships (typ relace) a uniqueness (moˇzina pravidel pro u ´pravu pozice pˇri procházen´ı). Nakonec se takto inicializované rozhran´ı pouˇzije pro z´ıskán´ı jednotliv´ ych vrchol˚ u, které jsou popsány vlastnostmi. [9] // inicializace final TraversalDescription FRIENDS_TRAVERSAL = Traversal.description() .depthFirst() .relationships( Rels.KNOWS ) .uniqueness( Uniqueness.RELATIONSHIP_GLOBAL ); //

Transformace objektu TraversalDescription na objekt Node (vrchol) 18

Neo4j


for ( Node currentNode : FRIENDS_TRAVERSAL .traverse( node ) .nodes() ) { output += currentNode.getProperty( "name" ) + "\n"; }

3.3.4

Grafov´ e algoritmy

Knihovna Neo4j obsahuje nˇekolik základn´ıch grafov´ ych algoritm˚ u, které se pouˇz´ıvaj´ı v situaci, kdy potˇrebujeme naj´ıt nejkratˇs´ı cestu z jednoho vrcholu do druhého. Nejˇcastˇeji pouˇz´ıvan´ ymi algoritmy jsou: [9] • Shortest paths • all paths • all simple paths • Dijkstra • A* Ukázka jednoduchého pouˇzit´ı grafového algoritmu Dijkstra pro nalezen´ı nejkratˇs´ı cesty mezi vrcholem A a vrcholem B. // pˇ rı ´klad pouˇ z´ ıt´ ı algoritmu Dijkstra PathFinder<WeightedPath> finder = GraphAlgoFactory.dijkstra( Traversal.expanderForTypes( ExampleTypes.MY_TYPE, Direction.BOTH ), "cost" ); WeightedPath path = finder.findSinglePath( nodeA, nodeB ); path.weight(); Inicializuje se objekt PathFinder, kter´ y nastav´ı vˇsechny d˚ uleˇzité parametry (typ, smˇer hrany, váhu) pro v´ ypoˇcet nejkratˇs´ı cesty pomoc´ı Dijkstrova algoritmu. V objektu WeightedPath se jako parametry vloˇz´ı odkaz na vrchol A a B. Nakonec se zavolá metoda weight(), která vrát´ı v´ yslednou délku (váhu) nejkratˇs´ı cesty. 19

Neo4j

3.4

Integrace a nasazen´ı


Tato ˇca´st kapitoly se zab´ yvá zaˇclenˇen´ım knihovny Neo4j do projektu. Samotná integrace se skládá z instalace knihovny, v´ ybˇerem verze knihovny (licence), minimáln´ıch a doporuˇcen´ ych systémov´ ych poˇzadavk˚ u a nakonec moˇznosti nasazen´ı vˇcetnˇe reálného pouˇzit´ı v praxi. Otestován´ı vytvoˇrené grafové databáze umoˇzn ˇuj´ı tzv. vizualizaˇcn´ı nástroje (Gephi, Neoclipse a Web admin), které budou popsány na konci kapitoly.

3.4.1

Instalace

Neo4j knihovna m˚ uˇze b´ yt nainstalována bud’ jako embedded databáze, tzn. databáze bˇeˇz´ı ve stejném procesu jako aplikace, která j´ı pouˇz´ıvá, nebo jako standalone databáze pˇripojená k aplikaci pˇres rozhran´ı REST API, coˇz dává velké moˇznosti ve v´ ybˇeru jazyk˚ u (.NET, Ruby, Python, ...) pro implementaci. Knihovnu pro embedded verzi databáze je moˇzné stáhnout z oficiáln´ıch stránek Neo4j. Pˇri pouˇzit´ı vzdáleného pˇripojen´ı k databázi je nutné stáhnout jeˇstˇe knihovnu pro REST API.

3.4.2

Licence

Neo4j je software, kter´ y je k dispozici ve dvou r˚ uzn´ ych licenc´ı. Pro nekomeˇcn´ı vyuˇzit´ı je k dispozici verze Community pod licenc´ı GPL (General Public License), která je zdarma. V pˇr´ıpadˇe pouˇzit´ı pro komerˇcn´ı u ´ˇcely jsou k dispozici verze Advanced, Enterprise pod licenc´ı AGPLv3 (Affero General Public License), která je zpoplatnˇena.[9]

Verze

Popis

Licence

Community

základn´ı databáze, plná podpora ACID

GPL

Advanced

Pokroˇcil´ y monitoring (anal´ yza aktivit databáze)

AGPLv3

Enterprise

online zálohován´ı, klastrován´ı, High availability

AGPLv3

Tabulka 3.1: Pˇrehled dostupn´ ych licenc´ı knihovny Neo4j. 20

Neo4j

3.4.3


Syst´ emov´ e poˇ zadavky

• Procesor - minimálnˇe Intel Core i3, doporuˇceno Intel Core i7 • Operaˇ cn´ı pamˇ et’ RAM - minimálnˇe 2 GB, doporuˇceno 16 - 32 GB (podle velikosti grafu) • Pevn´ y disk - minimálnˇe 10 GB SATA, doporuˇceno SSD w/ SATA • Operaˇ cn´ı syst´ em - Linux, Windows, Mac OS X (Neo4j zaloˇzen na Javˇe => pˇrenositelnost)

3.4.4

Nasazen´ı

Po u ´spˇeˇsné instalaci a vytvoˇren´ı modelu grafové databáze je nutné databázi nasadit. Jak uˇz bylo zm´ınˇeno v ˇcásti instalace, Neo4j vyuˇz´ıvá dva druhy pˇr´ıstupu k databázi. • Embedded - jak bylo zm´ınˇeno v pˇredchoz´ı ˇca´sti kapitoly pˇripojen´ı k databázi prob´ıhá lokálnˇe, tzn. databáze je spuˇstˇena ve stejném procesu jako aplikace, která j´ı pouˇz´ıvá. Pˇri implementaci se pracuje s rozhran´ım GraphDatabaseService, které umoˇzn ˇuje pˇrep´ınat mezi jednou a v´ıce instancemi databáze. Postup je jednouch´ y, pro jednu instanci se pouˇzije objekt EmbeddedGraphDatabase a pro v´ıce instanc´ı se pouˇzije objekt HighlyAvailableGraphDatabase. • Standalone - jedná se o vzdálené pˇripojen´ı k databázi, která je um´ıstˇena na jiném stroji neˇz, na kterém je spuˇstˇena databáze. Ke vzdálené databázi se lze pˇripojit prostˇrednictv´ım rozhran´ı REST nebo dostupného ovladaˇce konkrétn´ıho programovac´ıho jazyka. [9]

21

Neo4j

3.5

Vizualizaˇcn´ı nástroje

Vizualizaˇ cn´ı n´ astroje

Vizualizaˇcn´ı nástroje se pouˇz´ıvaj´ı pro zobrazen´ı grafu nebo jeho ˇcásti, která je v´ ysledkem nˇejakého dotazu. Samotná vizualizace je u ´ˇcinn´ ym nástrojem pro vyjádˇren´ı obsahu grafu, napˇr. zv´ yraznˇen´ı vzor˚ u grafu, spojen´ı mezi vrcholy, atd. Existuj´ı r˚ uzné nástroje pro vizualizaci grafové databáze (nejen pro Neo4j), které se od sebe liˇs´ı pˇredevˇs´ım nab´ızenou funkcionalitou.

3.5.1

Web admin Neo4j

Neo4j webové rozhran´ı je primárnˇe uˇzivatelské rozhran´ı pro správu databáze a jej´ı vizualizaci. Umoˇzn ˇuje monitorován´ı Neo4j serveru, prohl´ıˇzen´ı a manipulován´ı s daty a vykonáván´ı dotaz˚ u prostˇrednictv´ı konzole. Nástroj pro správu databáze je k dispozici na adrese http://localhost:7474, ale nejdˇr´ıve je nutné spustit samotn´ y server Neo4j. Administraˇcn´ı rozhran´ı se skládá z nˇekolika záloˇzek: • Dashboard - zobrazuje pˇrehled spuˇstˇen´ ych instanc´ı Neo4j, poˇcet vˇsech vrchol˚ u, hran, typ˚ u hran a vlastnost´ı. • Data browser - slouˇz´ı k procházen´ı, pˇridáván´ı nebo upravován´ı vrchol˚ u, hran a vlastnost´ı • Console - vykonáván´ı dotaz˚ u prostˇrednictv´ım jazyka Gremlin nebo Cypher, komunikován´ı se vzdálenou databáz´ı pomoc´ı HTTP protokolu • Server info - zobrazuje detailn´ı informace o nastaven´ı serveru Neo4j a JVM

3.5.2

Neoclipse

Neoclipse je vizualizaˇcn´ı nástroj implementovan´ y v jazyku Java a klade si za c´ıl podporovat v´ yvoj Neo4j aplikac´ı. Nástroj je k dispozici zdarma (Open source). Mezi jeho hlavn´ı funkce patˇr´ı • Vizualizace grafové databáze • Filtrován´ı podle typ˚ u hran 22

Neo4j

Vizualizaˇcn´ı nástroje

• Vytvoˇren´ı/smazán´ı vrchol˚ u a hran • Vytvoˇren´ı typ˚ u hran • Vytvoˇren´ı/smazán´ı/editován´ı vlastnost´ı popisuj´ıc´ı vrcholy ˇci hrany • Zv´ yraznˇen´ı ˇca´sti grafu a moˇznost pˇridán´ı ikon k vrchol˚ um • Podpora dotazovac´ıho jazyka Cypher

3.5.3

Gephi

Gephi je interaktivn´ı vizualizaˇcn´ı desktopov´ y nástroj, kter´ y umoˇzn ˇuje procházet a manipulovat s grafy. Nástroj je dostupn´ y zdarma (Open source). Uˇzivatel interaguje s grafem, manipuluje se strukturami - tvarem a barvami, aby se ukázaly skryté vlastnosti grafu. Uˇz´ıvá se hlavnˇe k zobrazován´ı objemn´ ych graf˚ u v reálném ˇcase a k urychlen´ı prohl´ıˇzen´ı vyuˇz´ıvá 3D engine. Mezi jeho hlavn´ı funkce patˇr´ı: [2] • Vizualizace v reálném ˇcase • Prohl´ıˇzen´ı a analyzován´ı dat • Analyzován´ı propojen´ı mezi jednotliv´ ymi vrcholy • Anal´ yza sociáln´ıch s´ıt´ı • Vytvoˇren´ı kartografi´ı • Metrika grafu • Klastrován´ı hiearchick´ ych graf˚ u

23

4 EEG/ERP portál 4.1

Vize port´ alu

Prvotn´ı myˇslenka EEG/ERP portálu vznikla v roce 2008 na základˇe nˇeko” lika d˚ uleˇzit´ ych podnˇet˚ u. Katedra informatiky a v´ ypoˇcetn´ı techniky na Západoˇceské univerzitˇe v Plzni se zab´ yvá projektem experimentáln´ıho mˇeˇren´ı mozkové aktivity. V dobˇe pˇred vznikem portálu se namˇeˇrená data ukládala neuspoˇra´danˇe na poˇc´ıtaˇc v laboratoˇri na katedˇre. Samotná namˇeˇrená data nám ale nic neˇreknou o mˇeˇrené osobˇe, mˇeˇr´ıc´ı osobˇe, pouˇzit´ ych pˇr´ıstroj´ıch a scénáˇr´ıch experiment˚ u. Spoleˇcnˇe s namˇeˇren´ ymi daty bylo nutné ukládat i informace o jednotliv´ ych experimentech. Dále bylo zapotˇreb´ı data a informace z experiment˚ u ukládat do databáze a umoˇznit pˇr´ıstup v´ıce uˇzivatel˚ um pˇres webové rozhran´ı. Dalˇs´ım d˚ uvodem, proˇc portál vznikl, je jeho jedineˇcnost. Po prozkoumán´ı dostupn´ ych alternativ bylo jednoznaˇcnˇe nutné portál vytvoˇrit od základu a to tak, aby splˇ noval potˇrebná kritéria. ˇ nen´ı jediná, která se v´ Samotná katedra na ZCU yzkumem EEG zab´ yvá. Existuje mnoho dalˇs´ıch zájmov´ ych skupin s podobn´ ym zamˇeˇren´ım, které by také potˇrebovaly své experimenty sd´ılet s ostatn´ımi. Jedna z viz´ı tohoto projektu je umoˇznit ostatn´ım uˇzivatel˚ um pˇridávat a konzultovat své experimenty pˇres webové rozhran´ı.”[4]

4.2

Popis port´ alu

Portál je webová aplikace slouˇz´ıc´ı ke správˇe neuroinformatick´ ych dat z´ıskan´ ych mˇeˇren´ım mozkové aktivity. Umoˇzn ˇuje skupinám v´ yzkumn´ık˚ u ukládat, aktualizovat, stahovat data a metadata z EEG/ERP experiment˚ u namˇeˇren´ ych v laboratoˇr´ıch. Portál je vyv´ıjen jako samotn´ y produkt s licenc´ı GNU GPL. Pˇr´ıstup do databáze je pomoc´ı webového rozhran´ı. Portál je napsán v jazyce Java a je zaloˇzen na frameworku Spring MVC, Spring Security a technologii JSP. Datová vrstva pracuje s neuroinformatickou databáz´ı a pouˇz´ıvá k tomu systém Oracle 11g spolu s objektovˇe relaˇcn´ım mapován´ım, které zajiˇst’uje framework Hibernate.

24

EEG/ERP portál

Popis portálu

Portál nab´ız´ı následuj´ıc´ı sadu funkc´ı: • Registrace uˇzivatel˚ u • Ukládán´ı, aktualizace a stahován´ı dat, scénáˇr˚ u a experiment˚ u • Nástroje pro zpracován´ı signál˚ u • Historie stahován´ı • Systém pro správu obsahu (CMS) • Fulltextové vyhledáván´ı Portál je testován na serveru Jetty. Na testovac´ım serveru je dostupn´ y vˇzdy denn´ı build portálu. Produkˇcn´ı verzi portálu lze nalézt na adrese eegdatabase.kiv.zcu.cz, která bˇeˇz´ı také na serveru Jetty. Cel´ y projekt EEG/ERP je dostupn´ y na veˇrejném hostovac´ım serveru Github [1]. Databáze nese kromˇe informac´ı o samotn´ ych experimentech a dat jim náleˇz´ıc´ıch i dalˇs´ı struktury pro bˇeh samotného portálu. Mezi ty hlavn´ı patˇr´ı napˇr. informace o uˇzivatel´ıch, v´ yzkumn´ ych skupinách, ˇclánc´ıch, jejich komentáˇr´ıch, experimentech, atd. V souˇcasné dobˇe se posouvá v´ yznam portálu z bˇeˇzného u ´loˇziˇstˇe dat k velké webové aplikaci schopné analyzovat data a pracovat s nimi pˇr´ımo na serveru.[13]

4.2.1

Role port´ alu

Uˇzivatelé pracuj´ıc´ı s EEG/ERP portálem jsou vˇetˇsinou pracovn´ıci katedry informatiky a v´ ypoˇcetn´ı techniky, dále studenti, kteˇr´ı se pod´ılej´ı na mˇeˇren´ıch, a nakonec i ˇsiˇrˇs´ı komunita zab´ yvaj´ıc´ı se tématikou EEG/ERP. Aktuálnˇe v portálu rozliˇsujeme celkem pˇet r˚ uzn´ ych rol´ı. • Neregistrovan´ y uˇ zivatel - uˇzivatel m˚ uˇze navˇst´ıvit pouze domovskou stránku a m˚ uˇze se registrovat ˇ • Cten´ aˇ r - registrovann´ y uˇzivatel, kter´ y si m˚ uˇze stáhnout veˇrejné experimety a nemá právo prohl´ıˇzet osobn´ı informace o mˇeˇr´ıc´ıch a mˇeˇren´ ych osobách. Dále m˚ uˇze pˇridávat názory na veˇrejnou nástˇenku. V pˇr´ıpadˇe, ˇze je ˇclenem skupiny, pak m˚ uˇze pˇridávat názory i na nástˇenku skupiny. 25

EEG/ERP portál

Popis portálu

• Experiment´ ator - registrovan´ y uˇzivatel, kter´ y m˚ uˇze pˇridávat experimenty, v rámci zákona má povoleno pouˇz´ıvat osobn´ı data subjekt˚ u, na kter´ ych provedl experiment. Dále m˚ uˇze pˇrisp´ıvat sv´ ymi názory na veˇrejnou nástˇenku a na nástˇenku skupiny, jej´ıˇz je ˇclenem. • Administr´ ator skupiny - má práva spravovat skupiny, pˇrisp´ıvat sv´ ymi názory a aktualitami na nástˇenku skupiny, kterou on sám vytvoˇril. Dále m˚ uˇze pˇrisp´ıvat sv´ ymi názory na veˇrejnou nástˇenku a prohl´ıˇzet evidenci stahován´ı experiment˚ u ˇclen˚ u své skupiny. • Administr´ ator - uˇzivatel, kter´ y má nejˇsirˇs´ı práva ke správˇe portálu. M˚ uˇze spravovat evidenci stahován´ı experiment˚ u vˇsech uˇzivatel˚ u portálu. [4]

´ Obrázek 4.1: Uvodn´ ı stránka EEG/ERP portálu.[11]

26

EEG/ERP portál

4.3

Analýza datového schématu

Anal´ yza datov´ eho sch´ ematu

C´ılem této anal´ yzy je prozkoumat stávaj´ıc´ı datové schéma EEG/ERP portálu a vybrat vhodnou podmnoˇzinu pouˇzitelnou pro modelován´ı datové vrstvy v grafové databázi Neo4j. Datové schéma EEG/ERP portálu je zaloˇzené na databázové technologii Oracle 11g. Databáze je z vˇetˇs´ı ˇcásti navrˇzena tak, aby uchovávala informace o proveden´ ych experimentech. Mimo toho lze ukládat do databáze také informace o lidech, kteˇr´ı pracuj´ı na nˇejakém experimentu, v´ yzkumn´ ych skupinách, scénáˇr´ıch, ˇclánc´ıch, atd. Kompletn´ı datové schéma EEG/ERP portálu je k dispozici v pˇr´ıloze. Bˇehem anal´ yzy bylo zjiˇstˇeno chybné propojen´ı mezi nˇekter´ ymi tabulkami v datovém schématu, pˇri kterém doˇslo ke vzniku cykl˚ u. Takto vzniklé cykly maj´ı neblah´ y u ´ˇcinek na celé schéma databáze, a proto je nutné je odstranit. Na obrázku 4.2 jsou zobrazeny tabulky, u kter´ ych doˇslo k zacyklen´ı. Ke vzniku cyklu doˇslo následuj´ıc´ım zp˚ usobem. Tabulka EXPERIMENT obsahuje ciz´ı kl´ıˇc, kter´ y odkazuje na tabulku ELECTRODE_CONF. Ta obsahuje ciz´ı kl´ıˇc, kter´ y odkazuje na tabulku DATA_FILE. V této chv´ıli jeˇstˇe k ˇzádnému zacyklen´ı nedoˇslo, ale bohuˇzel tato obsahuje dále ciz´ı kl´ıˇc, kter´ y odkazuje zpˇet na tabulku EXPERIMENT a t´ım doˇslo k zacyklen´ı. Tento problém vzniku cyklu lze ˇreˇsit v´ıce zp˚ usoby, ale my se spokoj´ıme s jednoduch´ ym ˇreˇsen´ım, které spoˇc´ıvá v odstranˇen´ı ciz´ıho kl´ıˇce z tabulky DATA_FILE. T´ımto je problém zacyklen´ı vyˇreˇsen a m˚ uˇzeme pokraˇcovat ve v´ ybˇeru vhodné podmnoˇziny datového schématu.

Obrázek 4.2: Ukázka zacyklen´ı v datovém schématu EEG/ERP portálu.

27

EEG/ERP portál

4.4

Výbˇer vhodné podmnoˇziny

V´ ybˇ er vhodn´ e podmnoˇ ziny

V této ˇca´sti anal´ yzy datového modelu je nutné vybrat vhodnou podmnoˇzinu datového schématu EEG/ERP portálu, která bude pouˇzita pˇri modelován´ı grafové databáze. Poˇzadavky na v´ ybˇer podmnoˇziny nebyly stanovené, ale je nutné, aby ve vybrané podmnoˇzinˇe byla taková ˇca´st datového schématu, která je nejv´ıce pouˇz´ıvaná. Z d˚ uvodu toho, ˇze vˇetˇs´ı ˇca´st databáze tvoˇr´ı informace o experimentech, je zcela ˇzádouc´ı, aby byla za vhodnou podmnoˇzinu datového schématu vybraná právˇe tabulka uchovávaj´ıc´ı informace o experimentech vˇcetnˇe vˇsech závisej´ıc´ıch tabulek. Na obrázku 4.3 je znázornˇeno datové schéma vybrané podmnoˇziny, která obsahuje tabulku experiment˚ u a také vˇsechny závislé tabulky. Podmnoˇzina datového schématu jiˇz neobsahuje ˇzádné cykly, které by pˇri modelován´ı grafové databáze nebyly problémem, ale bylo nutné tento cyklus odstranit v datovém schématu relaˇcn´ı databáze.

28

EEG/ERP portál


Obrázek 4.3: Ukázka podmnoˇzina datového schématu EEG/ERP portálu.

29

EEG/ERP portál

4.4.1


Popis vybran´ ych tabulek

EXPERIMENT Tabulka experiment˚ u uchovává informace o vˇsech uskuteˇcnˇen´ ych experimentech. V tabulce se zaznamenává hlavnˇe ˇcas zaˇca´tku a ˇcas konce experimentu, teplota, popis prostˇred´ı, poˇcas´ı, konfigurace elektrod, digitalizace, v´ yzkumná skupina, druh scénáˇre a dalˇs´ı.

PERSON Tabulka osob uchovává informace o vˇsech registrovan´ ych ˇclenech a testovan´ ych subjekt˚ u, kteˇr´ı se pod´ılej´ı na v´ yzkumné ˇcinnosti. Základn´ı informace o tˇehto osobách jsou napˇr. uˇzivatelské jméno, v´ yzkumná skupina a nejvyˇsˇs´ı dosaˇzené vzdˇelán´ı, osobn´ı u ´daje (jméno pˇr´ıjmen´ı, email, pohlav´ı, ...), datum registrace, atd.

EDUCATION LEVEL V tabulce se uchovávaj´ı informace o nejvyˇsˇs´ım dosaˇzeném vzdˇelán´ı dané osoby, napˇr. název dosaˇzeného vzdˇelán´ı.

SUBJECT GROUP Tabulka obsahuje seznam skupin subjekt˚ u, která slouˇz´ı pro rozliˇsen´ı testovan´ ych subjekt˚ u. Obsahuje informace o názvu a popisu skupiny.).

ELECTRODE CONF Tabulka uchovává informace o konfiguraci elektrod pro dan´ y experiment, napˇr. hodnotu maximáln´ı impedance, systém, dle kterého byly elektrody osazeny.

ELETRODE SYSTEM Slouˇz´ı k uchováván´ı informac´ı o jednotliv´ ych systémech, na kter´ ych byly elektrody osazeny. Obsahuje informace o názvu a popisu systému.

DIGITIZATION Tabulka uchovává informace o procesu pˇrevodu analogového signálu do digi-

30

EEG/ERP portál


táln´ıho k danému experimentu. Obsahuje informace o pouˇzitém filtru, vzorkovac´ı frekvenci a hodnotˇe zisku (gain).

ANALYSIS V této tabulce se ukládaj´ı informace o provedné anal´ yze signálu k danému systému, napˇr. délka signálu pˇred a po stimulu, popis anal´ yzy a poˇcet epoch.

ARTEFACT Tabulka artefakt˚ u uchovává informace o metodách kompenzace artefakt˚ ua podm´ınky pro zahozen´ı mˇeˇren´ı k danému experimentu.

DATA FILE Tabulka obsahuje informace o datov´ ych souborech, které jsou pˇridruˇzeny k nˇejakému experimentu, napˇr. název souboru, typ souboru, popis, název provedené anal´ yzy a samotn´ y binárn´ı datov´ y soubor ve formátu BLOB.

SCENARIO Tabulka scénáˇr˚ u uchovává informace k jednotliv´ ym experiment˚ um, jako napˇr. název scénáˇre, popis, typ, osobu odpovˇednou za vytvoˇren´ y scénáˇr a název v´ yzkumné skupiny.

WEATHER Do této tabulky se ukládaj´ı informace o poˇcas´ı, napˇr. popis aktuáln´ıho poˇcas´ı a název.

RESEARCH GROUP V této tabulce se uchovávaj´ı informace o vˇsech v´ yzkumn´ ych skupinách, pˇriˇcemˇz kaˇzdá z tˇechto v´ yzkumn´ ych skupin obsahuje informace jako napˇr. název v´ yzkumné skupiny, popis a správce skupiny.

31

5 Generován´ı testovac´ıch dat Tato kapitola se zab´ yvá generován´ım testovac´ıch dat nad relaˇcn´ı databáz´ı Oracle pro EEG/ERP portálu. Vygenerován´ı testovac´ıch dat je nutné provést jiˇz pˇred samotnou implementac´ı grafové databáze Neo4j, jelikoˇz pˇri vytváˇren´ı grafové struktury budou tato data vyˇzadována.

5.1

Datanamic Data Generator for Oracle

Tento nástroj je urˇcen´ y právˇe pro generován´ı testovac´ıch dat nad Oracle databáz´ı. Produkt je moˇzné stáhnout jako trial verzi na 30 dn´ı zdarma, ale po uplynut´ı doby je nutné zakoupit licenci. Pro u ´ˇcely testován´ı mi byla poskytnuta licence na tento produkt, která byla vydaná pro University of West ” Bohemia”. Nástroj poskytuje mnoho funkc´ı, napˇr. • Generován´ı smyslupln´ ych testovac´ıch dat • Generován´ı dat pˇr´ımo do databáze nebo do souboru • Generován´ı dat zaloˇzené na charakteristice sloupc˚ u • Vytvoˇren´ı vlastn´ıch generátor˚ u dat • Sada pˇredpˇripraven´ ych generátor˚ u • Podpora pro Oracle 9i, 10g, 11g • Podpora pro databáze MySQL, Oracle, MS SQL Server, MS Access a PostgreSQL

5.1.1

Postup vygenerov´ an´ı dat

Neˇz zaˇcneme s generován´ım dat, je potˇreba nejprve vytvoˇrit databázi na lokáln´ım u ´loˇziˇsti, z d˚ uvodu snadnˇejˇs´ıho pˇr´ıstupu a práce s databáz´ı. K tomu je potˇreba nainstalovat databázov´ y server Oracle (aktuáln´ı verze 11g). Cel´ y proces instalace je popsán v uˇzivatelské pˇr´ıruˇcce, která se nacház´ı v Pˇr´ıloze

32

Generován´ı testovac´ıch dat

Datanamic Data Generator for Oracle

A. Dále je nutné nainstalovat samotn´ y nástroj pro generován´ı dat Datanamic Data Generator for Oracle a poté spustit. Po spuˇstˇen´ı zaloˇz´ıme projekt, ve kterém nastav´ıme parametry pro pˇripojen´ı k lokálnˇe vytvoˇrené databázi a poté vybereme tabulky, které budou zahrnuty do procesu generován´ı. Po naˇcten´ı tabulek vybereme u jednotliv´ ych sloupc˚ u tabulek typ generátoru dat. Nástroj je natolik inteligentn´ı, ˇze podle názvu sloupce rozpozná, o jak´ y druh dat by mohl j´ıt, a automaticky pˇriˇrad´ı moˇznou variantu z pˇredem pˇripravené sady generátor˚ u. Napˇr´ıklad pokud se jedná o sloupec s názvem FileName” automaticky vybere generátor pro název souboru. U ostatn´ıch ” sloupc˚ u, které nerozpozná, se vybere generátor podle datového typu. V pr˚ ubˇehu nastaven´ı generátor˚ u jsem narazil na nˇekolik problém˚ u. Napˇr´ıklad tabulka ELECTRODE_CONF obsahuje sloupec s názvem IMPEDANCE, kter´ y má datov´ y typ Number, coˇz reprezentuje obecnou ˇc´ıselnou hodnotu. Tato hodnota m˚ uˇze nab´ yvat bud’ celoˇc´ıselné hodnoty nebo desetinné hodnoty. V tomto pˇr´ıpadˇe byla vyˇzadována celoˇc´ıselná hodnota, pro kterou nebyl k dispozici vhodn´ y generátor. Nástroj sice poskytuje funkci pro vytvoˇren´ı vlastn´ıho generátoru hodnot, ale nepodaˇrilo se mi takto vytvoˇren´ y generátor um´ıstit do nab´ıdky generátor˚ u. Vˇetˇsina pˇreddefinovan´ ych generátor˚ u maj´ı moˇznost zvolit si rozsah, v jakém se maj´ı generovat hodnoty pro dan´ y sloupec a v jakém intervalu se maj´ı tyto hodnoty opakovat. Ve vlastnostech projektu lze nastavit, napˇr. poˇcet vygenerovan´ ych ˇrádk˚ u pro vˇsechny tabulky nebo formát generátoru datum˚ u. Poˇcet vygenerován´ ych ˇra´dek je moˇzné nastavit individuálnˇe ke kaˇzdé tabulce. V této chv´ıli jiˇz máme nastavené generován´ı a zb´ yvá jen nastavit poˇrad´ı tabulek, ve kterém se maj´ı generovat data, aby se správnˇe uloˇzily hodnoty ciz´ıch kl´ıˇc˚ u. Po tomto kroku spust´ıme proces generován´ı, ve kterém jeˇstˇe definujeme, kam se maj´ı vygenerovaná data uloˇzit. Prvn´ı moˇznost´ı je uloˇzit data pˇr´ımo do databáze. Druhá moˇznost je generovat data pˇr´ımo do souboru s pˇr´ıponou .sql. My zvol´ıme moˇznost prvn´ı - generován´ı dat do databáze protoˇze kdybychom zvolili generován´ı do souboru, tak by se neuloˇzily hodnoty ciz´ıch kl´ıˇc˚ u. Po dokonˇcen´ı generován´ı testovac´ıch dat m˚ uˇzeme ovˇeˇrit jestli se vˇsechna data vygenerovala. Otevˇreme si databázi napˇr. v programu SQL Oracle Developer a zkontrolujeme obsah naplnˇen´ ych tabulek. Kaˇzdá z tabulek obsahuje jeden milion ˇrádek, aby bylo moˇzné d˚ ukladnˇe otestovat v´ ykonost celé databáze pˇri velkém mnoˇzstv´ı uloˇzen´ ych dat. Cel´ y proces generován´ı trvá v pr˚ umˇeru mezi 20 - 30 hodinami. Ovˇsem záleˇz´ı na fyzickém stroji, na kterém tento proces generován´ı prob´ıhá.

33

6 Návrh datového modelu v Neo4j Pˇredchoz´ı kapitola se zab´ yvala anal´ yzou datového schématu EEG/ERP portálu, z nˇehoˇz byla vybrána vhodná podmnoˇzina. C´ılem této kapitoly je navrhnout pro vybranou podmnoˇzinu datov´ y model grafové databáze Neo4j a popsat, jak vypadá v´ ysledná datová struktura.

6.1

Mapov´ an´ı z datov´ eho sch´ ematu relaˇ cn´ı datab´ aze

Datové schéma v relaˇcn´ıch databáz´ıch je reprezentováno tabulkami, tzn. data jsou uloˇzena do jednotliv´ ych sloupc˚ u a ˇra´dk˚ u. Abychom mohli tato data pˇrevést do grafové struktury je nutné nejprve definovat pravidla za jak´ ych je to moˇzné. Kaˇzdá záznam v tabulce datového schématu relaˇcn´ı databáze je v grafové struktuˇre vyjádˇren jako vrchol. Jednotlivé sloupce v tabulce jsou v grafové struktuˇre uloˇzeny jako vlastnosti, které bl´ıˇze popisuj´ı dan´ y vrchol. Vlastnosti v daném vrcholu jsou definovány jako dvojice kl´ıˇc/hodnota. Kl´ıˇcem je vˇzdy název vlastnosti, kter´ y odpov´ıdá sloupci v datovém schématu relaˇcn´ı databáze a hodnotou, která odpov´ıdá ˇra´dku v datovém schématu relaˇcn´ı databáze m˚ uˇze b´ yt libovoln´ y primitivn´ı datov´ y typ (String, integer, boolean, ...). Mezi jednotliv´ ymi tabulkami relaˇcn´ı databáze m˚ uˇzou existovat r˚ uzné vztahy, které jsou v grafové struktuˇre vyjádˇreny hranou. V relaˇcn´ı databázi obvykle rozliˇsujeme dva typy vazby: • 1:N - tato vazba v terminologii relaˇcn´ıch databáz´ıch znamená, ˇze pˇriˇrazujeme jednomu záznamu v jedné tabulce v´ıce záznam˚ u z jiné tabulky. V grafové struktuˇre tato vazba odpov´ıdá orientované hranˇe, smˇeˇruj´ıc´ı od jednoho vrcholu ke druhému. • M:N - v relaˇcn´ıch databáz´ıch se u této vazby vytváˇr´ı tzv. vazebn´ı tabulka, která tvoˇr´ı vazbu mezi dvˇema tabulkami. Tato vazba umoˇzn ˇuje nˇekolika záznam˚ um z jedné tabulky pˇriˇradit nˇekolik záznam˚ u z tabulky druhé. V grafové struktuˇre tato vazba odpov´ıdá neorientované hranˇe, kterou popisuj´ı vlastnosti obsahuj´ıc´ı data z vazebn´ı tabulky.

34

Návrh datového modelu v Neo4j

6.2

Schéma datového modelu

Sch´ ema datov´ eho modelu

Na obrázku 6.1 je zobrané schéma datové struktury popsané grafem, kter´ y se skládá z vrchol˚ u a hran. Graf obsahuje vˇsechny typy vazeb, které jsou obsaˇzené v datovém schématu relaˇcn´ı databáze pro jeden konkrétn´ı záznam. Graf je tvoˇren jedn´ım poˇcáteˇcn´ım vrcholem oznaˇcen´ ym jako koˇrenov´ y, ze kterého jsou postupnˇe vytváˇreny dalˇs´ı vrcholy.

Obrázek 6.1: Ukázka návrhu grafové struktury v Neo4j.

35

Návrh datového modelu v Neo4j

6.3

Popis datového modelu

Popis datov´ eho modelu

Datov´ y model je tvoˇren nˇekolika vrcholy, které jsou mezi sebou nˇejak´ ym zp˚ usobem propojené. Spoleˇcné vlastnosti vˇsech vrchol˚ u jsou napˇr. identifikátor vrcholu (ˇc´ıselná hodnota) a typ, kter´ y je tvoˇren názvem tˇr´ıdy popisuj´ıc´ı danou entitu, napˇr. entities.Experiment. Základn´ım vrcholem této datové struktury je koˇrenov´ y vrchol, o kterého se postupnˇe vytváˇrej´ı ostatn´ı vrcholy. Druh´ ym vytvoˇren´ ym vrcholem je vrchol typu Experiment, kter´ y obsahuj´ıc´ı informace o experimentech. Od tohoto vrcholu se vytváˇrej´ı ostatn´ı vrcholy typu napˇr. Digitalization, Artefact, Scenario, atd. Vˇsechny vrcholy jsou propojené orientovanou hranou a neobsahuj´ı ˇza´dn´ y cyklus. Kaˇzdá hrana obsahuje vlastnost, napˇr. REF_EXPERIMENT identifikuj´ıc´ı vrchol, do kterého hrana smˇeˇruje. Kompletn´ı statistika o stavu vygenerovaného grafu je v tabulce 6.1. Celkov´ y poˇcet vrchol˚ u

20 034 839

Celkov´ y poˇcet hran

20 020 000

Celkov´ y poˇcet vlastnost´ı

94 630 475

Velikost databáze

14 GB

Tabulka 6.1: Statistika vytvoˇrené grafové databáze Neo4j.

36

7 Implementace datového modelu v Neo4j Tato kapitola popisuje postup implementace datového modelu v grafové databázi Neo4j za pouˇzit´ı Java API, které bylo popsáno v kapitole o Neo4j. Vytvoˇren´ı grafové databáze Neo4j je d˚ uleˇzitou ˇcásti v celém experimentu, aby bylo moˇzné porovnat datov´ y model relaˇcn´ı databáze s datov´ ym modelem grafové databáze.

7.1

Pouˇ zit´ e technologie

Pˇri implementaci grafové databáze v Neo4j byly pouˇzity tyto technologie: • Neo4j Community 2.0.0 M02 - knihovna pro vytvoˇren´ı grafové databáze • Java (JDK 1.7) - jazyk, ve kterém se provede implementace grafové databáze Neo4j • Oracle 11g - databázov´ y server, na kterém bˇeˇz´ı relaˇcn´ı databáze stávaj´ıc´ıho EEG/ERP portálu

7.2

Popis implementace

Aplikace je ˇclenˇena do nˇekolika logick´ ych blok˚ u tzv. packages, pˇriˇcemˇz samotná tˇr´ıda, která spouˇst´ı aplikaci se nacház´ı v koˇrenové ˇca´sti aplikace. Ve struktuˇre aplikace se nacházej´ı tyto bloky entities, relationships, utils. Podrobnˇejˇs´ı popis vˇsech ˇca´st´ı aplikace bude uveden dále. Na obrázku 7.1 je v´ yvojov´ y diagram, kter´ y obsahuje jednotlivé kroky, kter´ ymi lze doc´ılit k vytvoˇren´ı kompletn´ı grafové databáze. V rozhodovac´ı ˇcásti se algoritmus rozhoduje, zda-li ukonˇcit vytváˇren´ı grafové databáze, v pˇr´ıpadˇe, ˇze jsou vˇsechny data z relaˇcn´ı databáze Oracle naˇctena, a nebo pokraˇcovat v naˇc´ıtán´ı dat. 37

Implementace datového modelu v Neo4j

Popis implementace

Obrázek 7.1: V´ yvojov´ y diagram vytvoˇren´ı grafové databáze Neo4j.

Client Hlavn´ı tˇr´ıda, která obsahuje nˇekolik d˚ uleˇzit´ ych metod. Prvn´ı metodou je main(), která vytváˇr´ı hlavn´ı vlákno aplikace. V tˇele této metody se nejprve zpracuj´ı zadané argumenty, kde prvn´ı argument je hodnota, od které se budou naˇc´ıtat data z Oracle databáze a druh´ y argument pˇredstavuje cestu k vytvoˇrené grafové databázi. Poté se vytvoˇr´ı grafová databáze na disku podle zadané cesty a nakonec se zavolá metoda generateGraphDatabase(), která napln´ı vytvoˇrenou grafovou databázi daty z databáze Oracle. void generateGraphDatabase(BatchInserter batchDb,int startNumber, DdConfig dbConfig) Metoda nejprve naˇcte data v daném rozsahu z Oracle databáze pomoc´ı metody loadDataFromDb(), vytvoˇr´ı strukturu grafové databáze a napln´ı j´ı naˇcten´ ymi daty z Oracle databáze a uzavˇre databázové pˇripojen´ı. void clearDb(String pathDb) Vymaˇze celou databázi v pˇr´ıpadˇe, ˇze existuje. Tato metoda se volá jen v pˇr´ıpadˇe, pokud je hodnota prvn´ıho argumentu rovna nule. Proto aby bylo moˇzné vytvoˇrit prázdnout databázi v prvn´ı iteraci generován´ı grafové databáze. 38

Implementace datového modelu v Neo4j

Popis implementace

DbConfig Tˇr´ıda popisuje vlastnosti pro ukládán´ı informac´ı o pˇripojen´ı k databázi Oracle, napˇr. pˇrihlaˇsovac´ı jméno, heslo, název sluˇzby. Tyto informace jsou zadavány pˇri spuˇstˇen´ı této aplikace.

ImportDataFromDb Tato tˇr´ıda poskytuje prostˇredek pro z´ıskán´ı dat z Oracle databáze prostˇrednictv´ım JDBC ovladaˇce. Obsahuje jedinou metodu loadDataFromDb(), která naˇcte data z Oracle databáze. void loadDataFromDb() V tˇele metody dojde nejprve k pˇripojen´ı prostˇrednictv´ım JDBC ovladaˇce k Oracle databázi a poté se vykoná dotaz, kter´ y má za u ´kol naˇc´ıst urˇciou mnoˇzinu dat podle zadané poˇca´teˇcn´ı hodnoty, od které se zaˇcnou data naˇc´ıtat, a poˇctu dat. Takto naˇctená data se uloˇz´ı do struktury HashMap, která se zpˇr´ıstupn´ı metodˇe generateGraphDatabase().

Bal´ık relationships V tomto bal´ıku se nacház´ı v´ yˇctov´ y typ RelationshipTypeEnum, kter´ y obsahuje názvy vlastnost´ı hran mezi vrcholy v grafové struktuˇre.

Bal´ık entities Tento bal´ık obsahuje jednotlivé tˇr´ıdy reprezentuj´ıc´ı danou entitu. Vˇsechny tyto tˇr´ıdy jsou oddˇedˇené od tˇr´ıdy Entity, která poskytuje vˇsem sv´ ym potomk˚ um spoleˇcné vlastnosti (Id, Type). V kaˇzdé z tˇechto tˇr´ıd se volá metoda, která vytvoˇr´ı vrchol s vlastnostmi dané entity. Entitou m˚ uˇze b´ yt napˇr. Person, Experiment, DataFile, a dalˇs´ı.

Bal´ık utils Bal´ık obsahuje jedinou tˇr´ıdu Converter, která primárnˇe slouˇz´ı pro pˇrevod mezi datov´ ym typem Date a String. Tato tˇr´ıda obsahuje metody convertFromDateToString() a convertFromStringToDate().

39

8 Testován´ı a zhodnocen´ı výsledk˚ u Prvn´ı ˇcást této kapitoly je vˇenována samotnému testován´ı relaˇcn´ı databáze Oracle a grafové databáze Neo4j s c´ılem zjistit, kter´ y z testovan´ ych databázov´ ych systému má flexibilnˇejˇs´ı datov´ y model a rychleji vykonané dotazy. Vˇsechny z´ıskané v´ ysledky z prvn´ı ˇca´sti kapitoly jsou zhodnoceny v druhé ˇcásti kapitoly a na základnˇe nich se rozhodne, zda-li se vyplat´ı pouˇz´ıt grafovou databázi Neo4j nebo z˚ ustat u relaˇcn´ı databáze Oracle.

8.1

Testov´ an´ı

Testován´ı je ned˚ uleˇziˇstˇejˇs´ı ˇca´st´ı v této práci, které má pomoci rozhodnout, která ze dvou testovan´ ych databáz´ı je vhodnˇejˇs´ı. Základn´ı poˇzadavky na v´ ybˇer databáze jsou: • Flexibiln´ı datov´ y model - moˇznost rozˇs´ıˇren´ı souˇcasného datového modelu o dalˇs´ı entity a zmˇena stávaj´ıc´ı entity. • Rychlost vykon´ an´ı dotaz˚ u - dotaz by mˇel b´ yt vykonán rychleji neˇz v dosavadn´ı relaˇcn´ı databázi Oracle Proces testován´ı prob´ıhal na lokáln´ım poˇc´ıtaˇci z d˚ uvodu snaˇzˇs´ıho pˇr´ıstupu k databázov´ ym server˚ um a v pˇr´ıpadˇe potˇreby zmˇenit nastaven´ı tˇechto server˚ u. Dále bude uvedena konfigurace poˇc´ıtaˇce, na kterém prob´ıhalo testován´ı.

Konfigurace poˇ c´ıtaˇ ce Testován´ı probˇehlo na poˇc´ıtaˇci s touto konfigurac´ı: • Procesor: Intel Core i7 CPU • Pamˇ et’ RAM: 4GB • Operaˇ cn´ı syst´ em: Window 7 Professional • Typ syst´ emu: 64bitov´ y operaˇcn´ı systém • Hardisk: WD 300GB 40

Testován´ı a zhodnocen´ı výsledk˚ u

8.1.1

Testován´ı

Flexibilita datov´ eho modelu

Datov´ y model m˚ uˇzeme povaˇzovat za flexibln´ı, pokud ho lze rozˇs´ıˇrit bez toho, aniˇz bychom poruˇsili stávaj´ıc´ı koncept datového modelu. V pˇr´ıpadˇe relaˇcn´ı databáze Oracle je flexibilita závislá na sloˇzitosti a provázanosti datového schématu, tud´ıˇz nemus´ı b´ yt jednoduché rozˇs´ıˇrit stávaj´ıc´ı model o nˇejakou dalˇs´ı entitu. V grafové databázi Neo4j máme v´ıce moˇznost´ı jak rozˇs´ıˇrit stávaj´ıc´ı datov´ y model o dalˇs´ı entitu. Prvn´ı moˇznost´ı je vytvoˇrit si nejprve novou tˇr´ıdu, která reprezentuje sv´ ymi vlastnostmi danou entitu a tu prostˇrednictv´ım Java API pˇridat do stávaj´ıc´ıho datového modelu. Druhou moˇznost´ı je pouˇz´ıt nˇekter´ y z dostupn´ ych vizualizaˇcn´ıch nástroj˚ u, které byly popsány v kapitole 3. Pomoc´ı tˇechto nástroj˚ u lze pomˇernˇe snadno pˇridat dalˇs´ı entitu do stávaj´ıc´ıho datového modelu. Dále si pop´ıˇseme jak rozˇs´ıˇrit oba datové modely (Oracle, Neo4j) o novou entitu nazvanou PHARMACEUTICAL, která uchovává informace informace o lec´ıch souvisej´ıc´ı s jednotliv´ ymi experimenty.

Oracle V datovém schématu relaˇcn´ı databáze Oracle vytvoˇr´ıme novou tabulku s názvem PHARMACEUTICAL a poté pˇridáme nové sloupce (title, description), které reprezentuj´ıc´ı název a popis jednotliv´ ych lék˚ u uloˇzen´ ych v tabulce. Jelikoˇz poˇzadujeme, aby jeden záznam z tabulky EXPERIMENT mohl m´ıt v´ıce záznam˚ u z tabulky PHARMACEUTICAL a jeden záznam z tabulky PHARMACEUTICAL mohl patˇrit v´ıce záznam˚ um z tabulky EXPERIMENT je nutné zaloˇzit vazebn´ı tabulku s názvem PHARMACEUTICAL_REL, která bude obsahovat ciz´ı kl´ıˇc na tabulku EXPERIMENT a PHARMACEUTICAL. Daleko vˇetˇs´ı problém je pokud bychom z tabulky PHARMACEUTICAL odstranili sloupec, kter´ y by pouˇz´ıvala jiná tabulka. Dalˇs´ı problém m˚ uˇze vzniknout pˇri zmˇenˇe datového typu nˇejakého sloupce. V pˇr´ıpadˇe pˇridán´ı nového sloupce do tabulky, kterému nastav´ıme defaultn´ı hodnotu nebo ho nastav´ıme na nepovinn´ y (not null) k problému nedojde.

Neo4j Datov´ y model grafové databáze Neo4j se skládá z vrchol˚ u a hran a jeho rozˇs´ıˇren´ı o dalˇs´ı vrchol a hranu je jednoduˇs´ı neˇz v pˇr´ıpadˇe relaˇcn´ıho datového sché41


Testován´ı

matu. K rozˇs´ıˇren´ı pouˇzijeme vizualizaˇcn´ı nástroj Neoclipse, ve kterém nejprve vytvoˇr´ıme nov´ y typ hrany s názvem REF_EXPERIMENT_PHARMACEUTICAL a poté definujeme nov´ y vrchol s vlastnostmi (title, description). Takto vznikl´ y vrchol napoj´ıme do s´ıtˇe stávaj´ıc´ıho datového modelu. V pˇr´ıpadˇe rozˇs´ıˇren´ı o dalˇs´ı sloupec se jedná jen o pˇridán´ı nové vlastnosti vˇcetnˇe jej´ı hodnoty. Pokud bychom chtˇeli odebrat nˇejak´ y sloupec máme dvˇe moˇznosti. Bud’ nechat stávaj´ıc´ı sloupec a pˇridat jin´ y s t´ım, ˇze ten star´ y se bude pˇri dotazován´ı ignorovat, a nebo ho vymazat a pˇridat nov´ y sloupec jako v pˇredchoz´ım pˇr´ıpadˇe.

8.1.2

Rychlost vykon´ an´ı dotaz˚ u

Rychlost vykonán´ı dotaz˚ u je dalˇs´ım poˇzadavkem pˇri v´ ybˇeru vhodného databázového systému. V kapitole porovnán´ı relaˇcn´ıch a nerelaˇcn´ıch databáz´ıch byly popsány rozd´ıly mezi tˇemito databázemi, které se liˇsily hlavnˇe v rychlosti proveden´ı dotaz˚ u. V této ˇcásti kapitoly je hlavn´ım pˇredmˇetem testován´ı právˇe rychlost vykonan´ ych dotaz˚ u, pro kter´ y bylo sestaveno pˇet dotaz˚ u a ty budou postupnˇe vykonány nad relaˇcn´ı databáz´ı Oracle a poté nad grafovou databáz´ı Neo4j. U kaˇzdého dotazu bude uveden struˇcn´ y popis, tzn. co kter´ y dotaz dˇelá, syntaxe obou dotazovac´ıch jazyk˚ u (SQL, Cypher) a nakonec tabuka namˇeˇren´ ych hodnot ˇcasu stráveného vykonán´ım dotazu pro oba databázové systémy. Celé testován´ı prob´ıhalo tak, ˇze kaˇzd´ y dotaz byl vykonán opakovanˇe pro r˚ uzn´ y poˇcet záznam˚ u, nejprve pro 1000 záznam˚ u a poté pro 10 000 záznam˚ u. Kv˚ uli pamˇetové nebylo moˇzné dotazovat se vˇetˇs´ıho poˇcet záznam˚ u. Pˇri pokusu o vˇetˇs´ı mnoˇzstv´ı dat doˇslo ke zpomalen´ı stroje, pˇri kterém nebylo moˇzné pokraˇcovat v testován´ı a bylo nutné ukonˇcit spuˇstˇen´ y dotaz. Pro r˚ uzn´ y poˇcet záznam˚ u se dotaz vykonal pˇetkrát. Pˇred samotn´ ym mˇeˇren´ım bylo d˚ uleˇzité rozhodnout o tom, jak´ ym zp˚ usobem mˇeˇrit ˇcas vykonán´ı dotazu. Na v´ ybˇer je hodnota ˇcasu vykonán´ı dotazu, tzv. executing time, která pˇredstavuje ˇcas, za kter´ y se vykoná dan´ y dotaz bez zobrazen´ı mnoˇziny v´ ysledk˚ u. Druhou moˇznost´ı je vz´ıt ˇcas vykonán´ı dotazu a zobrazen´ı v´ ysledk˚ u dotazu, tzv. fetch time, kter´ y pˇredstavuje ˇcas, za kter´ y se dan´ y dotaz vykoná a zobraz´ı se pˇr´ısluˇsná mnoˇzina v´ ysledk˚ u. Pˇri tomto testován´ı je d˚ uleˇzitá hodnota vykonán´ı dotazu a ne hodnota ˇcasu zobrazen´ı, jelikoˇz vykreslen´ı hodnot na v´ ystup m˚ uˇze m´ıt za následek zpoˇzdˇen´ı, které nelze dopˇredu pˇredpov´ıdat. Jednotlivé hodnoty ˇcas˚ u jsou uvedeny v sekundách.

42


Testován´ı

Jako nástroj pro testován´ı rychlosti vykonán´ı dotazu v relaˇcn´ı databázi Oracle byl pouˇzit SQL Developer Oracle, kter´ y se standardnˇe pouˇz´ıvá pro práci s touto databáz´ı. Pro testován´ı rychlosti vykonán´ı dotazu v grafové databázi Neo4j byl zvolen nástroj Web admin, kter´ y je souˇca´st´ı knihovny Neo4j, a umoˇzn ˇuje vykonávat dotazy prostˇrednictv´ım konzole.

Dotaz ˇ c. 1 - Select persons Dotaz vybere vˇsechny osoby a ke kaˇzdé osobˇe zobraz´ı informace o ni samotné vˇcetnˇe nejvyˇsˇs´ıho dosaˇzeného vzdˇelán´ı.

Oracle SELECT p . p e r s o n i d , p . givenname , p . a u t h e n t i c a t i o n , p . surname , p . d a t e o f b i r t h , p . gender , p . email , p . phone number , p . note , p . username , p . password , p . a u t h o r i t y , p . co nfirmed , p . f b u i d , p . r e g i s t r a t i o n d a t e , p . l a t e r a l i t y , e l . t i t l e as education level title FROM p e r s o n p INNER JOIN e d u c a t i o n l e v e l e l ON p. education level id = el . education level id

V´ ypis 8.1: Pˇr´ıklad skriptu pro v´ ybˇer osob v SQL

Jednotlivé kroky mˇeˇren´ı [s] Poˇ cet z´ aznam˚ u

[s]

1

2

3

4

5

Pr˚ umˇ er

1000

0,675

0,655

0,662

0,718

0,665

0,675

10 000

2,925

2,525

2,41

2,442

2,483

2,557

Tabulka 8.1: Tabulka s namˇeˇren´ ymi ˇcasy vykonán´ı dotazu nad Oracle.

Neo4j START p = node : e e g i n d e x ( ’_Type : entities . Person ’ ) MATCH p − [ :REF PERSON EDUCATION LEVEL]−>ed

43


Testován´ı

RETURN p . Id , p . GivenName , p . A u t h e n t i c a t i o n , p . SurName , p . DateOfBirth , p . Gender , p . Email , ed . T i t l e as E d u c a t i o n L e v e l p . Note , p . UserName , p . Password , p . Authority , p . Confirmed , p . FbUID , p . R e g i s t r a t i o n D a t e , p . L a t e r a l i t y , p . PhoneNumber

V´ ypis 8.2: Pˇr´ıklad skriptu pro v´ ybˇer osob v Cypheru


[s]

1

2

3

4

5

Pr˚ umˇ er

1000

0,422

0,468

0,335

0,322

0,353

0,380

10 000

1,811

1,953

2,045

1,655

1,578

1,808

Tabulka 8.2: Tabulka s namˇeˇren´ ymi ˇcasy vykonán´ı dotazu nad Neo4j.

Dotaz ˇ c. 2 - Select experiment Dotaz vybere vˇsechny informace o experimentech a ke kaˇzdému z nich zobraz´ı informace o nˇem samotném vˇcetnˇe entit, které jsou s n´ım v relaci.

Oracle SELECT ex . e x p e r i m e n t i d , ex . s t a r t t i m e , ex . e n v i r o n m e n t n o t e , ex . end time , ex . temperature , p . username as Owner , sp . username as S u b j e c t P e r s o n , w . t i t l e as Weather , s g . T i t l e as SubjectGroup , r g . t i t l e as ResearchGroup , d . g a i n as D i g i t i z a t i o n , s c . t i t l e as S c e n a r i o , e c . impedance as E l e c t r o d e C o n f , e s . t i t l e , a . compensation FROM e x p e r i m e n t ex INNER JOIN p e r s o n p ON ex . o w n e r i d = p . p e r s o n i d LEFT JOIN p e r s o n sp ON ex . s u b j e c t p e r s o n i d = sp . p e r s o n i d INNER JOIN s c e n a r i o s c ON ex . s c e n a r i o i d = s c . s c e n a r i o i d INNER JOIN weather w ON ex . w e a t h e r i d = w . w e a t h e r i d INNER JOIN r e s e a r c h g r o u p r g ON ex . r e s e a r c h g r o u p i d = rg . r e s e a r c h g r o u p i d INNER JOIN s u b j e c t g r o u p s g ON ex . s u b j e c t g r o u p i d = s g . s u b j e c t g r o u p i d

44


Testován´ı

INNER JOIN e l e c t r o d e c o n f e c ON ex . e l e c t r o d e c o n f i d = e c . e l e c t r o d e c o n f i d INNER JOIN d i g i t i z a t i o n d ON ex . d i g i t i z a t i o n i d = d . d i g i t i z a t i o n i d INNER JOIN a r t e f a c t a ON ex . a r t e f a c t i d = a . a r t e f a c t i d INNER JOIN e l e c t r o d e s y s t e m e s ON ec . e l e c t r o d e s y s t e m i d = es . e l e c t r o d e s y s t e m i d

V´ ypis 8.3: Pˇr´ıklad skriptu pro v´ ybˇer experiment˚ u v SQL Jednotlivé kroky mˇeˇren´ı [s] Poˇ cet z´ aznam˚ u

[s]

1

2

3

4

5

Pr˚ umˇ er

1000

3,97

4,167

3,575

4,018

3,973

3,941

10 000

43,17

35,155

30,89

36,385

38,365

36,793


Neo4j START exp = node : e e g i n d e x ( ’_Type : entities . Experiment ’ ) MATCH exp − [ :REF EXPERIMENT OWNER]−>ow , exp − [ :REF EXPERIMENT SUBJECT PERSON]−>sp , exp − [ :REF EXPERIMENT SCENARIO]−>sc , exp − [ :REF EXPERIMENT WEATHER]−>w, exp − [ :REF EXPERIMENT RESEARCH GROUP]−>rg , exp − [ :REF EXPERIMENT SUBJECT GROUP]−>sg , exp − [ :REF EXPERIMENT ELECTRODE CONF]−>ec , exp − [ :REF EXPERIMENT DIGITIZATION]−>dig , ec − [ :REF ELECTRODE CONF ELECTRODE SYSTEM]−> e s RETURN exp . Id , exp . StartTime , exp . EndTime , exp . Temperature , exp . EnvironmentNote , ow . UserName as Owner , sp . UserName as S u b j e c t P e r s o n , s c . T i t l e as S c e n a r i o , w . T i t l e as Weather , r g . T i t l e as ResearchGroup , s g . T i t l e as SubjectGroup , e c . Impedance as E l e c t r o d e C o n f , d i g . Gain as D i g i t i z a t i o n , e s . T i t l e as E l e c t r o d e S y s

V´ ypis 8.4: Pˇr´ıklad skriptu pro v´ ybˇer experiment˚ u v Cypheru 45


Testován´ı


[s]

1

2

3

4

5

Pr˚ umˇ er

1000

0,458

0,415

0,361

0,387

0,376

0,399

10 000

2,855

3,000

3,261

3,675

3,238

3,206

Tabulka 8.4: Tabulka s namˇeˇren´ ymi ˇcasy vykonán´ı dotazu nad Neo4j. Dotaz ˇ c. 3 - Select scenarios Dotaz vybere vˇsechny scénáˇre a ke kaˇzdému scénáˇri zobraz´ı informace o nˇem samotném vˇcetnˇe v´ yzkumné skupiny a správce scénáˇre.

Oracle SELECT s c . s c e n a r i o i d , s c . t i t l e , s c . s c e n a r i o l e n g t h , s c . d e s c r i p t i o n , s c . p r i v a t e , s c . s c e n a r i o n a m e , s c . mimetype , ow . username , r g . t i t l e as r e s e a r c h g r o u p t i t l e FROM s c e n a r i o s c INNER JOIN p e r s o n ow ON s c . o w n e r i d = ow . p e r s o n i d INNER JOIN r e s e a r c h g r o u p r g ON sc . r e s e a r c h g r o u p i d = rg . r e s e a r c h g r o u p i d

V´ ypis 8.5: Pˇr´ıklad skriptu pro v´ ybˇer scénáˇr˚ u v SQL


[s]

1

2

3

4

5

Pr˚ umˇ er

1000

0,877

0,767

0,758

0,803

0,648

0,771

10 000

5,553

5,397

6,485

5,295

5,633

5,673


46


Testován´ı

Neo4j START s c = node : e e g i n d e x ( ’_Type : entities . Scenario ’ ) MATCH sc − [ :REF SCENARIO RESEARCH GROUP]−>rg , sc − [ :REF SCENARIO OWNER]−>ow RETURN s c . Id , s c . T i t l e , s c . D e s c r i p t i o n , s c . S c e n a r i o L e n g t h , s c . P r i v a t e , s c . ScenarioName , s c . MimeType , r g . T i t l e as ResearchGroup , ow . UserName

V´ ypis 8.6: Pˇr´ıklad skriptu pro v´ ybˇer scénáˇr˚ u v Cypheru


[s]

1

2

3

4

5

Pr˚ umˇ er

1000

0,434

0,384

0,238

0,223

0,223

0,211

10 000

1,323

1,294

1,169

0,957

1,105

1,170


Dotaz ˇ c. 4 - Select research groups Dotaz vybere vˇsechny v´ yzkumné skupiny a ke kaˇzdé skupinˇe zobraz´ı informace o ni samotné vˇcetnˇe poˇctu uˇzivatel˚ u v dané skupinˇe.

Oracle SELECT r g . t i t l e , r g . d e s c r i p t i o n , COUNT( p . p e r s o n i d ) as pocet uzivatelu FROM r e s e a r c h g r o u p r g INNER JOIN p e r s o n p ON p . pe rs on id = rg . owner id GROUP BY r g . t i t l e , r g . d e s c r i p t i o n

V´ ypis 8.7: Pˇr´ıklad skriptu pro v´ ybˇer v´ yzkumn´ ych skupin v SQL

47


Testován´ı


[s]

1

2

3

4

5

Pr˚ umˇ er

1000

1,067

0,759

0,938

0,803

0,899

0,893

10 000

2,228

2,052

3,086

1,847

2,717

2,386

Tabulka 8.7: Tabulka s namˇeˇren´ ymi ˇcasy vykonán´ı dotazu nad Oracle. Neo4j START r g = node : e e g i n d e x ( ’_Type : entities . ResearchGroup ’ ) MATCH rg − [ :REF RESEARCH GROUP OWNER]−>ow RETURN r g . Id , r g . T i t l e , r g . D e s c r i p t i o n , COUNT(ow . Id ) as PocetUzivatelu

V´ ypis 8.8: Pˇr´ıklad skriptu pro v´ ybˇer v´ yzkumn´ ych skupin v Cypheru


[s]

1

2

3

4

5

Pr˚ umˇ er

1000

0,21

0,21

0,178

0,148

0,245

0,198

10 000

0,667

0,650

0,517

0,660

0,491

0,593


Dotaz ˇ c. 5 - Select electrode confs Dotaz vybere vˇsechny konfigurace elektrod, které maj´ı menˇs´ı impedanci neˇz 500 a ke kaˇzdé z nich zobraz´ı informace o ni samotné vˇcetnˇe m´ısta osazen´ı elektrod.

48


Testován´ı

Oracle SELECT e c . e l e c t r o d e c o n f i d , e c . impedance , e s . t i t l e as electrode system FROM e l e c t r o d e c o n f e c INNER JOIN e l e c t r o d e s y s t e m e s ON ec . e l e c t r o d e s y s t e m i d = es . e l e c t r o d e s y s t e m i d WHERE e c . impedance < 500

V´ ypis 8.9: Pˇr´ıklad skriptu pro v´ ybˇer konfigurac´ı elektrod v SQL

Poˇ cet z´ aznam˚ u

1

2

3

4

5

Pr˚ umˇ er

1000

0,327

0,296

0,359

0,375

0,395

0,350

10 000

2,373

2,561

2,42

2,39

2,36

2,421


Neo4j START e c = node : e e g i n d e x ( ’_Type : entities . ElectrodeConf ’ ) MATCH ec − [ :REF ELECTRODE CONF ELECTRODE SYSTEM]−> e s WHERE e c . Impedance < 500 RETURN e c . Id , e c . Impedance , e s . T i t l e as E l e c t r o d e S y s t e m

V´ ypis 8.10: Pˇr´ıklad skriptu pro v´ ybˇer konfigurac´ı elektrod v Cypheru

Poˇ cet z´ aznam˚ u

1

2

3

4

5

Pr˚ umˇ er

1000

0,08

0,06

0,077

0,085

0,052

0,071

10 000

0,242

0,333

0,655

0,418

0,317

0,393


49


8.2

Zhodnocen´ı výsledk˚ u

Zhodnocen´ı v´ ysledk˚ u

V pˇredchoz´ı ˇcásti kapitoly byly otestovány dva poˇzadavky na datov´ y model relaˇcn´ı databáze Oracle a nerelaˇcn´ı grafové databáze Neo4j. Prvn´ım poˇzadavkem byla flexibilita datov´ eho modelu, která by umoˇznila snadné rozˇs´ıˇren´ı datového modelu o dalˇs´ı entitu. Druh´ ym poˇzadavkem byla rychlost vykon´ an´ı dotazu. Z hlediska flexibility datového modelu lze prohlásit, ˇze u grafové databáze Neo4j je rozˇs´ıˇren´ı datového modelu snadnˇejˇs´ı a pˇr´ıstupnˇejˇs´ı neˇz u relaˇcn´ı databáze Oracle. D˚ uvodem je skuteˇcnost, ˇze v pˇr´ıpadˇe Neo4j staˇc´ı vytvoˇrit nov´ y vrchol a ten napojit do s´ıtˇe vrchol˚ u a pojmenovat vlastnosti. Tato zmˇena nikterak nenaruˇsuje souˇcasn´ y koncept datového modelu. U relaˇcn´ı databáze Oracle je tomu naopak, jelikoˇz rozˇs´ıˇren´ı stávaj´ıc´ıho datového schématu o dalˇs´ı tabulku vyˇzaduje postup, kter´ y je mnohdy komplikovanˇejˇs´ı. Druh´ ym poˇzadavkem na testován´ı byla rychlost vykonán´ı dotazu nad obˇema databázov´ ymi systémy. Testován´ı rychlosti prob´ıhalo tak, ˇze kaˇzd´ yz dotaz˚ u byl opakovanˇe vykonán a to vˇzdy pro r˚ uzn´ y poˇcet záznam˚ u, tzn. 1000 a 10 000 záznam˚ u, aby se ovˇeˇrila v´ ykonost databáze pˇri v´ ybˇeru vˇetˇs´ıho poˇctu záznam˚ u. Pro detailnˇejˇs´ı pohled namˇeˇren´ ych hodnot ˇcas˚ u obsahuje tabulka 8.11 pr˚ umˇerné ˇcasy spuˇstˇen´ ych dotaz˚ u v konkrétn´ım databázovém systému (Oracle, Neo4j) a u kaˇzdého z nich pˇr´ıpadné zrychlen´ı. U obou databázov´ ych systému byla provedena optimalizace a to pˇredevˇs´ım prostˇrednictv´ım vytvoˇren´ı index˚ u. V pˇr´ıpadˇe databáze Oracle se jednalo o vytvoˇren´ı index˚ u pro primárn´ı a ciz´ı kl´ıˇce. Dále také optimalizaci spuˇstˇen´ ych dotaz˚ u, kterou nejlépe zajist´ı databázov´ y engine. U grafové databáze Neo4j byly vytvoˇreny indexy pro vˇsechny vlastnosti popisuj´ıc´ı vrcholy. Indexován´ı slouˇz´ı pˇredevˇs´ım ke zrychlen´ı vykonáván´ı dotaz˚ u. Z v´ ysledku tˇechto namˇeˇren´ ych pr˚ umˇern´ ych hodnot a urychlen´ı je vidˇet, ˇze vykonán´ı dotaz˚ u nad grafovou databáz´ı Neo4j je ˇra´dovˇe rychlejˇs´ı neˇz v pˇr´ıpadˇe relaˇcn´ı databáze Oracle. V´ yraznˇe se tento rozd´ıl projevuje u dotaz˚ u, které pˇristupuj´ı k dat˚ um z jin´ ych entit. Napˇr´ıklad u dotazu, kter´ y zobrazuje informace o experimentech a pˇritom pˇristupuje k dat˚ um z jin´ ych entit, je urychlen´ı Neo4j aˇz 11x oproti relaˇcn´ı databázi Oracle.

50


Zhodnocen´ı výsledk˚ u

Velikost grafové databáze Neo4j má vliv na velikost operaˇcn´ı pamˇeti RAM. Tato pamˇet’ová závislost se projevuje hlavnˇe pˇri vykonáván´ı dotaz˚ u, kdy je celá databáze vloˇzena do operaˇcn´ı pamˇeti RAM, ale jen pˇri prvn´ım spuˇstˇen´ı dotazu. Pˇri dalˇs´ım spuˇstˇen´ı dotazu uˇz jsou data pˇr´ıstupná jen z operaˇcn´ı pamˇeti RAM. Operaˇcn´ı pamˇet’ je urˇcená pro doˇcasné uloˇzen´ı dat a má rychlejˇs´ı pˇr´ıstup neˇz vnˇejˇs´ı pamˇet’ (napˇr. pevn´ y disk). Tato skuteˇcnost je podloˇzena v následujic´ı citaci z dokumentace, která je k dispozici na oficiáln´ıch stránkách Neo4j. Neo4j tries to memory-map as much of the underlying store files as possi” ble. If the available RAM is not sufficient to keep all data in RAM, Neo4j will use buffers in some cases, reallocating the memory-mapped high-performance I/O windows to the regions with the most I/O activity dynamically. Thus, ACID speed degrades gracefully as RAM becomes the limiting factor.”[9] V závˇeru zhodnocen´ı testován´ı je nutné rozhodnout, zda-li je vhodnˇejˇs´ı pouˇz´ıt grafovou databázi Neo4j nebo z˚ ustat u souˇcasné relaˇcn´ı databáze Oracle. Z dosaˇzen´ ych v´ ysledk˚ u testován´ı je patrné, ˇze v obou kritéri´ıch (flexibilita, rychlost) je vhodnˇejˇs´ı pouˇz´ıt grafovou databázi Neo4j. Jedinou pˇrekáˇzkou m˚ uˇze b´ yt pamˇet’ová závislost na fyzické pamˇeti RAM, ale záleˇz´ı na hardwaru daného stroje, na kterém databáze pobˇeˇz´ı. Z mého pohledu se Neo4j jev´ı jako vhodná pro pouˇzit´ı v EEG/ERP portálu, aˇckoliv se mi nepodaˇrilo kv˚ uli pamˇet’ové nároˇcnosti zajistit u ´plnˇe zat´ıˇzˇen´ı Neo4j databáze pˇri vˇetˇs´ım poˇctu záznam˚ u v dotazech. I tak si mysl´ım, ˇze tato knihovna má velkou budoucnost a uplatnˇen´ı se na trhu. Dotaz

Oracle [s]

Neo4j [s]

Zrychlen´ı

select persons

0,675

0,380

1,41x

select experiments

36,793

3,206

11,48x

select scenarious

5,673

1,170

4,85x

select research groups

2,386

0,593

4,02x

select electrode confs

2,421

0,393

6,16x

Tabulka 8.11: Zrychlen´ı jednotliv´ ych dotaz˚ u pro 10 0000 záznam˚ u.

51

9 Závˇer V rámci diplomové práce jsem nejprve prostudoval moˇznosti nerelaˇcn´ıch databáz´ı a poté provedl srovnán´ı s databázemi relaˇcn´ımi. Zamˇeˇril jsem se jen na databáze grafové a vybral tˇri zástupce (Neo4j, OrientDB a DEX). Z tˇechto tˇr´ı zástupc˚ u jsem vybral databázi, která vyhovovala nejlépe a tou je Neo4j. V dalˇs´ım kroku jsem se d˚ ukladnˇe seznámil s touto grafovou databáz´ı a poté provedl anal´ yzu stávaj´ıc´ıho datového schématu EEG/ERP portálu a vybral vhodnou podmnoˇzinu. Na této podmnoˇzinˇe relaˇcn´ı databáze Oracle za pomoci nástroje Datanamic Data for Oracle jsem vygeneroval testovac´ı data, která jsou d˚ uleˇzité pro implementaci datového modelu grafové databáze Neo4j. Na základˇe této vybrané podmnoˇziny jsem navrhl datov´ y model grafové databáze Neo4j a ten implementoval pomoc´ı Java API. Po implementaci jsem grafovou databázi Neo4j otestoval spolu s relaˇcn´ı databáz´ı Oracle, kde bylo c´ılem rozhodnout, která z testovan´ ych databáz´ı je vhodnˇejˇs´ı pro pouˇzit´ı v EEG/ERP portálu. Testovaly se dva základn´ı poˇzadavky nad obˇema databázema - flexibilita datového modelu a rychlost vykonán´ı dotazu. Podle zhodnocen´ı dosaˇzen´ ych v´ ysledku (viz pˇredchoz´ı kapitola) byla zvolena za vhodnou databázi právˇe grafová databáze Neo4j, která dosahuje lepˇs´ıch v´ ysledk˚ u v testován´ı poˇzadavk˚ u na flexibilitu a rychlost vykonán´ı dotaz˚ u. Samozˇrejmˇe se jedná jen o doporuˇcen´ı, které nemus´ı b´ yt realizováno z d˚ uvod˚ u, které byly popsány v pˇredchoz´ı kapitole. Napˇr´ıklad se m˚ uˇze jednat o pamˇet’ovou závislost databáze na velikosti operaˇcn´ı pamˇeti RAM. Tato práce byla pro mˇe velmi zaj´ımavá z ohledem na to, ˇze jsem si vyzkouˇsel práci s relativnˇe mladou, ale slibnou databáz´ı Neo4j, která se ˇrad´ı do skupiny NoSQL databáz´ı. V souˇcasné dobˇe se NoSQL databáze stále rozv´ıj´ı a do budoucna se mohou stát velmi vyuˇz´ıvanou skupinou databáz´ı v mnoha oblastech. Hlavn´ım d˚ uvodem je rostouc´ı objem dat a flexibiln´ı datové schéma, na které jiˇz klasické relaˇcn´ı databáze nestaˇc´ı. V´ yˇse uvedené body dokazuj´ı, ˇze c´ıle diplomové práce byly u ´spˇeˇsnˇe splnˇeny a také se vymezuje proti oborovému projektu, kter´ y se zab´ yval studi´ı tˇr´ı grafov´ ych databáz´ı.

52

Literatura [1] Eeg database. URL https://github.com/INCF/eeg-database. Navˇst´ıveno: 20.04.2013. [2] Jacomy M Bastian M., Heymann S. Oficiáln´ı stránky vizualizaˇcn´ıho nástroje gephi. URL http://www.gephi.org. Navˇst´ıveno: 22.04.2013. [3] McCrory’s Blog. Cap theorem and clouds. URL http://blog. mccrory.me/2010/11/03/cap-theorem-and-the-clouds/. Navˇst´ıveno: 08.05.2013. [4] Ing. Petr Br˚ uha. Diplomová práce EEG/ERP portál a prostˇredky sémantického webu. 2011. [5] Luca Garulli. Oficiáln´ı stránky technologie orientdb. URL http://www. orientdb.org/orient-db.htm. Navˇst´ıveno: 15.04.2013. [6] Richard G¨ unzl. Bakaláˇrská práce na téma NoSQL databáze. 2012. [7] Aleksa Vukotic Jonas Partner. Neo4j in Action. Manning Publications, 2013. Navˇst´ıveno: 08.04.2013. [8] Sergejus Barinovas | Microsoft MVP. Prezentace na téma nosql - what’s that? URL http://www.slideshare.net/sergejus/ nosql-whats-that. Navˇst´ıveno:: 08.05.2013. [9] Inc Neo Technology. Oficiáln´ı stránky technologie neo4j. URL http: //www.neo4j.org/. Navˇst´ıveno: 05.04.2013. [10] Peter Neubauer. Graph databases, nosql and neo4j. URL http://www. infoq.com/articles/graph-nosql-neo4j. Navˇst´ıveno: 08.05.2013. [11] The University of West Bohemia. Oficiáln´ı stránky eeg/erp portálu. URL http://eegdatabase.kiv.zcu.cz/home.html. Navˇst´ıveno: 10.04.2013. 53

LITERATURA

LITERATURA

[12] Amit Piplani. U pick 2 selection for nosql providers. URL http://amitpiplani.blogspot.cz/2010/05/ u-pick-2-selection-for-nosql-providers.html. Navˇst´ıveno: 01.05.2013. [13] Martin Strbaˇcka. Diplomová práce Vytvoˇren´ı publikaˇcn´ıho standardu v oblasti evokovaných potenciál˚ u. 2012. [14] Sparsity Technologies. Oficiáln´ı stránky technologie dex. URL http: //www.sparsity-technologies.com/index/. Navˇst´ıveno: 28.04.2013.

54

A Uˇzivatelská dokumentace Tato kapitola popisuje pr˚ ubˇeh celého procesu testován´ı, od samotné instalace potˇrebn´ ych nástroj˚ u aˇz k testován´ı poˇzadavk˚ u. Prvn´ı ˇcást kapitoly se zab´ yvá popisem instalace nástroj˚ u pro samotné testován´ı a druhá kapitola popisuje pouˇzit´ı tˇechto nástroj˚ u pˇri testován´ı. Na pˇriloˇzeném CD se nacházej´ı nástroje vyuˇzité v pr˚ ubˇehu testován´ı kromˇe Oracle serveru, kter´ y je ke staˇzen´ı na ofiiciáln´ıch stránkách spoleˇcnosti Oracle.

A.1

Pˇ r´ıprava n´ astroj˚ u pro testov´ an´ı

Ke zprovoznˇen´ı celého procesu testován´ı je d˚ uleˇzité nainstalovat nˇekolik nástroj˚ u, které maj´ı na starosti nˇejakou ˇcinnost spojenou s procesem testován´ı. Nejprve nainstalujeme Oracle server v aktuáln´ı verzi 11g pˇr´ıpadnˇe verzi 10g, která je ke staˇzen´ı na oficiáln´ıch stránkách spoleˇcnosti Oracle. Po u ´spˇeˇsné instalaci je potˇreba vytvoˇrit lokáln´ı databázi. K tomu pouˇzijeme nástroj Database Configuration Assistant, kter´ y je souˇca´st´ı nainstalovaného Oracle serveru. V pr˚ ubˇehu vytváˇren´ı lokáln´ı databáze vytvoˇr´ıme uˇzivatele, jehoˇz pˇrihlaˇsovac´ı u ´daje budou slouˇzit pro pˇr´ıstup k vytvoˇrené databázi. Dále specifikujeme název sluˇzby, pod kterou databáze pobˇeˇz´ı. Po tomto kroku máme vytvoˇrenou databázi, ke které se pˇripoj´ıme napˇr´ıklad pomoc´ı nástroje Oracle SQL Developer, kter´ y se pouˇz´ıvá ke správˇe databáze. Na pˇriloˇzeném CD se nacház´ı sloˇzka scripts, která obsahuje skript pro vytvoˇren´ı databáze a skripty testovac´ıch dotaz˚ u pro oba databázové systémy. y otevˇreme poV této sloˇzce najdeme soubor s názvem create model.sq, kter´ moc´ı jiˇz zm´ınˇeného nástroje Oracle SQL Developer a poté spust´ıme. Tento skript nám vytvoˇr´ı strukturu tabulek vybrané podmnoˇziny EEG/ERP portálu. Kdyˇz máme vytvoˇrené datové schéma podmnoˇziny EEG/ERP portálu, je nutné jej naplnit testovac´ımi daty. Vyuˇzijeme k tomu nástroj Datanamic Data for Oracle, prostˇrednictv´ım nˇehoˇz vygenerujeme testovac´ı data pˇr´ımo do vytvoˇrené databáze. V tuto chv´ıli jiˇz máme vˇse potˇrebné pro otestován´ı relaˇcn´ı databáze Oracle, ale nejdˇr´ıve vytvoˇr´ıme grafovou databázi Neo4j. Ve sloˇzce Apps se nacház´ı sloˇzka Neo4j Graph Database Creating, ve které je soubor run.bat, kter´ y spust´ı proces vytváˇren´ı grafové databáze Neo4j. V tomto souboru je 55

Uˇzivatelská dokumentace

Spuˇstˇen´ı testován´ı

nutné pˇred spuˇstˇen´ım nastavit parametry pro pˇripojen´ı k relaˇcn´ı databázi Oracle, tzn. pˇrihlaˇsovac´ı jméno, heslo a název spuˇstˇené sluˇzby. Ukázka spuˇstˇen´ı procesu vytváˇren´ı grafové databáze Neo4j vˇcetnˇe parametr˚ u je n´ıˇze. Neo4JEEG.jar \%\%i [filePath] [userName] [password] [serviceName] Spuˇstˇen´ı aplikace prob´ıhá opakovanˇe, a to vˇzdy s jin´ ym vstupn´ım parametrem %%i, ker´ y oznaˇcuje ˇcást dat, která se má naˇc´ıst z relaˇcn´ı databáze Oracle. Dalˇs´ı parametry jako napˇr. userName, password slouˇz´ı pro pˇripojen´ı k databázi Oracle. D˚ uvodem opakovaného spuˇstˇen´ı aplikace je velké mnoˇzˇ sen´ım je tedy stv´ı dat, které nebylo moˇzné najednou naˇc´ıst do pamˇeti. Reˇ postupné naˇcten´ı ˇca´sti dat z relaˇcn´ı databáze Oracle, které se pouˇzij´ı pˇri vytváˇren´ı grafové databáze Neo4j. Tato aplikace vyuˇz´ıvá k vytvoˇren´ı grafové databáze prostˇredky, které jsou obsaˇzeny v knihovnˇe Neo4j.

A.2

Spuˇ stˇ en´ı testov´ an´ı

V této fázi testován´ı jiˇz máme vytvoˇrené obˇe databáze a naplnˇené testovac´ımi daty. Nyn´ı m˚ uˇzeme otestovat oba poˇzadavky, které byly zm´ınˇené v kapitole testován´ı. Pro upˇresnˇen´ı uvedu, ˇze jde o poˇzadavek na flexibiln´ı datov´ y model databáze a rychlost vykonán´ı dotazu. Testovac´ı scénáˇre dotaz˚ u pro oba databázové systémy jsou um´ıstˇené ve sloˇzce scripts.

A.2.1

Testov´ an´ı datab´ aze Oracle

Nejdˇr´ıve otestujeme relaˇcn´ı databázi Oracle. K testován´ı pouˇzijeme nástroj SQL Oracle Developer v nˇemˇz otevˇreme konkrétn´ı skript s dotazem, kter´ y chceme otestovat. Napˇr´ıklad otevˇreme soubor select person.sql a spust´ıme dotaz, kter´ y nám vrát´ı seznam osob z tabulky Person. Na obrázku A1 je vidˇet ukázka testován´ı tohoto dotazu, kter´ y byl vykonán pro 10 000 záznam˚ u. V pˇr´ıpadˇe otestován´ı flexibility datového schématu otevˇreme skript s názvem pharmaceutical table.sq a spust´ıme. Vytvoˇr´ı se nám tabulka PHARMACEUTICAL a vazebn´ı tabulka PHARMACEUTICAL_REL.

56



Obrázek A.1: Ukázka pouˇzit´ı nástroje SQL Oracle Developer pˇri testován´ı.

A.2.2

Testov´ an´ı datab´ aze Neo4j

Pro otestován´ı grafové databáze Neo4j pouˇzijeme webové rozhran´ı Web admin, které je souˇcást´ı knihovny Neo4j um´ıstˇené ve sloˇzce Apps. Soubor ke spuˇstˇen´ı tohoto webového rozhran´ı se nacház´ı ve sloˇzce bin pod názvem neo4j.bat. Samotné webové rozhran´ı si zobraz´ıme pomoc´ı prohl´ıˇzeˇce, ve kterém zadáme adresu http://localhost:7474. Ve webovém rozhran´ı prostˇrednictv´ım konozle otestujeme rychlost vykonán´ı dotazu, a to tak, ˇze do konzole vloˇz´ıme dotaz v jazyce Cypher. Dotaz vrát´ı 10 000 záznam˚ u, které obsahuj´ı informace o lidech, kteˇr´ı se pod´ılej´ı na experimentech. Pˇri prvn´ım spuˇstˇen´ı dotazu dojde k naˇcten´ı celé grafové databáze do operaˇcn´ı pamˇeti RAM, proto je lepˇs´ı zmˇeˇrit rychlost v´ ykonu dotazu aˇz pˇri dalˇs´ım spuˇstˇen´ı. Ukázka spuˇstˇen´ı dotazu v nástroji Web admin je vidˇet na obrázku A2.

57



Obrázek A.2: Ukázka pouˇzit´ı nástroje Web admin pˇri testován´ı.

58

B Schéma grafové struktury v Neo4j

Obrázek B.1: Ukázka grafové struktury v Neo4j bez vlastnost´ı. 59

Schéma grafové struktury v Neo4j

Obrázek B.2: Ukázka rozˇs´ıˇren´ı grafové struktury o entitu Pharmaceutical

60

C Obsah pˇriloˇzené CD Na CD, jeˇz je pˇriloˇzeno k této diplomové prác, se nacház´ı tato struktura: • Doc - obsahuje elektronickou podobu této dokumentace • Apps - v této sloˇzce jsou nástroje pro spuˇstˇen´ı celého procesu testován´ı – Datanamic Data Generator for Oracle - nástroj pro spuˇstˇen´ı generován´ı testovac´ıch dat k relaˇcn´ı databázi Oracle – Neo4j Community 2.0.0.2 - knihovna práci s grafovou databáz´ı Neo4j obsahuj´ıc´ı nástroj Web admin – Neo4j Graph Database Creating - aplikace pro vytvoˇren´ı grafové databáze podle vybrané podmnoˇziny EEG/ERP portálu • Scripts - v této sloˇzce se nacházej´ı veˇskeré testovac´ı skripty dostupné v jazyku SQL a Cypher

C.1

Struktura aplikace Neo4j Graph Database Creating

• dist - obsahuje spustiteln´ y soubor s pˇr´ıponou .jar • run.bat - soubor, kter´ y spust´ı aplikaci opakovanˇe s r˚ uzn´ ym parametrem pro zadán´ı zaˇcátku naˇc´ıtán´ı dat z databáze • src - sloˇzka obsahuj´ıc´ı zdrojové kódy aplikace – entities - bal´ıˇcek obsahuj´ıc´ı tˇr´ıdy reprezentuj´ıc´ı jednotlivé entity – relationships - bal´ıˇcek obsahuj´ıc´ı v´ yˇctov´ y typ definuj´ıc´ı jednotlivé vztahy v grafu – utils - obsahuje jedinou tˇr´ıdu s pomocn´ ymi metodami

61

Západočeská univerzita v Plzni Fakulta aplikovaných věd Katedra informatiky a výpočetní techniky

Recommend Documents