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 Spr´ avce datab´ az´ı pro vybran´ y NoSQL datab´ azov´ y syst´ em

Plzeˇ n 2014

Barbora Staffová

Prohl´ aˇ sen´ı Prohlaˇsuji, ˇze jsem diplomovou práci vypracovala samostatnˇe a v´ yhradnˇe s pouˇzit´ım citovan´ ych pramen˚ u. V Plzni dne 11. kvˇetna 2014 Barbora Staffová

Abstract This thesis deals with the creation of database manager for NoSQL database system Redis. In the first part of the document the basic database terminology is described. Then the current NoSQL database systems are introduced and compared with relational database systems. In the second part there is presented the analysis of solutions for the resulting program NoSqlManager. The next part describes the creation of the application itself and its functions. The applicability of the final database manager was tested in a distributed environment. Tato diplomová práce se zab´ yvá tvorbou správce pro NoSQL databázov´ y systém Redis. V prvn´ı ˇca´sti dokumentu jsou vysvˇetleny základn´ı pojmy o databáz´ıch. Dále jsou pˇredstaveny souˇcasné NoSQL databázové systémy a jejich srovnán´ı s relaˇcn´ımi databázov´ ymi systémy. V druhé ˇcásti je popsána anal´ yza ˇreˇsen´ı pro v´ ysledn´ y program NoSqlManager. Dalˇs´ı ˇca´st popisuje vytvoˇren´ı samotného správce databáze a jeho funkce. Pouˇzitelnost v´ ysledného správce databáze byla otestována v distribuovaném prostˇred´ı.

Obsah ´ 1 Uvod

1

2 Z´ akladn´ı pojmy a teorie 2.1 Big data . . . . . . . . . . . . . . . . ˇ 2.2 SRBD . . . . . . . . . . . . . . . . . . 2.3 Databázové modely . . . . . . . . . . 2.3.1 Otevˇrené soubory . . . . . . . 2.3.2 Hierarchick´ y databázov´ y model 2.3.3 S´ıt’ov´ y databázov´ y model . . . 2.3.4 Relaˇcn´ı databázov´ y model . . . 2.4 ACID . . . . . . . . . . . . . . . . . . 3 Relaˇ cn´ı datab´ aze 3.1 Popis . . . . . . . . . 3.2 Integritn´ı omezen´ı . . 3.3 Normáln´ı formy . . . 3.4 SQL . . . . . . . . . 3.5 Hlavn´ı pˇredstavitelé

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

4 NoSQL datab´ aze 4.1 Popis . . . . . . . . . . . . . . . . 4.2 Base . . . . . . . . . . . . . . . . . 4.3 CAP teorém . . . . . . . . . . . . 4.4 Map Reduce . . . . . . . . . . . . 4.5 Distribuce dat . . . . . . . . . . . . ˇ alovatelnost . . . . . . . . . . . 4.6 Sk´ 4.7 Dotazován´ı . . . . . . . . . . . . . 4.8 Datov´ y model . . . . . . . . . . . 4.8.1 Databáze typu kl´ıˇc/hodnota 4.8.2 Dokumentové databáze . . 4.8.3 Sloupcové databáze . . . .

. . . . .

. . . . . . . .

. . . . .

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

. . . . . . . .

. . . . .

. . . . . . . . . . .

. . . . . . . .

. . . . .

. . . . . . . . . . .

. . . . . . . .

. . . . .

. . . . . . . . . . .

. . . . . . . .

. . . . .

. . . . . . . . . . .

. . . . . . . .

. . . . .

. . . . . . . . . . .

. . . . . . . .

. . . . .

. . . . . . . . . . .

. . . . . . . .

. . . . .

. . . . . . . . . . .

. . . . . . . .

. . . . .

. . . . . . . . . . .

. . . . . . . .

. . . . .

. . . . . . . . . . .

. . . . . . . .

. . . . .

. . . . . . . . . . .

. . . . . . . .

. . . . .

. . . . . . . . . . .

. . . . . . . .

. . . . .

. . . . . . . . . . .

. . . . . . . .

. . . . .

. . . . . . . . . . .

. . . . . . . .

. . . . .

. . . . . . . . . . .

. . . . . . . .

. . . . .

. . . . . . . . . . .

. . . . . . . .

. . . . .

. . . . . . . . . . .

. . . . . . . .

2 2 3 4 4 5 6 7 7

. . . . .

9 9 9 10 11 12

. . . . . . . . . . .

15 15 16 17 18 20 21 21 22 23 24 26

OBSAH

OBSAH

4.8.4 Grafové databáze . . . . . . . . . . . . . . . . . . . . . . . . 28 4.9 Riak . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 4.10 Redis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 5 Porovn´ an´ı NoSQL datab´ az´ı s relaˇ cn´ımi datab´ azemi

37

6 Anal´ yza probl´ emu 6.1 Typ NoSQL databáze . . . . . . . . . . . 6.2 Databázov´ y systém pro key/value databázi 6.3 Webové vs. desktopové ˇreˇsen´ı . . . . . . . 6.4 Existuj´ıc´ı ˇreˇsen´ı pro Redis . . . . . . . . . 6.5 Základn´ı funkce správce . . . . . . . . . .

. . . . . . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

39 39 39 41 42 43

7 Realizace spr´ avce datab´ aze 7.1 Návrh správce databáze . . . . 7.1.1 Programovac´ı jazyk . . 7.1.2 Rozvrˇzen´ı programu . . 7.1.3 GUI . . . . . . . . . . . 7.2 V´ yvojové nástroje . . . . . . . . 7.3 Pˇripojen´ı k databázi . . . . . . 7.4 Konzole . . . . . . . . . . . . . 7.5 Import a export JSON soubor˚ u 7.6 Ukládán´ı konfigurace pˇripojen´ı

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

44 44 44 45 46 49 50 53 56 58

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

8 Testov´ an´ı 61 8.1 Testovac´ı scénáˇre . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61 9 Z´ avˇ er

65

A Uˇ zivatelsk´ a pˇ r´ıruˇ cka

73

B Graf z´ avislost´ı

82

C Obsah DVD

83

iv

Seznam obr´ azk˚ u 2.1 2.2 2.3 2.4

Big data a 3V. [Lac12] . . . . . . . . . . . . . . . . . . . . . . . . . ˇ Báze dat a systém ˇr´ızen´ı báze dat (SRBD) tvoˇr´ıc´ı databázov´ y systém. [Sch88] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Hierarchick´ y model databáze. . . . . . . . . . . . . . . . . . . . . . S´ıt’ov´ y model databáze. . . . . . . . . . . . . . . . . . . . . . . . .

.

3

. . .

4 5 6

3.1 3.2

Normáln´ı formy. [Kul08] . . . . . . . . . . . . . . . . . . . . . . . . . 11 Poˇcet nainstalovan´ ych a nasazen´ ych databázov´ ych systém˚ u podle spoleˇcnosti Gartner v roce 2008.[MaS08] . . . . . . . . . . . . . . . . . . 12

4.1 4.2 4.3 4.4 4.5 4.6

CAP teorém. [Ver13] . . . . . . . . . . . . . . MapReduce. [Gro09] . . . . . . . . . . . . . . Datové modely NoSQL. [Kat12] . . . . . . . . Datov´ y model v databázi Cassandra. [Mam11] Ukázkov´ y model grafové databáze. [Pok12] . . Riak ring. [Ria11] . . . . . . . . . . . . . . . .

5.1

Ukázka pouˇzit´ı nˇekolika databázov´ ych systém˚ u v jednom projektu. [Sad12] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

7.1 7.2

Hlavn´ı okno programu NoSqlManager. . . . . . . . . . . . . . . . . . 47 Konzole programu NoSqlManager. . . . . . . . . . . . . . . . . . . . . 48

A.1 A.2 A.3 A.4 A.5 A.6 A.7 A.8 A.9

Ukázka hlavn´ıho okna programu NoSqlManager. . . . . . . . . Okno pro pˇridán´ı a editaci pˇripojen´ı. . . . . . . . . . . . . . . Ukázka stromové struktury seznamu pro pˇripojen´ı. . . . . . . Ukázka nab´ıdky nad zvolen´ ym serverem. . . . . . . . . . . . . Ukázka okna s informacemi o serveru. . . . . . . . . . . . . . . Konzolové okno. . . . . . . . . . . . . . . . . . . . . . . . . . . Ukázka s nˇekolika záloˇzkami. . . . . . . . . . . . . . . . . . . . Ukázka okna pro pˇridán´ı nového kl´ıˇce do databáze. . . . . . . Ukázka okna pro pˇridáván´ı a u ´pravu hodnot kl´ıˇce typu Hash.

v

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . . . . .

. . . . . .

. . . . . . . . .

. . . . . .

. . . . . . . . .

. . . . . .

. . . . . . . . .

18 19 23 26 28 31

75 76 76 77 77 78 79 79 80

´ ˚ SEZNAM OBRAZK U

´ ˚ SEZNAM OBRAZK U

A.10 Ukázka okna pro zobrazen´ı náhledu kl´ıˇce. . . . . . . . . . . . . . . . . 81 B.1 Graf závislost´ı jednotliv´ ych jmenn´ ych prostor˚ u vygenerovan´ y Visual Studiem. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82

vi

´ 1 Uvod V dneˇsn´ı dobˇe d´ıky nár˚ ustu mobiln´ıch a elektronick´ ych zaˇr´ızen´ı stoupá i mnoˇzstv´ı uloˇzen´ ych dat a nároky na rychlost jejich zpracován´ı. Stále ˇcastˇeji se v reálné praxi objevuje situace, kdy dnes hojnˇe pouˇz´ıvané relaˇcn´ı databáze pˇrestávaj´ı dostaˇcovat sv´ ym datov´ ym modelem. D´ıky tomu se na scénˇe objevily NoSQL databáze, které jsou schopny zpracovat velké objemy dat (tzv. Big data) r˚ uzn´ ych struktur. Nejedná se vˇsak o náhradu stávaj´ıc´ıch relaˇcn´ıch databáz´ı. Obˇe tato ˇreˇsen´ı maj´ı stále svá specifická uplatnˇen´ı. Relaˇcn´ı databáze vycházej´ı z klasického pojet´ı datov´ ych struktur, tzn., ˇze vazby a struktura dat je pˇresnˇe specifikovaná. Na rozd´ıl od toho NoSQL databáze nemaj´ı pˇresnˇe specifikovanou strukturu. V´ yvoj NoSQL databáz´ı ˇsel nˇekolika smˇery, které umoˇznily vzniku r˚ uzn´ ych typ˚ u databáz´ı. Tyto smˇery jsou reprezentovány databázemi key/value, sloupcov´ ymi, dokumentov´ ymi a grafov´ ymi databázemi. NoSQL databáze jsou hojnˇe vyuˇz´ıvány pˇredevˇs´ım u sociáln´ıch s´ıt´ı, jako je Facebook nebo Twitter, kde se kaˇzd´ ym dnem enormnˇe zvyˇsuje poˇcet uchovávan´ ych dat. C´ılem této diplomové práce je zanalyzovat souˇcasné druhy NoSQL databázov´ ych systém˚ u, pˇriˇcemˇz v´ ysledné poznatky porovnat s relaˇcn´ımi databázov´ ymi systémy a v návaznosti na to vybrat vhodnou NoSQL databázi. V tomto pˇr´ıpadˇe byla zvolena na základˇe anal´ yzy problému databáze Redis, která je typu key/value. Dalˇs´ım c´ılem bylo praktické vyuˇzit´ı zm´ınˇené databáze pro navrˇzen´ı správce, kter´ y bude umoˇzn ˇovat uˇzivatelsky pˇr´ıjemnou práci s daty uloˇzen´ ymi v uvedené databázi a následnˇe na to implementovat ˇreˇsen´ı s ohledem na poskytovaná API (Application Programming Interface) systému a v závˇeru pak v´ ysledného správce otestovat a zhodnotit. Diplomová práce je rozdˇelena do kapitol. Prvn´ı kapitola se zab´ yvá teoretick´ ym u ´vodem do problematiky databáz´ı. V druhé kapitole jsou podrobnˇe popsány relaˇcn´ı databáze a jejich vlastnosti. V tˇret´ı kapitole je detailnˇe probrána problematika NoSQL databáz´ı. Jsou zde uvedeny hlavn´ı pˇredstavitelé jednotliv´ ych typ˚ u NoSQL databáz´ı. Dalˇs´ı kapitola se zab´ yvá porovnán´ım relaˇcn´ıch a NoSQL databáz´ı. Na to navazuj´ı kapitoly, v kter´ ych docház´ı k popisu realizace tvorby správce NoSQL databáze. Na závˇer práce je uvedena kapitola, která zahrnuje v´ ysledky testován´ı napsaného správce. V dodatku je pˇriloˇzena uˇzivatelská dokumentace, graf závislost´ı jednotliv´ ych jmenn´ ych prostoru a popis obsahu pˇriloˇzeného DVD.

1

2 Základn´ı pojmy a teorie V souˇcasnosti se hojnˇe pracuje s velk´ ymi objemy informac´ı, jejichˇz zpracován´ı a ukládán´ı se stává v´ yznamnou otázkou pˇredevˇs´ım v oblasti informaˇcn´ıch technologi´ı. Informace vznikaj´ı zpracován´ım a strukturován´ım surov´ ych dat, která dávaj´ı urˇcitému jedinci nebo organizaci v´ yznam. [Con09] Organizované soubory dat, které se pouˇz´ıvaj´ı k modelován´ı r˚ uzn´ ych organizaˇcn´ıch struktur nebo proces˚ u, se naz´ yvaj´ı databáze. Databáze b´ yvá definována jako sebe popisuj´ıc´ı kolekce integrovan´ ych záznam˚ u. D´ıky sebe popisuj´ıc´ımu charakteru databáze je zajiˇstˇena nezávislost dat. Tud´ıˇz zmˇenou struktur v databázi nejsou ovlivnˇeny existuj´ıc´ı databázové aplikace, pokud se jich zmˇena pˇr´ımo net´ yká. [Her06]

2.1

Big data

V posledn´ıch letech se d´ıky rozˇs´ıˇren´ı webu, mobiln´ıch aplikac´ıch a dalˇs´ıch nov´ ych technologi´ıch v´ yraznˇe zvˇetˇsilo mnoˇzstv´ı uloˇzen´ ych dat, která jsou nestrukturovaná a distribuovaná. S t´ım pˇricház´ı i v´ yraz big data. Tento pojmem si lze pˇredstavit jako soubory dat, které jsou tak rozsáhlé, ˇze se nedaj´ı spravovat, zachycovat a zpracovávat normáln´ımi softwarov´ ymi prostˇredky v rozumném ˇcase. Velikost dat je chápana nejenom z hlediska objemu dat, ale také z hlediska rychlosti jejich tvorby a pˇrenosu. Pro efektivn´ı práci s big daty se vyˇzaduj´ı nové technologie, které budou zpracovávat ˇ data v pˇrijatelném ˇcase. Casto se v souvislosti s big daty mluv´ı o trojrozmˇernosti velikosti a r˚ ustu dat, známé také jako 3V, viz obrázek 2.1. • Objem (volume) – pˇri provozu firem nar˚ ustá mnoˇzstv´ı dat r˚ uzn´ ych typ˚ u exponenciálnˇe. • Typ (variety) – big data jsou r˚ uzn´ ych typ˚ u, mimo obvykl´ ych strukturovan´ ych dat jsou zpracovávána také nestrukturovaná data, napˇr´ıklad textové soubory, data ze senzor˚ u, video soubory a data z log˚ u. • Rychlost (velocity) – velká rychlost vznikaj´ıc´ıch dat a potˇreba jejich anal´ yzy v reálném ˇcase.

2

ˇ SRBD

Základn´ı pojmy a teorie

B´ yvaj´ı uvádˇená i dalˇs´ı V“ jako vˇerohodnost (veracity) nebo variabilita (variability)1 . ” Ve v´ ysledku lze vˇsak shrnout big data tak, ˇze pˇrib´ yvá mnoho r˚ uzn´ ych zaˇr´ızen´ı a systém˚ u, kde data vznikaj´ı. Také roste mnoˇzstv´ı dat a zvyˇsuj´ı se nároky na jejich zpracován´ı. [Dol11]

Obrázek 2.1: Big data a 3V. [Lac12]

2.2

ˇ SRBD

Pojmem databáze b´ yvá ˇcasto zamˇen ˇován s databázov´ ym systém. Databázov´ y sysˇ tém se skládá z báze dat, neboli databáze, a ze systému ˇr´ızen´ı báze dat (SRBD, ˇ anglicky téˇz DBMS), viz obrázek 2.2. SRBD je softwarové vybaven´ı, které umoˇzn ˇuje ˇ uˇzivateli definovat, vytváˇret, udrˇzovat a ˇr´ıdit databázi. SRBD dovoluje uˇzivatel˚ um ˇ aktualizovat, vkládat, mazat a vyvolávat data z databáze. Souˇcást´ı SRBD je také moˇznost dotazován´ı na data pomoc´ı dotazovac´ıch jazyk˚ u jako je napˇr. SQL (Structured Query Language). [Con09] ˇ Pˇred vznikem SRBD se pro poˇc´ıtaˇce dodávalo vˇseobecné programové vybaven´ı, ˇ které mˇelo za u ´kol plnit nˇekteré funkce SRBD. Jednalo se o systémy na ˇr´ızen´ı soubor˚ u ˇ (file management systems). Za kritérium, které rozliˇsuje SRBD od jin´ ych systém˚ u 1

http://www.adastra.cz/co-jsou-big-data

3


Databázové modely Databázový systém

Báze dat

SŘBD

ˇ Obrázek 2.2: Báze dat a systém ˇr´ızen´ı báze dat (SRBD) tvoˇr´ıc´ı databázov´ y systém. [Sch88] s podobnou funkcionalitou, se povaˇzuje to, zda si systém vede a obsahuje katalog dat, do kterého si ukládá strukturu soubor˚ u, s kter´ ymi pracuje. Takováto charakteristika ˇ SRBD umoˇzn ˇuje dosáhnout nezávislosti program˚ u na datech.[Sch88] ˇ Pokud je SRBD bez podpory zobrazován´ı dat na obrazovce poˇc´ıtaˇce ˇci v tiˇstˇené podobˇe, je oznaˇcována jako databázov´ y stroj. Zobrazován´ı dat zajiˇst’uje uˇzivatelská ˇ aplikace. Mezi nˇekteré SRBD patˇr´ı napˇr. Oracle, MS SQL Server, Sybase, Informix nebo freeware programy mSQL, MySQL a PostgreSQL [Kos99].

2.3

Datab´ azov´ e modely

Systémy pro ˇr´ızen´ı báze dat lze rozdˇelit do nˇekolika typ˚ u, které se oznaˇcuj´ı jako modely. Databázové modely urˇcuj´ı logickou strukturu databáze a také jak´ ym zp˚ usobem budou data uloˇzena, organizována a zpracována.

2.3.1

Otevˇ ren´ e soubory

Obyˇcejné soubory operaˇcn´ıho systému jsou oznaˇcovány jako otevˇrené soubory (flat files). To znamená, ˇze záznamy tˇechto soubor˚ u nenesou ˇza´dné doplˇ nuj´ıc´ı informace, které by c´ılové aplikaci pˇredávaly strukturu soubor˚ u nebo vztahy mezi záznamy.

4


Databázové modely

Informace o struktuˇre dat mus´ı b´ yt souˇca´st´ı aplikace, která se souborem pracuje. Databázov´ y systém má, na rozd´ıl od operaˇcn´ıho systému, o tˇechto souborech k dispozici metadata, d´ıky jimˇz m˚ uˇze provádˇet r˚ uzné pˇrevody mezi otevˇren´ ymi soubory ve fyzické vrstvˇe. Metadata, neboli data o datech, jsou v tomto pˇr´ıpadˇe pouˇzita k oznaˇcen´ı informac´ı, které popisuj´ı, jaká data jsou uloˇzena v databázi a vztahy mezi nimi. Otevˇrené soubory zde byly jiˇz pˇred vznikem databáz´ı. Prvn´ı databázové systémy se vyvinuly právˇe z nich. [Opp06]

2.3.2

Hierarchick´ y datab´ azov´ y model

Hierarchick´ y model, kter´ y je zobrazen na obrázku 2.3, je nejstarˇs´ı pouˇz´ıvan´ y model. Poprvé byl pouˇzit v roce 1968 spoleˇcnost´ı IBM u systému IMS. Základem tohoto modelu je stromová struktura vycházej´ıc´ı z jednoho koˇrene. Koˇren (jak je to chápáno v teorii grafu) je jedin´ y uzel, kter´ y nemá rodiˇcovsk´ y uzel. Jednotlivé uzly stromu jsou propojené do hierarchie rodiˇc-potomek, kde jeden rodiˇc m˚ uˇze m´ıt v´ıce potomk˚ u, ale kaˇzd´ y potomek má jen jednoho rodiˇce, neboli uzel vyˇsˇs´ı u ´rovnˇe se vztahuje k v´ıce uzl˚ um na niˇzˇs´ı u ´rovni. Pokud z uzlu nevycház´ı dalˇs´ı vˇetev, je oznaˇcen jako list. V této struktuˇre jsou dva druhy vztah˚ u mezi poloˇzkami, rodiˇcovské a sourozenecké. Kromˇe listu m˚ uˇze m´ıt kaˇzd´ y uzel libovoln´ y poˇcet potomk˚ u. D´ıky tomu se v hierarchickém modelu dobˇre definuj´ı vztahy 1:n, jeden ku mnoha. [Kal12] Vedení podniku

Zaměstnanec

Oddělení

Oddělení

Zaměstnanec

Zaměstnanec

Oddělení

Obrázek 2.3: Hierarchick´ y model databáze.

Hierarchické databáze byly pouˇz´ıvané zejména pro ukládán´ı dat v 70. letech na sálov´ ych poˇc´ıtaˇc´ıch. V´ yhodou hierarchického modelu byl pˇr´ım´ y a rychl´ y pˇr´ıstup k dat˚ um a také moˇznost pˇridáván´ı nov´ ych poloˇzek. Mezi nev´ yhody patˇr´ı sloˇzitá 5


Databázové modely

správa struktura databáze. Pˇri u ´pravˇe vztah˚ u rodiˇc-potomek se mus´ı sloˇzitˇe pˇredˇelávat celá struktura. Nejvˇetˇs´ı nev´ yhodou je vˇsak tvorba vztah˚ u m:n, mnoha k mnoh´ ym. [Her06]

2.3.3

S´ıt’ov´ y datab´ azov´ y model

S´ıt’ová databáze byla vyvinuta jako moˇznost pro vyˇreˇsen´ı problém˚ u vznikaj´ıc´ıch u hierarchické databáze. Tento model umoˇzn ˇuje popisovat v databázi vztahy m:n, mnoha k mnoh´ ym. Struktura s´ıt’ové databáze je popsána pomoc´ı pojm˚ u uzel a mnoˇzinová struktura, kde uzel pˇredstavuje soubor záznam˚ u a mnoˇzinová struktura zastupuje a zˇrizuje vztah. Vztahy mezi daty jsou pojmenovány, tud´ıˇz je v databázi moˇzn´ y pˇrechod z jednoho záznamu na jin´ y pˇres konkrétn´ı relaci. Rozd´ıl oproti hierarchické konstrukci rodiˇc-potomek je takov´ y, ˇze jeden uzel je definovan´ y jako vlastn´ık a druh´ y jako ˇclen. D´ıky mnoˇzinové struktuˇre je podporován vztah 1:n. Vlastn´ık m˚ uˇze b´ yt v relaci k jednomu nebo v´ıce záznam˚ um v uzlu ˇclen. Jeden záznam v uzlu ˇclen je vˇsak ve vztahu pouze k jednomu záznamu v uzlu typu vlastn´ık. Záznam v uzlu typu ˇclen také nem˚ uˇze existovat, pokud by nebyl ve vztahu k záznamu v odpov´ıdaj´ıc´ım uzlu typu vlastn´ık. Pˇr´ıklad s´ıt’ového modelu je na obrázku 2.4. [Her06] Univerzita Vede

Vede Vede

Fakulta Zaměstnává

Zaměstnává

Vyučující

Vyučuje

Fakulta

Vyučující

Fakulta

Zaměstnává

Vyučující

Vyučuje

Vyučuje

Student

Obrázek 2.4: S´ıt’ov´ y model databáze. S´ıt’ov´ y model pˇrináˇs´ı pˇredevˇs´ım vyˇsˇs´ı flexibilitu, snadné pˇridáván´ı nov´ ych zá6


ACID

znam˚ u, omezen´ı nˇekter´ ych duplicitn´ıch záznam˚ u a rychlé vyhledáván´ı dat. Pˇres nˇekterá zlepˇsen´ı oproti hierarchickému modelu se s´ıt’ov´ y model setkává s nutnost´ı správného návrhu prvotn´ı struktury databáze.

2.3.4

Relaˇ cn´ı datab´ azov´ y model

Roku 1969 zveˇrejnil Dr. E. F. Codd ˇclánek, kter´ y definoval model databáz´ı zaloˇzen´ y na matematickém pojmu relaˇcn´ıch mnoˇzin. Tento model se stal nejrozˇs´ıˇrenˇejˇs´ım modelem pouˇz´ıvan´ ym pˇri správˇe databáz´ı. Data se v relaˇcn´ıch databáz´ıch ukládaj´ı ve vztaz´ıch, které uˇzivatelé vid´ı jako tabulky. Vztahy jsou sloˇzeny z tzv. n-tic (ˇra´dk˚ u) a atribut˚ u (sloupc˚ u). Kaˇzd´ y ˇra´dek je v tabulce identifikován sloupcem obsahuj´ıc´ı jedineˇcnou hodnotu. D´ıky tomu nemus´ı uˇzivatel, na rozd´ıl od hierarchického a s´ıt’ového modelu, znát pˇresné fyzické um´ıstˇen´ı záznamu, pokud s n´ım chce pracovat. V´ıce o relaˇcn´ıch databáz´ıch je uvedeno v kapitole 3.

2.4

ACID

Zkratka ACID (Atomicity, Consistency, Isolation, Durability) oznaˇcuje ˇctyˇri základn´ı vlastnosti, které mus´ı splˇ novat transakce. Databázová transakce je soubor pˇr´ıkaz˚ u, kter´ y zjiˇst’uje pˇrevod z jednoho konzistentn´ıho stavu do druhého. Pokud se vyskytne chyba, mus´ı b´ yt moˇzné vrátit celou operaci do p˚ uvodn´ıho stavu. • Atomicita (Atomicity) – Kaˇzdá transakce je atomická (nedˇelitelná), bud’ probˇehnou vˇsechny operace v transakci, nebo ˇza´dná. Pokud selˇze jedna ˇca´st, selˇze celá transakce a stav databáze se vrát´ı do p˚ uvodn´ıho stavu. • Konzistence (Consistency) – Data se pˇred i po proveden´ı transakce nacház´ı v konzistentn´ım stavu. Veˇskerá data zapsaná do databáze mus´ı b´ yt platná podle stanoven´ ych pravidel, transakce nesm´ı poruˇsit ˇzádné integritn´ı omezen´ı. • Izolace (Isolation) – Pˇri paraleln´ım zpracován´ı jsou jednotlivé transakce od sebe izolovány a navzájem se neovlivˇ nuj´ı. • Trvalost (Durability) – Zmˇeny po u ´spˇeˇsné transakci jsou v databázi uloˇzeny natrvalo. Systém, kter´ y splˇ nuje vˇsechny vlastnosti ACID, se oznaˇcuje za silnˇe konzistentn´ı“. ” Takovéto databázové systémy jsou potˇreba v nˇekter´ ych pˇr´ıpadech, jako jsou napˇr. 7


ACID

systémy v obchodech nebo v bankách. Databáze, které zcela nepodporuj´ı vlastnosti ACID, jsou naz´ yvány eventuálnˇe (pˇr´ıpadnˇe) konzistentn´ı“. Data v takov´ ychto data” báz´ıch nejsou konzistentn´ı v libovolném ˇcase, ale konzistence je dosaˇzeno postupnˇe. Pˇr´ıstup eventuálnˇe konzistentn´ıch databáz´ı umoˇzn ˇuje z´ıskat v´ yhodu lepˇs´ı horizontáln´ı ˇskálovatelnosti. Toho vyuˇz´ıvaj´ı pˇredevˇs´ım NoSQL databáze. [Pok97][Tiw11]

8

3 Relaˇcn´ı databáze Relaˇcn´ı databáze je normalizovan´ y systém, kter´ y je zaloˇzen na relaˇcn´ım modelu dat ˇ a je ˇr´ızen pomoc´ı SRBD. Základem kaˇzdé relaˇcn´ı databáze je tabulka neboli relace. Databáze je následnˇe tvoˇrena kolekc´ı tabulek, které jsou navzájem propojeny. Svou oblibu mezi programátory z´ıskaly pˇredevˇs´ım kv˚ uli své jednoduchosti. [Skˇr02]

3.1

Popis

Relace je reprezentována jako tabulka, kde ˇra´dky tabulky reprezentuj´ı datové ntice a sloupce odpov´ıdaj´ı atribut˚ um. I kdyˇz se atributy objev´ı v libovolném poˇrad´ı, bude se jednat o stejnou relaci se stejn´ ym v´ yznamem. Tabulka má jedineˇcné jméno, aby byla odliˇsitelná od ostatn´ıch tabulek v dané databázi. Buˇ nky tabulky mus´ı obsahovat pouze jednu hodnotu (pˇr´ısluˇsná tabulka je tak normalizována do prvn´ı normáln´ı formy). Kaˇzd´ y sloupec má jedineˇcn´ y název a urˇcit´ y datov´ y typ podle dat, ˇ jeˇz maj´ı b´ yt uloˇzena. Rádky tabulky mus´ı m´ıt jedineˇcn´ y identifikátor, coˇz se ˇreˇs´ı pomoc´ı kl´ıˇce. Primárn´ı kl´ıˇc je sloupec nebo mnoˇzina sloupc˚ u, kter´ y jedineˇcnˇe urˇcuje ˇra´dek v tabulce. Ciz´ı kl´ıˇc je také mnoˇzina sloupc˚ u, která nese stejnou hodnotu jako primárn´ı kl´ıˇc ale v jiné tabulce. [Con09] S objevem objektové orientace pˇriˇslo vylepˇsen´ı relaˇcn´ıch databáz´ı. Docház´ı k rozˇs´ıˇren´ı o nov´ y typ, objekt, a o podporu ukládán´ı a práce s n´ım. Vznikaj´ı tak objekˇ ˇ tovˇe relaˇcn´ı SRBD (ORDBMS), které kombinuj´ı vlastnosti relaˇcn´ıch SRBD, jako ˇ je tˇreba dotazovac´ı jazyk SQL, a vlastnosti objektovˇe orientovan´ ych SRBD (OODBMS). Tento model má mnoho v´ yhod, ale stále nen´ı pˇr´ıliˇs rozˇs´ıˇren. [Opp06]

3.2

Integritn´ı omezen´ı

Relaˇcn´ı model dat urˇcuje pouze strukturu dat. Pro praktické pouˇzit´ı je ale nutné zajistit, aby se v relaci vyskytovala pouze logicky správná data. Integritn´ı omezen´ı jsou pravidla, která zabrán´ı vloˇzen´ı nesprávn´ ych data a ztrátˇe nebo poˇskozen´ı stávaj´ıc´ıch u ´daj˚ u pˇri práci s databáz´ı. Entitn´ı integrita zajiˇst’uje jednoznaˇcnost ˇrádku v tabulce, neboli u ´plnost primárn´ıho kl´ıˇce. Dalˇs´ım pravidlem je referenˇcn´ı integrita, která se vztahuje k ciz´ım kl´ıˇc˚ um. Existuje-li v tabulce ciz´ı kl´ıˇc, mus´ı jeho hodnota odpov´ıdat primárn´ımu kl´ıˇci 9

Relaˇcn´ı databáze

Normáln´ı formy

v jiné tabulce. Databáze, která vyhovuje zadan´ ym integritn´ım omezen´ım, se oznaˇcuje za konzistentn´ı. [Con09]

3.3

Norm´ aln´ı formy

D˚ uvodem k zaveden´ı normalizace vedly problémy, jeˇz byly oznaˇcovány jako anomálie, nenormalizovan´ ych relac´ı, které se projevovaly pˇri aktualizaci dat. Normalizace je dekompozice relace, která vznikla kv˚ uli jednoduˇsˇs´ı práci s daty, jejich lepˇs´ı manipulaci, zabránˇen´ı redundance dat a lepˇs´ı konzistenci. Poˇcet normalizaˇcn´ıch u ´rovn´ı, oznaˇcovan´ ych jako normáln´ı formy, je ˇsest. [Opp06] Normáln´ı formy jsou pravidla, podle kter´ ych by se mˇely navrhovat tabulky a jejich vzájemné relace. Jsou oznaˇceny jako 1NF, 2NF, 3NF, BCNF, 4NF a 5NF. Formy smˇeˇruj´ı postupnˇe od niˇzˇs´ıch k vyˇsˇs´ım, kdy kaˇzdá vyˇsˇs´ı normáln´ı forma obsahuje svá vlastn´ı pravidla a podm´ınky forem pˇredchoz´ıch, viz obrázek 3.1. [Kul08] Relace je v prvn´ı normáln´ı formˇe (1NF), pokud jsou data atomická. To znamená, ˇze by jiˇz dále nemˇela b´ yt dˇelitelná, neboli neobsahuje ˇza´dné atributy s násobn´ ymi hodnotami. V druhé normáln´ı formˇe (2NF) se relace nacház´ı, kdyˇz je v 1NF a kaˇzd´ y nekl´ıˇcov´ y atribut je plnˇe funkˇcnˇe závisl´ y na celém primárn´ım kl´ıˇci relace. Relace se nacház´ı v tˇret´ı normáln´ı formˇe (3NF), pokud je v 2NF a kaˇzd´ y nekl´ıˇcov´ y atribut nen´ı tranzitivnˇe závisl´ y na primárn´ım kl´ıˇci, neboli neexistuje závislost mezi dvˇema nekl´ıˇcov´ ymi atributy. Vedle 3NF existuje Boyce-Coddova normáln´ı forma (BCNF), která je silnˇejˇs´ı formou 3NF. Relace je v BCNF, pokud je v 3NF a v relaci neexistuje ˇza´dn´ y urˇcuj´ıc´ı atribut, kter´ y by byl primárn´ım nebo kandidátn´ım kl´ıˇcem. Tzn., ˇze ˇza´dn´ y nekl´ıˇcov´ y atribut nesm´ı urˇcovat hodnotu ˇza´dného jiného atributu, a to ani atribut˚ u, které jsou souˇcást´ı definice primárn´ıho kl´ıˇce. Kaˇzdá relace, která je v BCNF je vˇzdy ve 3NF. Opaˇcnˇe vˇsak 3NF nemus´ı b´ yt v BCNF, jestliˇze nastane situace, kdy v relaci je v´ıce kandidátn´ıch kl´ıˇc˚ u, vˇsechny tyto kandidátn´ı kl´ıˇce jsou sloˇzené a existuje atribut, kter´ y je pro vˇsechny kandidátn´ı kl´ıˇce spoleˇcn´ y. Z praktického hlediska postaˇc´ı vˇetˇsinou transformace relaci do BCNF. Je vˇsak popsán pˇrevod relac´ı dále do ˇctvrté a páté normáln´ı formy. Opom´ıj´ı se ale ˇcasto proto, ˇze pˇredstavuj´ı pomˇernˇe v´ yjimeˇcné situace a je celkem obt´ıˇzné je poruˇsit. Ve ˇctvrté normáln´ı formˇe (4NF) je relace, pokud je v BCNF a vˇsechny v´ıcehodnotové závislost jsou zároveˇ n funkˇcn´ımi závislostmi z kandidátn´ıch kl´ıˇc˚ u. V posledn´ı páté normáln´ı formˇe (5NF) se relace nacház´ı, jeli ve 4NF a nem˚ uˇze-li b´ yt dále bez10


SQL

1 NF Všechnapdatappvprelacipmusípbýtpatomická.

2 NF Datapzávisípnapcelémpklíči.

3 NF Neklíčovápdatapjsoupzávislápjenpnapklíčipapnepmezipsobou.

BCNF Všechnapdatapjsoupzávislápjenpnapklíčipapnepmezipsobou.

4 NF Složenýpprimárnípklíčpnesmípbýtptvořenpzpnezávislýchpdat.

5 NF Trojnýpapvícerýpprimárnípklíčpnesmípobshaovatppárovépcyklicképzávislosti.

Obrázek 3.1: Normáln´ı formy. [Kul08] ztrátovˇe rozloˇzena. [Kal12] [Opp06] [Norm07]

3.4

SQL

SQL (Structured Querry Language, v pˇrekladu strukturovan´ y dotazovac´ı jazyk) je standardizovan´ y dotazovac´ı jazyk. Pouˇz´ıvá se pˇredevˇs´ım pro práci s daty v relaˇcn´ıch databáz´ıch. SQL vznikl z projektu SEQUEL v 70. letech v laboratoˇr´ıch firmy IBM. C´ılem bylo vytvoˇrit standardn´ı metodu pˇr´ıstupu k dat˚ um, která by byla nezávislá na dalˇs´ıch v´ yvojov´ ych nástroj´ıch. Jazyk SQL je neproceduráln´ı. Zadává, jaké informace se vyˇzaduj´ı, nikoliv zp˚ usob, jak je z´ıskat. Tento zp˚ usob vyuˇzit´ı je oznaˇcován jako dynamické SQL. Také se ale m˚ uˇze SQL pouˇz´ıt v aplikaci, která je napsána proceduráln´ım jazykem. Potom se naz´ yvá jako vnoˇrené SQL, které poskytuje pˇr´ıstup k databázi nezávisle na jazyku, ve kterém je napsána zb´ yvaj´ıc´ı ˇca´st aplikace.

11


Hlavn´ı pˇredstavitelé

Obrázek 3.2: Poˇcet nainstalovan´ ych a nasazen´ ych databázov´ ych systém˚ u podle spoleˇcnosti Gartner v roce 2008.[MaS08] Skládá se z nˇekolika skupin. Prvn´ı je jazyk pro definici dat DDL (Data Definition Language), kter´ y urˇcuje strukturu databáze (napˇr. pˇr´ıkazy CREATE, ALTER, DROP). Druh´ ym jazykem je DML (Data Manipulation Language), neboli jazyk pro manipulaci dat, kter´ y slouˇz´ı pro z´ıskáván´ı dat z databáze a jejich aktualizaci. Mezi nˇekteré pˇr´ıkazy DML jazyka patˇr´ı napˇr. SELECT, INSERT, UPDATE a DELETE. Dalˇs´ımi jazyky jsou DCL (Data Control Language), jazyk pro ˇr´ızen´ı dat, kter´ y slouˇz´ı pro správu uˇzivatelsk´ ych rol´ı a práv, a TCL (Transaction Control Language), jazyk pro ˇr´ızen´ı transakc´ı. [Con09][Skˇr00]

3.5

Hlavn´ı pˇ redstavitel´ e

ˇ V souˇcasné dobˇe patˇr´ı k nejv´ıce rozˇs´ıˇren´ ym a nejpropracovanˇejˇs´ım SRBD právˇe relaˇcn´ı databázové systémy (RDBMS). V dalˇs´ı ˇca´sti jsou uvedeny základn´ı informace o nejznámˇejˇs´ıch zástupc´ıch. Na obrázku 3.2 je zobrazen pˇrehled nejpouˇz´ıvanˇejˇs´ıch databázov´ ych systém˚ u. 12



MySQL Databázov´ y systém MySQL1 vlastnˇen´ y spoleˇcnost´ı Oracle Corporation je poskytován pod dvˇema licencemi. Základn´ı verze je pod bezplatnou licenc´ı GPL (General Public License). Komerˇcn´ı verze je poskytována pod placenou licenc´ı a obsahuje rozˇs´ıˇrené funkce a nástroje. D´ıky své multiplatformnosti, vysokému v´ ykonu a n´ızk´ ym finanˇcn´ım náklad˚ um je tento systém ˇcasto vyuˇz´ıván pˇredevˇs´ım na serverech pro potˇreby webov´ ych aplikac´ı. Spoleˇcnˇe s operaˇcn´ım systémem Linux, skriptovac´ım programovac´ım jazykem PHP a webov´ ym serverem Apache tvoˇr´ı tzv. LAMP server. Pro správu MySQL databáz´ı se pouˇz´ıvá open-source nástroj napsan´ y v jazyce PHP, PhpMyAdmin, kter´ y umoˇzn ˇuje kompletn´ı správu systému pomoc´ı webového rozhran´ı. [MyS11]

Microsoft SQL Server Microsoft SQL Server, oznaˇcován jako MSSQL nebo jen SQL Server, je RDBMS vyvinut´ y spoleˇcnost´ı Microsoft. V´ yvoj SQL Serveru zaˇcal ve firmách Microsoft a IBM v roce 1985. Jeˇstˇe nedávno byla k dispozici placená verze a Developer Edition, která byla zdarma pouze pro v´ yvojáˇrské t´ ymy a studenty. Dnes je k dispozici i neplacená verze SQL Server Express. Pro práci s SQL Serverem se nejˇcastˇeji vyuˇz´ıvá SQL Server Management Studio poskytovan´ y od verze MSSQL 2005. Hlavn´ımi jazyky jsou pro SQL Server SQL a T-SQL (Transact-SQL), kter´ y rozˇsiˇruje standardn´ı SQL o proceduráln´ı programován´ı, lokáln´ı promˇenné a dalˇs´ı funkce. Nejnovˇejˇs´ı verz´ı je SQL Server 20142 , kter´ y se jiˇz specializuje na big data a také umoˇzn´ı propojen´ı s cloudov´ ymi sluˇzbami Azure. [MSSQL01]

Oracle Database Spoleˇcnost Oracle Corporation3 patˇr´ı mezi nejvˇetˇs´ı svˇetové v´ yrobce podnikov´ ych systém˚ u, jako jsou relaˇcn´ı databáze, nástroje pro správu databáz´ı a CRM (Customer Relationship Management) systémy. Prvn´ı Oracle databáze oznaˇcena jako Oracle Version 2 vznikla jiˇz v roce 1979, jako prvn´ı relaˇcn´ı databázov´ y systém. Nejnovˇejˇs´ı verze Oracle Database 12c byla prvn´ı databáze urˇcená pro cloud. Pro správu databáze dodává firma zdarma grafick´ y nástroj Oracle SQL Developer, kter´ y umoˇz1

http://www.mysql.com/about/ https://www.microsoft.com/sqlserver/cs/cz/ 3 http://www.oracle.com 2

13



n ˇuje prohl´ıˇzen´ı databáze, spouˇstˇet SQL pˇr´ıkazy, editovat a debugovat PL/SQL pˇr´ıkazy. Spoleˇcnost Oracle vlastn´ı i konkurenˇcn´ı MySQL, kdyˇz v roce 2010 zakoupila spoleˇcnost Sun Microsystems. Spoleˇcnost poskytuje Oracle NoSQL Database, coˇz je NoSQL databáze typu key/value.

PostgreSQL PostgreSQL patˇr´ı mezi objektovˇe-relaˇcn´ı databázové systém, distribuovan´ y zdarma pod licenc´ı PostgreSQL License, která je podobná licenci MIT (svobodná licence z Massachusetts Institute of Technology). Byl vytvoˇren t´ ymem profesora Michaela Stonebrakera na Kalifornské univerzitˇe v Berkeley v roce 19864 . Hlavn´ımi nástroji pro správu databáze jsou psql, aplikace pro pˇr´ıkazovou ˇrádku umoˇzn ˇuj´ıc´ı zadávan´ı SQL dotaz˚ u, a grafické administraˇcn´ı rozhran´ı pgAdmin.

Firebird Databázov´ y systém Firebird vycház´ı ze systému InterBase spoleˇcnosti Borland. V roce 2000 byly uvolnˇeny zdrojové kódy systému InterBase, které zaˇcal ve stejném roce t´ ym v´ yvojáˇr˚ u upravovat, a tak vznikl Firebird, kter´ y je dál vyv´ıjen pod veden´ım neziskové organizace Firebird Foundation. Souˇcasná verze Firebirdu je 2.5.2. D´ıky pˇrepsán´ı do jazyka C++ a velkého mnoˇzstv´ı u ´prav p˚ uvodn´ıho kódu se tento multiplatformn´ı systém stal velmi stabiln´ı. Systém je nab´ızen pod volnou licenc´ı Initial Developer’s Public License vycházej´ıc´ı z MPL (Mozilla Public Licence) pro svobodn´ y software5 . [Jak07]

4 5

http://www.postgresql.org/docs/current/static/history.html http://www.firebirdsql.org/en/licensing/

14

4 NoSQL databáze S nár˚ ustem objemu dat, jejich vzr˚ ustaj´ıc´ı propojenost´ı a ztrátˇe pˇredv´ıdatelné struktury v posledn´ıch letech pˇrestaly b´ yt relaˇcn´ı databázové systémy vhodnou volbou pro nˇekterá data. Google byl prvn´ı spoleˇcnost´ı, která se rozhodla ˇreˇsit problém s ukládán´ım big dat. Vytvoˇril nové databázové uloˇziˇstˇe BigTable, které neukládalo data klasicky po ˇra´dc´ıch ale po sloupc´ıch. Dalˇs´ım ˇreˇsen´ım byl projekt Dynamo od spoleˇcnosti Amazon, kter´ y se zab´ yvá ukládán´ım dat na principu key/value. Oba ˇ projekty stanovily základy pro vznik a v´ yvoj NoSQL databáz´ı. [Sel11]

4.1

Popis

V roce 2009 byl term´ın NoSQL databáze zvolen pro poˇcetnou skupinu nerelaˇcn´ıch datov´ ych uloˇziˇst’. Takové databáze na rozd´ıl od relaˇcn´ıch vˇetˇsinou nepouˇz´ıvaj´ı SQL jako sv˚ uj dotazovac´ı jazyk. Název NoSQL je obˇcas mylnˇe vykládán jako No SQL“ ” (ˇzádné SQL), databázová komunita ale radˇeji vysvˇetluje tento pojem sp´ıˇse jako Not only SQL“ (nejen SQL). Nˇekdy se pro tato datová uloˇziˇstˇe pouˇz´ıvá term´ın ” postrelaˇcn´ı. V ˇsirˇs´ım v´ yznamu se do této skupiny zahrnuj´ı také databáze XML, grafové, dokumentové, objektové a také softwarová ˇreˇsen´ı, která dokonce nejsou ani v tradiˇcn´ım pojet´ı databázemi v˚ ubec. Základn´ımi charakteristikami vˇetˇsiny NoSQL databáz´ı jsou: [Flo12] • Nepouˇz´ıvaj´ı relaˇcn´ı model a jazyk SQL, • vˇetˇsina NoSQL databáz´ı jsou open-source, • jsou navrˇzeny pro práci v clusteru, • umoˇzn ˇuj´ı snadnou podporu replikac´ı a distribuce dat, • poskytuj´ı vlastn´ı jednoduchá API, • nemaj´ı stanovené ˇzádné schéma (nestrukturovaná data), • jsou vysoce horizontálnˇe ˇskálovatelné, • ˇcásteˇcné vyuˇz´ıvaj´ı ACID, • podporuj´ı transakci BASE, 15

NoSQL databáze

Base

• CAP teorém. Data uloˇzená v NoSQL databázi nemusej´ı m´ıt pevné uspoˇrádán´ı, mohou b´ yt strukturovaná, nestrukturovaná nebo semistrukturovaná. V NoSQL se pˇredevˇs´ım vyuˇz´ıvá schopnosti ukládat a naˇc´ıtat velké mnoˇzstv´ı dat bez závislosti na vztaz´ıch. D´ıky tomuto jinému pˇr´ıstupu k ukládán´ı dat do databáze jsou NoSQL v nˇekter´ ych pˇr´ıpadech vhodnˇejˇs´ı neˇz databáze relaˇcn´ı. Pˇr´ıkladem pouˇzit´ı m˚ uˇze b´ yt ukládán´ı nˇekolika milion˚ u dat typu key/value do jednoho asociativn´ıho pole. NoSQL systémy pracuj´ı s distribuovanou architekturou a daty, které jsou redundantn´ım zp˚ usobem uloˇzeny na nˇekolika serverech. V´ yhodou nerelaˇcn´ıch databáz´ı je schopnost tolerovat v´ ypadky s´ıtˇe a vysoká rychlost zpracován´ı obrovského objemu dat, na u ´kor malé funkcionality omezuj´ıc´ı se v nˇekter´ ych pˇr´ıpadech na pouhé ukládán´ı dat. NoSQL databáze neposkytuj´ı plnou podporu ACID. Umoˇzn ˇuj´ı proto pouze ˇca´steˇcnou konzistenci, d´ıky ˇcemuˇz se ale zvyˇsuje rychlost vykonávan´ ych dotaz˚ u, zvˇetˇsuje se dostupnost a moˇznost ˇskálovatelnosti databáze. [Pok12]

4.2

Base

NoSQL databáze povaˇzuj´ı ACID za pˇr´ıliˇs pˇr´ısn´ y. M´ısto toho preferuj´ı radˇeji pˇr´ıstup oznaˇcovan´ y jako BASE (Basically Available, Soft-state, Eventually Consistent), kter´ y upˇrednostˇ nuje dostupnost, ˇcásteˇcnou degradaci a v´ ykon pˇred konzistenc´ı a izoˇ lac´ı databáze. Casto je BASE chápan jako protiklad ACID. BASE se skládá z následuj´ıc´ıch princip˚ u: • Basically Available – pˇri poruˇse spojen´ı mezi uzly z˚ ustane ve vˇetˇsinˇe pˇr´ıpad˚ u dostupnost dat zachována a systém je v podstatˇe funkˇcn´ı po celou dobu. Tato vlastnost se dosahuje pomoc´ı vysoce distribuovaného pˇr´ıstupu ke správˇe databáz´ı. NoSQL databáze maj´ı data uloˇzené v systémech pro ukládán´ı dat s vysok´ ym stupnˇem replikace. • Soft-state – databáze vˇetˇsinou nedodrˇzuj´ı konzistentn´ı poˇzadavky ACID pˇr´ıstupu, neboli aplikace nemus´ı b´ yt v kaˇzdém okamˇziku konzistentn´ı. Základn´ı koncepc´ı je, ˇze konzistence dat je problémem v´ yvojáˇre a nemˇela by b´ yt ˇreˇsena v databázi. • Eventually Consistent – NoSQL databáze mus´ı b´ yt schopny dosahovat konzistentn´ıch dat postupnˇe, neboli v urˇcitém okamˇziku v budoucnosti budou data v konzistentn´ım stavu. Nen´ı vˇsak zaruˇceno, kdy k tomu dojde. To je u ´pln´ y odklon od poˇzadavku pˇr´ıstupu ACID na okamˇzitou konzistenci dat. 16

NoSQL databáze

CAP teorém

V praxi, napˇr. v internetov´ ych aplikac´ıch, se pouˇz´ıvaj´ı oba zm´ınˇené pˇr´ıstupy, ACID a BASE. V pˇr´ıpadech, kdy je nezbytná silná konzistence dat, jako jsou bankovn´ı operace, se pouˇz´ıvá ACID. V jin´ ych pˇr´ıpadech, kde je preferována dostupnost, se pouˇz´ıvá pˇr´ıstup BASE. Pouˇzit´ı pˇr´ıstupu ACID nebo BASE, pˇr´ıpadnˇe kombinace obou, závis´ı pˇredevˇs´ım na konkrétn´ım pˇr´ıstupu. [Cha11][Tiw11]

4.3

CAP teor´ em

V roce 2000 byl profesorem Erikem Brewerem z University of California pˇredstaven CAP teorém (Consistency – C, Availability – A, Partition tolerance – P), kter´ y vysvˇetluje moˇznosti realizace distribuovan´ ych systém˚ u, naz´ yvan´ y také Brewer˚ uv teorém. V posledn´ıch letech si tento princip z´ıskal velikou popularitu i pˇresto, ˇze je nˇekter´ ymi odborn´ıky kritizován. Trojice poˇzadavk˚ u na distribuované prostˇred´ı: • Konzistence (Consistency) znamená, ˇze kdykoliv jsou data zapsána, je pro kohokoliv, kdo ˇcte z databáze, zobrazena posledn´ı verze dat, neboli vˇsechny uzly distribuovaného systému vid´ı ve stejn´ y ˇcasov´ y okamˇzik shodná data. • Dostupnost (Availability) znamená, ˇze kaˇzd´ y klient po svém dotazu dostane informaci o tom, zda byla operace u ´spˇeˇsná nebo ne´ uspˇeˇsná. Také se nˇekdy pouˇz´ıvá i vysvˇetlen´ı, ˇze kaˇzd´ y klient m˚ uˇze ˇc´ıst i zapisovat data. Vysoká dostupnost je dosahována obvykle pomoc´ı vˇetˇs´ıho poˇctu propojen´ ych fyzick´ ych server˚ u p˚ usob´ıc´ı jako jedna databáze s rozdˇelen´ım dat mezi jednotlivé databázové uzly a za pomoci vyuˇzit´ı replik dat. • Odolnost v˚ uˇ ci rozdˇ elen´ı s´ıtˇ e (Partition tolerance) vyjadˇruje schopnost systému ˇc´ıst a zapisovat data i v pˇr´ıpadˇe, pokud doˇslo k pˇreruˇsen´ı spojen´ı mezi v´ yznaˇcn´ ym poˇctem databázov´ ych uzl˚ u. Odolnost m˚ uˇze b´ yt dosaˇzena pomoc´ı mechanism˚ u, kter´ ymi jsou zápisy m´ısto na poˇzadovan´ ych nedosaˇziteln´ ych uzlech poslány stále jeˇstˇe pˇr´ıstupn´ ym uzl˚ um. Kdyˇz se pak navrát´ı nedostupné uzly zpˇet do s´ıtˇe, obdrˇz´ı poˇzadované zápisy, které chybˇely. CAP teorém tvrd´ı, ˇze pro jak´ ykoliv distribuovan´ y systém je nemoˇzné splˇ novat souˇcasnˇe vˇsechny tˇri uvedené poˇzadavky. Z obrázku 4.1 plyne, ˇze systém lze rozdˇelit do následuj´ıc´ıch tˇr´ı kategori´ı: • CA (Consistency + Availability) – je zaruˇcena dostupnost a konzistence na u ´kor odolnosti k rozdˇelen´ı s´ıtˇe. Takové systémy obvykle splˇ nuj´ı zásady ACID a pouˇz´ıvaj´ı se napˇr. v bankách. Pˇredstavitelé: RDBMS. 17

NoSQL databáze

Map Reduce

Obrázek 4.1: CAP teorém. [Ver13] • CP (Consistency + Partition tolerance) – nesplnˇenou vlastnost´ı je dostupnost. Tato volba je vhodná pro systémy, kde dostupnost nen´ı kritická a je d˚ uleˇzité zachvoat pˇredevˇs´ım konzistenci dat. Pˇredstavitelé: Redis, MongoDB, BigTable. • AP (Availability + Partition tolerance) – systém má zaruˇcenou dostupnost a odolnost k rozdˇelen´ı s´ıtˇe, tentokrát na u ´kor konzistence. Tyto systémy jsou oznaˇcovány jako slabˇe konzistentn´ı a konzistence dat dosahuj´ı postupnˇe. Jsou pˇredevˇs´ım vhodné v pˇr´ıpadech, kdy je nepostradatelná odolnost v˚ uˇci rozdˇelen´ı dat. Pˇredstavitelé: Cassandra, Riak, CouchDB. [Pok12]

4.4

Map Reduce

Map Reduce je model urˇcuj´ıc´ı, jak zpracovávat velké objemy dat v clusterech s vyuˇzit´ım paraleln´ıho zpracován´ı na vˇetˇs´ım poˇctu uzl˚ u. Prvn´ı v´ yznamnou realizaci byl The Map Reduce Framework napsán v jazyce C++ od spoleˇcnosti Google. Základn´ı myˇslenky tohoto projektu byly pˇrevzaty softwarem Hadoop a vznikla tak opensource implementace v jazyce Java, jeˇz je v dneˇsn´ı dobˇe hojnˇe vyuˇz´ıvána. Tento 18

NoSQL databáze

Map Reduce

Obrázek 4.2: MapReduce. [Gro09] model pouˇz´ıvá napˇr. MongoDB. Princi Map Reudce, viz obrázek 4.2, vycház´ı z funkcionáln´ıho programován´ı, kde existuje mapovac´ı a redukˇcn´ı funkce. Map funkce uplatn´ı na kaˇzd´ y prvek datové struktury operaci. V´ ystupem je pak nová kolekce hodnot, pˇritom ale nen´ı p˚ uvodn´ı kolekce zmˇenˇena. Funkce Reduce pouˇzije agregaˇcn´ı funkci na novou kolekci hodnot a na v´ ystupu vytvoˇr´ı jednu jedinou hodnotu. Podobn´ y princi se pouˇz´ıvá u zpracován´ı velk´ ych objem˚ u dat v distribuované databázi. [Dea04][Tiw11] • Krok Map – hlavn´ı uzel, kter´ y z´ıskává vstup, rozdˇel´ı vstupn´ı data zadán´ı na ˇca´sti a pˇredá je pracovn´ım uzl˚ um. Pracovn´ı uzel m˚ uˇze opˇet rozdˇelit svoj´ı ˇcást a pˇredat j´ı ke zpracován´ı jin´ ym pracovn´ım uzl˚ um, pro které se tak stane ˇr´ıd´ıc´ım uzlem. Tento zp˚ usob vede k v´ıce´ urovˇ nové stromové struktuˇre. Pracovn´ı uzel pak pouˇzije funkci na kaˇzdou kolekci dvojic kl´ıˇc/hodnota a v´ yslednou kolekci novˇe vytvoˇren´ ych dvojic kl´ıˇc/hodnota pˇredá zpˇet svému nadˇrazenému uzlu. • Krok Reduce – hlavn´ı uzel shromaˇzd’uje v´ ysledky od pracovn´ıch uzl˚ u, které zkombinuje (spoj´ı data se stejn´ ym kl´ıˇcem) a vytvoˇr´ı v´ ystup neboli odpovˇed’ na p˚ uvodn´ı ˇreˇsen´ y problém.

19

NoSQL databáze

4.5

Distribuce dat

Distribuce dat

Data mohou b´ yt um´ıstˇena na jednom uzlu. To je v´ yhodné, protoˇze to nezp˚ usobuje komplikace s rozm´ıstˇen´ım dat na v´ıce uzlech, napˇr. u grafov´ ych databáz´ı, se skoro hotov´ ym grafem, je tˇeˇzké data distribuovat. Jelikoˇz jsou ale moˇznosti jednoho uzlu omezené, je v´ yhodnˇejˇs´ı rozmist’ovat data na v´ıce uzl˚ u. Existuj´ı dvˇe varianty distribuce dat, sharding a replikace. Sharding je metoda, která urˇcuje, na jakém uzlu se nacházej´ı data. Shard je pak oznaˇcen´ı ˇca´sti dat. Kaˇzd´ y shard m˚ uˇze b´ yt um´ıstˇen na odliˇsném databázovém serveru. Jelikoˇz je databáze rozdˇelena a distribuovaná na v´ıce uzlech, je mnoˇzstv´ı dat v kaˇzdé databázi menˇs´ı. Kaˇzd´ y uzel pracuje se svoj´ı ˇcást´ı dat, ˇc´ımˇz umoˇzn ˇuje sn´ıˇzit zat´ıˇzen´ı serveru. D´ıky tomu se sniˇzuje rychlost zpracován´ı jednotliv´ ych dotaz˚ u. Pokud dojde k v´ ypadu jednoho z uzl˚ u, je zbytek dat stále pˇr´ıstupn´ y1 . Nev´ yhodou ale je, ˇze data se mohou pˇri v´ ypadku ztratit. Tuto metodu pouˇz´ıvá napˇr´ıklad Redis nebo MongoDB. Na rozd´ıl od shardingu replikace duplikuje data z jednoho uzlu na ostatn´ı, coˇz znamená, ˇze na kaˇzdém uzlu budou uloˇzena stejná data. D´ıky tomu nedojde pˇri v´ ypadku uzlu ke ztrátˇe dat. Replikace m˚ uˇze b´ yt bud’ master-slave nebo peer-to-peer. Master-slave replikace, jak jiˇz název napov´ıdá, má jeden primárn´ı uzel (master), kter´ y m˚ uˇze ˇc´ıst i zapisovat data. Sekundárn´ı uzly (slaves) mohou pouze ˇc´ıst. Tato replikace je v´ yhodná pˇri vˇetˇs´ım poˇctu dotaz˚ u na ˇcten´ı dat, naopak pˇri vˇetˇs´ım poˇctu poˇzadavk˚ u na zápis ˇci aktualizaci dat má uzel master omezené schopnosti, jelikoˇz jako jedin´ y sm´ı tyto poˇzadavky provádˇet. Dalˇs´ı v´ yhodou master-slave replikace je, ˇze i pˇri v´ ypadku primárn´ıho uzlu, umoˇzn ˇuj´ı sekundárn´ı uzly ˇcten´ı dat. Sekundárn´ı uzel m˚ uˇze b´ yt pak automaticky nebo manuálnˇe pov´ yˇsen na primárn´ı uzel, ˇc´ımˇz pˇrevezme práva mastera. Peer-to-peer (P2P) replikace se od master-slave liˇs´ı pˇredevˇs´ım t´ım, ˇze jsou vˇsechny uzly rovnocenné a kaˇzd´ y uzel má právo pro zápis i ˇcten´ı. T´ım se ˇreˇs´ı nˇekteré nedostatky master-slave replikace pˇredevˇs´ım omezen´ y v´ ykon primárn´ıho uzlu pˇri zápisu. D´ıky tomu je zaruˇcena vˇetˇs´ı spolehlivost, jelikoˇz v´ ypadek jednoho uzlu nezp˚ usob´ı v´ ypadek celého systému. Problémem P2P replikace je konzistence. V pˇr´ıpadˇe zápisu na dvˇe rozd´ılná m´ısta m˚ uˇze vzniknout konflikt. Sharding a replikace se m˚ uˇzou navzájem kombinovat. V pˇr´ıpadˇe master-slave replikace a shardingu bude existovat v´ıce primárn´ıch uzl˚ u, ale kaˇzd´ y záznam bude m´ıt pouze jednoho mastera. D´ıky tomu m˚ uˇze nastat situace, kdy pro jedna data bude uzel primárn´ı, ale pro jiná sekundárn´ı. [Tiw11][Sad13] 1

http://highscalability.com/blog/2010/10/15/troubles-with-sharding-what-can-welearn-from-the-foursquare.html

20

ˇ alovatelnost Sk´

NoSQL databáze

4.6

ˇ alovatelnost Sk´

ˇ alovatelnost je vlastnost systému umoˇzn Sk´ ˇuj´ıc´ı reagovat na náhle zmˇeny potˇreby obˇ alovatelnost m˚ sluhy systému, napˇr. pojmout rostouc´ı poˇcet dat. Sk´ uˇze b´ yt vertikáln´ı (scale up) a horizontáln´ı (scale out). Pˇri vertikáln´ım ˇskálovatelnosti se dosáhne zv´ yˇsen´ı fyzického v´ ykonu serveru pˇridán´ım pamˇeti a zmˇenou procesoru za v´ ykonnˇejˇs´ı. Takové servery b´ yvaj´ı ale drahé. Pˇri horizontáln´ı ˇskálovatelnosti nedocház´ı k vylepˇsován´ı jednoho uzlu, ale m´ısto toho se data rozdˇel´ı na v´ıce vzájemnˇe spolupracuj´ıc´ıch server˚ u. D´ıky tomu m˚ uˇze b´ yt v´ ypoˇcet rozdˇelen na jednotlivé paraleln´ı u ´lohy. Pˇridáván´ı dalˇs´ı jednotky do systému se jev´ı, oproti stálému vylepˇsován´ı technick´ ych parametr˚ u jednoho stroje, finanˇcnˇe v´ yhodnˇejˇs´ı, jelikoˇz postaˇc´ı i levnˇejˇs´ı stroje. Horizontáln´ı ˇskálovatelnost se vyskytuje zejména u NoSQL databáz´ı. V NoSQL mohou b´ yt ale data ˇskálována i vertikálnˇe. [Tiw11][Pok12]

4.7

Dotazov´ an´ı

Jak jiˇz samotn´ y název NoSQL databáze napov´ıdá, tyto systémy postrádaj´ı dotazovac´ı jazyk SQL. Jelikoˇz se NoSQL systémy nezakládaj´ı na relaˇcn´ım modelu a neexistuje v nich ˇza´dn´ y standard pro dotazován´ı, tak se k dat˚ um v r˚ uzn´ ych systémech pˇristupuje rozd´ıln´ ymi zp˚ usoby. Nˇekteré NoSQL databáze podporuj´ı jazyk SQL, pouze vˇsak v omezené formˇe (SimpleDB). Operace agregace, spojen´ı a zanoˇrován´ı dotaz˚ u ˇ nejsou v této omezené formˇe podporovány. Sirˇs´ı podmnoˇzinou SQL jsou jazyky GQL (Google Query Language), pouˇz´ıvan´ y v nástroji Google AppEngine, a HQL (Hypertable Query Language), kter´ y pouˇz´ıvá databáze Hypertable. Dotazován´ı v NoSQL prob´ıhá pˇredevˇs´ım prostˇrednictv´ım kl´ıˇce pomoc´ı jednoduchého API. Obvyklé API pro NoSQL databázi obsahuje následuj´ıc´ı jednoduché operace: • get(kl´ ıˇ c) – z´ıská hodnotu daného kl´ıˇce, • put(kl´ ıˇ c, hodnota) – vytvoˇr´ı nebo aktualizuje hodnotu kl´ıˇce, • delete(kl´ ıˇ c) – odstran´ı kl´ıˇc vˇcetnˇe jeho hodnoty, • execute(kl´ ıc ˇ, operace, parametry) – vyvolá poˇzadovanou operaci na hodnotˇe urˇcené kl´ıˇcem.

21

NoSQL databáze

Datový model

Kv˚ uli horizontáln´ı ˇskálovatelnosti nepodporuj´ı NoSQL databáze operace spojen´ı (JOIN) a uspoˇra´dán´ı (ORDER BY). V pˇr´ıpadˇe, ˇze jsou tyto operace poˇzadovány, mohou b´ yt implementovány na stranˇe klienta, stejnˇe tak, jako ostatn´ı potˇrebné dotazovac´ı moˇznosti. Takovéto ˇreˇsen´ı znamená ruˇcn´ı programován´ı dotaz˚ u, coˇz je vhodné pro jednoduché u ´lohy, ale u komplikovanˇejˇs´ıch u ´loh je to naopak velmi ˇcasovˇe nároˇcné. [Pok12] V budoucnu je pravdˇepodobné, ˇze vznikne pro vˇsechny NoSQL systémy nˇejak´ y standardizovan´ y dotazovac´ı jazyk. Pro dokumentovˇe orientované databáze se zaˇcalo jiˇz hovoˇrit o UnQL (Unstructured Data Query Language)2 od spoleˇcnosti Couchbase. Jeho dalˇs´ı v´ yvoj je vˇsak nejist´ y.

4.8

Datov´ y model

Pˇri klasickém popisu databáz´ı se pouˇz´ıvá (logick´ y) datov´ y model. NoSQL vˇsak vyuˇz´ıvaj´ı jin´ y pˇr´ıstup, intuitivn´ı a bez jak´ ychkoliv pˇredepsan´ ych formáln´ıch základ˚ u. D´ıky tomu je terminologie velice r˚ uznorodá a st´ıraj´ı se zde rozd´ıly mezi konceptuáln´ım a databázov´ ym pohledem na data. Existuje nˇekolik druhu dˇelen´ı NoSQL. Nejˇcastˇeji se pouˇz´ıvá dˇelen´ı do ˇctyˇr kategori´ı, viz obrázek 4.3, podle kvalitativn´ıch parametr˚ u a pˇredevˇs´ım podle jejich datového modelu. • Databáze typu kl´ıˇc/hodnota (Key/value database), • dokumentovˇe orientované databáze (Document-oriented database), • sloupcové databáze (Column oriented database), • grafové databáze (Graph databases). Uvedené dˇelen´ı zobrazuje pouze uˇzˇs´ı koncepci NoSQL databáz´ı. Do ˇsirˇs´ıho pojet´ı lze dále pˇridat i objektové databáze, XML databáze, multidimenzionáln´ı databáze, cloud ˇreˇsen´ı a dalˇs´ı. [Pok12] 2

http://www.couchbase.com/press-releases/unql-query-language

22

NoSQL databáze

Datový model

Obrázek 4.3: Datové modely NoSQL. [Kat12]

4.8.1

Datab´ aze typu kl´ıˇ c/hodnota

Databáze typu kl´ıˇc/hodnota, oznaˇcovány také jako key/value, maj´ı velmi jednoduch´ y datov´ y model. Model lze chápat jako haˇsovac´ı tabulku, která se skládá z textov´ ych dvojic kl´ıˇc a hodnota. Kl´ıˇc jednoznaˇcnˇe identifikuje hodnotu. Hodnota m˚ uˇze obsahovat libovoln´ y blok dat (typicky BLOB) bez potˇreby anal´ yzy obsahu na stranˇe 23

NoSQL databáze

Datový model

databáze. Základn´ı operace, které tyto databáze podporuj´ı, jsou vloˇzen´ı hodnoty pro kl´ıˇc (put), z´ıskán´ı hodnoty podle kl´ıˇce (get) a odstranˇen´ı kl´ıˇce a jeho hodnoty z datového uloˇziˇstˇe (delete). Tento model se hod´ı napˇr´ıklad pro ukládán´ı informac´ı o uˇzivatelsk´ ych profilech. Kaˇzd´ y uˇzivatel má pˇridˇeleno vlastn´ı unikátn´ı user_id, user_name a dalˇs´ı nastaven´ı, jako je jazyk a ˇcasová zóna. Jelikoˇz existuje vˇzdy jedineˇcn´ y kl´ıˇc pro konkrétn´ı objekt, staˇc´ı v databázi vyhledat pouze tento jedineˇcn´ y kl´ıˇc a z´ıskat v´ ysledky. Pokud by ale bylo poˇzadováno dotazovat se podle nˇejakého atributu uloˇzeného v poli hodnota, mus´ı b´ yt zvolen jin´ y datov´ y model. Typ databáze key/value je bez schématu a pouˇz´ıvá se pˇredevˇs´ım pro velk´ y objem nestrukturovan´ ych dat. V´ yhodou takov´ ychto databáz´ı, které jsou podobné souborov´ ym systém˚ um, je pˇredevˇs´ım velk´ y v´ ykon, rychlost, dobrá ˇskálovatelnost a také to, ˇze dvojice kl´ıˇc/hodnota mohou b´ yt r˚ uzn´ ych typ˚ u. Naopak za nev´ yhodu je povaˇzován aˇz pˇr´ıliˇs jednoduch´ y datov´ y model. Mezi nejznámˇejˇs´ı keyvalue databáze patˇr´ı Redis, Riak, Amazon DynamoDB, Oracle NOSQL Database, Memcached a Project Voldemort. Podrobnˇejˇs´ı informace viz kapiotla 4.9 a 4.10. [Pok12]

4.8.2

Dokumentov´ e datab´ aze

Dokumentovˇe orientované databáze jsou rozˇs´ıˇren´ ym datov´ ym modelem key/value. Rozd´ıl je pˇredevˇs´ım v tom, ˇze základn´ım prvkem kaˇzdé dokumentové databáze jsou semistrutkurované dokumenty. Kaˇzd´ y dokument je reprezentován pomoc´ı unikátn´ıho kl´ıˇce, kter´ ym m˚ uˇze b´ yt jednoduch´ y ˇretˇezec. Data mohou b´ yt ukládána ve formátu XML (Extensible Markup Language), JSON (JavaScript Object Notation), BSON (Binary JSON) a v dalˇs´ıch fotmátech. Pro ukládán´ı dokumentu je nutné dodrˇzet zvolen´ y formát, kter´ y databáze podporuj´ı. Intern´ım jazykem je JavaScript. Hlavn´ı v´ yhodou dokumentového modelu je, ˇze jednotlivé dokumenty mohou m´ıt navzájem r˚ uznou strukturu, která nemus´ı b´ yt pˇredem definována. D´ıky tomu m˚ uˇze struktura dokumentu obsahovat velké mnoˇzstv´ı r˚ uzn´ ych informac´ı a také, oproti klasick´ ym relaˇcn´ım databáz´ım, m˚ uˇze mˇenit strukturu dat za bˇehu. JavaScript je v posledn´ı dobˇe hojnˇe vyuˇz´ıvan´ y na webu a proto se tento typ NoSQL databáz´ı stal velmi populárn´ı pˇredevˇs´ım u webov´ ych v´ yvojáˇr˚ u. Mezi nejpouˇz´ıvanˇejˇs´ı dokumentovˇe orientované databáze se ˇrad´ı MongoDB a CouchDB. [Tiw11][Nia13]

24

NoSQL databáze

Datový model

MongoDB MongoDB3 patˇr´ı mezi nejpopulárnˇejˇs´ı dokumentovˇe orientované databáze. Databáze byla vytvoˇrena firmou MongoDB Inc. (dˇr´ıve 10gen). Jedná se o open-source databázi napsanou v jazyce C++, která nemá strukturu (schema-free). MongoDB ukládá data jako dokumenty ve formátu BSON. Maximáln´ı velikost dokumentu je 16 MB. Dokumenty jsou shromaˇzd’ovány do kolekc´ı, které se podobaj´ı tabulkám z relaˇcn´ıch databáz´ı, nemaj´ı vˇsak pevné schéma. Datov´ y model je velmi flexibiln´ı, jakékoliv pol´ıˇcko m˚ uˇze obsahovat v´ıce hodnot a m˚ uˇze v nˇem b´ yt uloˇzena dalˇs´ı datová struktura nebo m˚ uˇze z˚ ustat prázdné. Libovolné pole v dokumentu m˚ uˇze b´ yt indexované, k dispozici je také sekundárn´ı indexován´ı. [Mon14] MongoDB disponuje vlastn´ım dotazovac´ım jazykem, kter´ y je velmi podobn´ y SQL. Podporuje mnoˇzinové operace, regulárn´ı v´ yrazy nebo dokonce dovoluje spustit metodu napsanou v JavaScriptu na stranˇe serveru. Také vyuˇz´ıvá návrhov´ y vzor Map Reduce pro hromadné operace nad daty a sharding pro horizontáln´ı ˇskálován´ı. Umoˇzn ˇuje master-slave replikaci, kde uˇzivatel do masteru zapisuje a ˇcte z nˇej. Slave slouˇz´ı klasicky jen pro ˇcten´ı nebo zálohován´ı zkop´ırovan´ ych dat z primárn´ıho uzlu. Pokud dojde k v´ ypadku uzlu master, systém automaticky zabezpeˇc´ı zvolen´ı nového prim´ıárn´ıho uzlu, kter´ ym se se stane jeden ze sekundárn´ıch uzl˚ u. [Klo12] Vˇsechnu dostupnou pamˇet’ RAM vyuˇz´ıvá MongoDB jako cache pro data, aby nemuselo ustaviˇcnˇe pˇristupovat na disk. Je ale potˇreba sledovat zaplnˇen´ı kapacity disku a pamˇeti RAM. Pokud by byl disk zaplnˇen, tak MongoDB zablokuje vˇsechny operace vˇcetnˇe mazán´ı. V pˇr´ıpadˇe, ˇze se zapln´ı pamˇet’ RAM, zpomal´ı se cel´ y systém na u ´roveˇ n rychlosti disku. [Hof10]

CouchDB Dokumentovˇe orientovaná databáze CouchDB4 je napsaná v jazyce Erlang a vyv´ıjena organizac´ı Apache Software Foundation jako open-source. Patˇr´ı k nejstarˇs´ım dokumentov´ ym databáz´ım, prvn´ı verze vyˇsla jiˇz v roce 2005. Tato databáze je urˇcena pˇredevˇs´ım pro web, také je vhodná pro pouˇzit´ı v mobiln´ıch zaˇr´ızen´ıch pˇredevˇs´ım kv˚ uli sv´ ym replikaˇcn´ım 3 4

https://www.mongodb.org/ http://couchdb.apache.org/

25

NoSQL databáze

Datový model

a synchronizaˇcn´ım schopnostem. Tato databáze b´ yvá nainstalována v mobiln´ıch telefonech a dalˇs´ıch mobiln´ıch zaˇr´ızen´ı tak, ˇze se synchronizuje s centráln´ı databáz´ı kdykoliv je online. Pro dotazován´ı nab´ız´ı pouˇzit´ı REST HTTP API a pro ukládán´ı dat vyuˇz´ıvá formát JSON. CouchDB spravuje obdobnˇe jako MongoDB kolekce JSON dokument˚ u5 . Jednotlivé dokumenty v rámci kolekce nemaj´ı spoleˇcné schéma, pˇriˇcemˇz nab´ızej´ı dotazovac´ı kapacity prostˇrednictv´ım pohled˚ u. Obdobˇe jako v Map Reduce jsou pohledy vymezeny agregaˇcn´ımi funkcemi a souˇcasnˇe s t´ım tˇr´ıdˇeny. Databáze CouchDB podporuje také peer-to-peer replikaci s automatickou detekc´ı konflikt˚ u. Zmˇeny dat jsou pravidelnˇe kop´ırovány mezi servery, ˇc´ımˇz se eliminuje zranitelné m´ısto. V CouchDB je pro ukládán´ı vˇsech dat, dvojic kliˇc/hodnota, pouˇzit B-strom tak, ˇze je podporováno seˇrazen´ı podle kl´ıˇce. [Pok12]

4.8.3

Sloupcov´ e datab´ aze

Sloupcovˇe orientované databáze si ukládaj´ı data po sloupc´ıch nam´ısto klasického pˇr´ıstupu ukládán´ı dat po ˇra´dc´ıch. D´ıky tomu se uchovaj´ı data bez zbyteˇcného zaplnˇen´ı m´ısta na disku, jelikoˇz se pˇri ukládán´ı nevytvoˇr´ı sloupec, pokud pro nˇej neexistuje hodnota. Tento pˇr´ıstup zlepˇsuje v´ ykon pˇredevˇs´ım v datov´ ych centrech a v analytick´ ych systémech, které potˇrebuj´ı velké mnoˇzstv´ı agregovan´ ych dat.

Obrázek 4.4: Datov´ y model v databázi Cassandra. [Mam11] 5

http://wiki.apache.org/couchdb/Introduction

26

NoSQL databáze

Datový model

Datov´ y model sloupcov´ ych NoSQL databáz´ı tvoˇr´ı tˇri základn´ı pojmy. Sloupec (Column) je nejniˇzˇs´ı u ´roveˇ n dat a je tvoˇren trojic´ı, která se skládá ze jména, hodnoty ˇ a ˇcasového raz´ıtka. Casov´ a raz´ıtka modeluj´ı ˇcas a slouˇz´ı k rozliˇsován´ı verz´ı jednotliv´ ych hodnot. Super sloupce (Super column family) nemaj´ı ˇcasové raz´ıtko, obsahuj´ı vˇsak nˇekolik sloupc˚ u (ne vˇsak jin´ y super sloupec) a tvoˇr´ı agregovanou pojmenovanou jednotku. Struktura, která obsahuje neomezené mnoˇzstv´ı ˇra´dk˚ u, se oznaˇcuje jako skupina sloupc˚ u (Column family). Kaˇzd´ y ˇrádek má svoje jméno (kl´ıˇc). Jednotlivé ˇra´dky jsou tvoˇreny sloupci pˇr´ıpadnˇe super sloupci. Skupina sloupc˚ u znázorˇ nuje, jak jsou data uloˇzená na disku. Celá struktura datového modelu pro sloupcovou databázi Cassandra je znázornˇena na obrázku 4.4. V´ yhodou tˇechto databáz´ı je oproti jednoduchému pˇr´ıstupu key/value bohatˇs´ı datov´ y model. Takováto data se ˇrad´ı sp´ıˇse jiˇz do kategorie semistrukturovan´ ych dat. Hlavn´ımi pˇredstaviteli sloupcovˇe orientovan´ ych databáz´ı jsou Cassandra, Google BigTable, HBase a dalˇs´ı. [Pok12][Rah10]

Cassandra V´ yznamn´ ym pˇredstavitelem sloupcovˇe orientovan´ ych NoSQL databáz´ı je vysoce ˇskálovatelná distribuovaná databáze Apache Cassandra6 . Navrˇzená byla v roce 2008 pro sociáln´ı s´ıt’ Facebook. V roce 2009 by tento open-source projekt pˇrevzat spoleˇcnost´ı Apache Software Foundation, která ho stále rozv´ıj´ı. Cassandra je vyuˇz´ıvána spoleˇcnostmi Instagram, Cisco, Ubisoft, Twitter a dalˇs´ımi7 . Apache Cassandra je napsána v programovac´ım jazyce Java a spojuje vlastnosti distribuovaného systému Amazon Dynamo s datov´ ym modelem Google BigTable. Jedná se o multiplatformn´ı databázi, m˚ uˇze b´ yt tak pouˇz´ıvaná jak na platformˇe Windows, tak i na Unix. Cassandra má podobnˇe jako BigTable sloupcovˇe orientovan´ y datov´ y model (Column family). Vyuˇz´ıvá v´ yˇse zm´ınˇen´ y model Map Reduce a d´ıky tomu je dobˇre horizontálnˇe ˇskálovatelná. Od projektu Dynamo pˇreb´ırá symetrickou peer-to-peer architekturu a eventuáln´ı konzistenci. Databáze poskytuje vlastn´ı dotazovac´ı jazyk CQL (Cassandra Query Language), kter´ y je svou syntax´ı podobn´ y jazyku SQL. [Bla10][Dat14][Str11] 6 7

http://cassandra.apache.org/ http://planetcassandra.org/companies/

27

NoSQL databáze

4.8.4

Datový model

Grafov´ e datab´ aze

Pˇredchoz´ı uvedené modely NoSQL databáz´ı se snaˇzily b´ yt bez jakéhokoliv schématu. V tˇechto databáz´ı m˚ uˇzou záznamy naopak m´ıt velké mnoˇzstv´ı vztah˚ u. Grafové databáze jsou vlastnˇe druhem s´ıt’ov´ ych databáz´ı, které si ukládaj´ı data reprezentovaná prostˇrednictv´ım grafu. Vˇetˇsinou se jedná o orientovan´ y a ohodnocen´ y graf, kter´ y je tvoˇren vrcholy (nodes) a hranami (edges). Jednotlivé vrcholy pˇredstavuj´ı objekty a hrany jejich vazby. Do kaˇzdého vrcholu bˇeˇznˇe vstupuje a vystupuje nˇekolik hran. Mohou vˇsak existovat i takové vrcholy, které mezi sebou ˇza´dné vazby nemaj´ı. Hrana mus´ı m´ıt vˇzdy jeden vrchol, ze kterého vystupuje, a dalˇs´ı vrchol, do kterého vstupuje. Vˇetˇsinou jsou data ukládána na vrcholech, ale napˇr. u Neo4j mohou b´ yt data uloˇzena stejn´ ym zp˚ usobem ale na hranách. Na obrázku 4.5 je znázornˇen pˇr´ıklad jednoduchého modelu grafové databáze. Vˇsechny vrcholy obsahuj´ı vlastnosti a mezi kaˇzd´ yma dvˇema vrcholy existuje hrana, která téˇz obsahuje nˇejakou vlastnost. [Pok12]

Id:á100 Značka:ázná Od:á23.á4.á2009

Id:á1 Jméno:áJan Věk:á18

é

Id:á3 Jméno:ácyklistika Typ:áskupina

ne m

v 07 no :á1 le Id a:áč k

a I O čka d:á1 d: :áj 05 á8 e_ .á8 č .á2 len 01 em 1

Zn ačk Id:á1 a:á 06 je_ čle

Zna Id:á10 4 čka :áčl eno vé

Id:á103 Značka:ázná Od:á20.á9.á2010

ač Zn

Zn

Id:á2 Jméno:áEva Věk:á19

Obrázek 4.5: Ukázkov´ y model grafové databáze. [Pok12] Grafové databáze se v souˇcasné dobˇe velmi rychle rozv´ıjej´ı. Pouˇz´ıvaj´ı se pˇredevˇs´ım pro ˇreˇsen´ı u ´loh, jeˇz je velmi obt´ıˇzné spravovat v klasick´ ych relaˇcn´ıch databáz´ıch. 28

NoSQL databáze

Riak

Jejich v´ yhodou je moˇznost pouˇz´ıt grafové algoritmy pro hledán´ı nejkratˇs´ı cesty mezi dvˇema uzly, nalezen´ı minimáln´ı kostry grafu nebo napˇr. Dijkstr˚ uv algoritmus. Tyto databáze nacházej´ı vyuˇzit´ı pˇredevˇs´ım u sociáln´ıch s´ıt´ı, které vyˇzaduj´ı vést záznamy o velkém poˇctu a typu vztah˚ u. V´ yznamn´ ymi pˇredstaviteli grafov´ ych databáz´ı jsou Neo4j, Titan a OrientDB8 .

Neo4j Neo4j9 je velmi populárn´ı robustn´ı databázov´ y systém, kter´ y je velmi ˇskálovateln´ y a vysoce v´ ykonn´ y. Byl vytvoˇren´ y v programovac´ım jazyce Java spoleˇcnost´ı Neo Technology v roce 2007. Na rozd´ıl od ostatn´ıch NoSQL databáz´ı umoˇzn ˇuje transakˇcn´ı zpracován´ı s u ´plnou podporou ACID vlastnost´ı. Zvládne ukládat data i s nˇekolika miliardami uzl˚ u a vztah˚ u, které dokáˇze vysokorychlostnˇe zpracovávat. Databáze Neo4j pouˇz´ıvá vlastn´ı dotazovac´ı jazyk Cypher, kter´ y inspirován jazyky SQL a SPARQL. Cypher je deklarativn´ı jazyk, kter´ y dovoluje popsat, co a jak se má v databázi nalézt. D´ıky podpoˇre vlastn´ıho REST API, které je pouˇz´ıváno pro komunikaci mezi klientem a databázov´ ym serverem pomoc´ı protokolu HTTP, se Neo4j vyuˇz´ıvá v modern´ıch webov´ ych aplikac´ıch. Hod´ı se pro pouˇzit´ı u sociáln´ıch s´ıt´ı, r˚ uzn´ ych wikipedi´ıch a dalˇs´ıch s´ıt’ovˇe orientovan´ ych webov´ ych dat. Obdobnˇe, jako v pˇr´ıpadˇe MongoDB, vyuˇz´ıvá Neo4j replikaci master-slave. Neo4j vyuˇz´ıvaj´ı napˇr´ıklad spoleˇcnosti Adobe, EBay nebo online ˇcasopis CHIP10 . [Hof09]

4.9

Riak

Riak11 je open-source databázov´ y systém, kter´ y vyuˇz´ıvá principy Amazon Dynamo. Tento databázov´ y systém, kter´ y je napsan´ y v jazyce Erlang, byl vytvoˇren firmou Basho Technologies v roce 2009. Slouˇz´ı pˇreváˇznˇe jako distribuované uloˇziˇstˇe typu key/value. Riak je urˇcen pˇredevˇs´ım pro web a webové aplikace a podporuje operaˇcn´ı systémy Linux, BSD, Mac OS X a Solaris. [Cat11] 8

http://db-engines.com/en/ranking/graph+dbms http://www.neo4j.org/ 10 http://www.neotechnology.com/customers/ 11 http://basho.com/ 9

29

NoSQL databáze

Riak

Objekty Riaku, které mohou b´ yt ve formátu JSON, obsahuj´ı unikátn´ı hodnotu s kl´ıˇcem. Dvojice je uloˇzena v tzv. bucketu (do ˇceˇstiny volnˇe pˇreloˇzeno jako kbel´ık). Hodnotami pro jednotlivé kl´ıˇce m˚ uˇze b´ yt cokoliv, od prostého textu, JSON nebo XML po obrázky a video soubory. Bucket je vlastnˇe jmenn´ y prostor pro kl´ıˇce. Má podobnou funkci jako tabulky v relaˇcn´ıch databáz´ı nebo jako adresáˇre ve file systému. Bucket spoleˇcnˇe s kl´ıˇcem vytváˇr´ı unikátn´ı identifikátor pro konkrétn´ı hodnotu. Riak obsahuje kromˇe rozhran´ı pˇr´ımo pro jazyk Erlang také i REST rozhran´ı, které umoˇzn ˇuje podporu knihoven ostatn´ıch jazyk˚ u jako je Java, Python, PHP, .NET a mnoho dalˇs´ıch. Následnˇe je ukázán kód pro vytvoˇren´ı a ˇcten´ı hodnot z bucketu v Riaku pomoc´ı jazyku Erlang. Ukládá se integer 1 do kl´ıˇce pojmenovaného one“. ” %% Creating Objects In Riak %% For these examples we will be using the "test" bucket. MyBucket = <<"test">>. Val1 = 1. Obj1 = riakc_obj:new(MyBucket, <<"one">>, Val1). riakc_pb_socket:put(Pid, Obj1). %% Reading Objects From Riak {ok, Fetched1} = riakc_pb_socket:get(Pid, MyBucket, <<"one">>). Val1 =:= binary_to_term(riakc_obj:get_value(Fetched1)).

Vˇsechny uzly v distribuovaném systému Riak obsahuj´ı kompletn´ı nezávislou kopii dat. Riak automaticky replikuje data pomoc´ı peer-to-peer replikace, defaultnˇe ˇ adn´ je nastaven poˇcet replikac´ı na tˇri. Z´ y uzel nemá vˇetˇs´ı odpovˇednost neˇz jin´ y a ˇza´dn´ y uzel nemá u ´lohy, které by vykonávaly jiné uzly. Kv˚ uli tomu i pˇri v´ ypadku vˇetˇs´ıho poˇctu uzl˚ u je stále moˇzno ˇc´ıst a zapisovat data, ˇc´ımˇz je zajiˇstˇena ˇskálovatelnost a vysoká tolerance proti v´ ypadku uzlu. Pokud je uzel nedostupn´ y, pˇreb´ırá jeho operace sousedn´ı uzel. Pˇri návratu nedostupného uzlu mu jeho soused poˇsle zpˇet aktualizovaná data. Cluster je rozdˇelen pomoc´ı takzvaného Riak ringu, d´ıky ˇcemuˇz bˇeˇz´ı na jednom fyzickém uzlu nˇekolik virtuáln´ıch (vnode). Data jsou distribuována pomoc´ı konzistentn´ı haˇsovac´ı funkce. Funguje to tak, ˇze pokud se provád´ı nˇejaká operace s key/value v Riaku, je následnˇe haˇsováná kombinace bucketu a kl´ıˇce. V´ ysledek haˇsovac´ı funkce je namapován na 160-bitov´ y integrov´ y prostor, kter´ y je rovnomˇernˇe rozdˇelen na ˇcásti. Na obrázku 4.6 je znázornˇen ring pro 4 fyzické uzly, které se dˇel´ı na 32 ˇcást´ı spravovan´ ych 32 virtuáln´ıma uzly. Kaˇzd´ y ze ˇctyˇr fyzick´ ych stroj˚ u má nárok na osm virtuáln´ıch uzl˚ u, t´ım se stroj stává zodpovˇedn´ y za vˇsechny kl´ıˇce, které jsou reprezentovány osmi virtuáln´ımi uzly. Databázov´ y systém Riak má implementovanou schopnost vyuˇz´ıvat jiˇz v´ yˇse zm´ı30

NoSQL databáze

Redis

nˇen´ y model Map Reduce. Definice jednotliv´ ych funkc´ı je systému pˇredávána ve formátu JSON. Pro Map Reduce je moˇzné vyuˇz´ıt indexy, které Riak podporuje. Indexace je zajiˇstˇena pomoc´ı pˇriˇrazen´ı nˇekolika hodnot danému indexovac´ımu kl´ıˇci.

Obrázek 4.6: Riak ring. [Ria11]

Riak se v praxi vyuˇz´ıvá napˇr´ıklad v projektu GitHub nebo v projektech firem Bestbuy a Dell12 . [Ria11][Red12]

4.10

Redis

Redis13 patˇr´ı k nejv´ yznamnˇejˇs´ım NoSQL databáz´ım, ˇrad´ı se do kategorie typu key/value. Byl vytvoˇren v roce 2009 jako soukrom´ y projekt Salvatora Snafilippa. Pozdˇeji byl projekt uvolnˇen jako open-source a pro jeho vysokou popularitu se do jeho v´ yvoje zapojila firma VMWare, od roku 2013 je v´ yhradnˇe sponzorován spoleˇcnost´ı Pivotal14 . Redis je napsán v jazyce C a vyznaˇcuje se vysok´ ym v´ ykonem. Oficiálnˇe je podporován pouze na UNIX platformˇe, ale existuj´ı projekty pro verzi Windows. Nejedná se o klasickou databázi typu key/value, kromˇe jednoduchého ukládán´ı 12

http://basho.com/riak-users/ http://redis.io/ 14 http://redis.io/topics/sponsors 13

31

NoSQL databáze

Redis

ˇretˇezce k danému kl´ıˇc umoˇzn ˇuje ukládat i sloˇzitˇejˇs´ı struktury. Také se odliˇsuje jin´ ym pˇr´ıstupem uchováván´ı dat. Redis si totiˇz veˇskerá svá data drˇz´ı v RAM pamˇeti. D´ıky tomu, ˇze pˇr´ıstup k dat˚ um v pamˇeti b´ yvá ˇrádovˇe rychlejˇs´ı neˇz ˇcten´ı uloˇzen´ ych dat z disku, se stává jednou z nejrychlejˇs´ıch databáz´ı ve svém oboru. Vyuˇz´ıvaj´ı ho spoleˇcnosti jako je Twitter, GitHub, StackOverflow a dalˇs´ı15 . Na sv´ ych domovsk´ ych stránkách poskytuje Redis v´ ybornou dokumentaci. Ta je velmi jednoduchá, pˇrehledná a také kompletn´ı, ˇcasto b´ yvá doplnˇena o komentáˇre uˇzivatel˚ u a interaktivn´ı moˇznost vyzkouˇsen´ı si pˇr´ıkaz˚ u pˇr´ımo na dané stránce. K dispozici je i jednoduch´ y interaktivn´ı tutoriál pˇr´ıkazové ˇra´dky Redisu16 .

Struktura dat Redis podporuje na rozd´ıl od jin´ ych NoSQL databáz´ı typu key/value pˇet datov´ ych typ˚ u. Vˇsechna data jsou uloˇzena do spoleˇcného prostoru a rozliˇsována jsou d´ıky kl´ıˇc˚ um. • String (ˇretˇezec) – jedná se o nejjednoduˇsˇs´ı strukturu, která m˚ uˇze obsahovat jak´ ykoliv druh dat, napˇr. serializovan´ y objekt nebo JPEG. Jeho velikost je omezena na 512 MB. S ˇretˇezci je moˇzné provádˇet základn´ı operace. Redis také umoˇzn ˇuje provádˇet základn´ı matematické operace, jako je zv´ yˇsen´ı ˇci sn´ıˇzen´ı uloˇzené hodnoty pomoc´ı pˇr´ıkaz˚ u INCR, DECR a INCRBY. Pokud jsou tyto pˇr´ıkazy pouˇzity, pak se k ˇretˇezci pˇristupuje jako k ˇc´ıslu, provede se nad n´ım poˇzadovaná operace a opˇet se uloˇz´ı jako ˇretˇezec. • List (seznam) – List v Redisu je jednoduch´ y seznam ˇretˇezc˚ u seˇrazen´ y podle 32 poˇrad´ı vloˇzen´ı. Maximáln´ı velikost seznamu je 2 −1 prvk˚ u. Je moˇzné pˇridávat nov´ y ˇretˇezec na zaˇcátek (LPUSH) nebo konec seznamu (RPUSH). Seznamy dokáˇz´ı pˇristupovat velmi rychle k dat˚ um ze zaˇca´tku ˇci konce seznamu. Naopak, pokud je potˇreba pˇristupovat k prvk˚ um z prostˇredku velmi velkého seznamu, je poté ˇcasová sloˇzitost operace O(N ). • Set (mnoˇzina) – je to neseˇrazená kolekce ˇretˇezc˚ u, do které je moˇzno pˇridávat, odeb´ırat a testovat na existenci ˇcleny s ˇcasovou sloˇzitost´ı O(1). Maximáln´ı poˇcet prvk˚ u je 232 − 1. Mnoˇzina nepodporuje duplicitn´ı ˇcleny, pokud se tedy jeden prvek pˇridá v´ıcekrát, bude mnoˇzina obsahovat stále jen jednu kopii tohoto prvku. Nad mnoˇzinami je moˇzno provádˇet mnoho operac´ı, jako je sjednocen´ı (SUNION), pr˚ unik (SINTER) nebo rozd´ıl (SDIFF). 15 16

http://redis.io/topics/whos-using-redis http://try.redis.io/

32

NoSQL databáze

Redis

• Hash (mapa) – hash je v Redisu mapa a jedná se o nejkomplexnˇejˇs´ı datov´ y typ. Pouˇz´ıvá se pˇredevˇs´ım k ukládán´ı objekt˚ u. Mapa je vlastnˇe kolekce, kde je pod dan´ ym kl´ıˇcem uloˇzena dvojice pole a hodnota. Tento zp˚ usob ukládán´ı objekt˚ u zab´ırá jen velmi malou ˇca´st pamˇeti, proto je dobré pouˇz´ıvat mapy, kdykoliv je to moˇzné. Kaˇzdá mapa je schopna uloˇzit 232 −1 dvojic pol´ı a hodnot. • SortedSet (setˇr´ıdˇená mnoˇzina) – setˇr´ıdˇená mnoˇzina se liˇs´ı od jednoduch´ ych mnoˇzin v tom, ˇze k prvk˚ um se pˇridává jeˇstˇe tzv. skóre. To je ˇc´ıselná hodnota, podle které jsou pak záznamy seˇrazené. D´ıky tomu je moˇzné vyb´ırat napˇr´ıklad mnoˇziny spadaj´ıc´ı do urˇcitého intervalu skóre. Redis podporuje tzv. expiraci kl´ıˇc˚ u u vˇsech podporovan´ ych datov´ ych struktur. Kaˇzdému kl´ıˇci je moˇzné zadat tzv. délku jeho ˇzivota pomoc´ı pˇr´ıkazu EXPIRE a poˇctem ˇ sekund. Po uplynut´ı této doby je kl´ıˇc z databáze automaticky odstranˇen. Zivotnost kl´ıˇce je vrácena pomoc´ı pˇr´ıkazu TTL (time to live). [Red12]

Perzistence dat Databázov´ y systém Redis si udrˇzuje celou databázi v operaˇcn´ı pamˇeti RAM. V pˇr´ıpadˇe v´ ypadku serveru by mohlo ale doj´ıt ke ztrátˇe dat, aby byla ztráta dat co nejmenˇs´ı, ukládá si Redis obraz pamˇeti na pevn´ y disk. Redis podporuje dva druhy 17 ukládán´ı dat, RDB a AOF , které je moˇzné zkombinovat. RDB (Random Database File) funguje tak, ˇze se v urˇcit´ ych intervalech uloˇz´ı aktuáln´ı kopie databáze (snapshot) na disk. Tento zp˚ usob je velmi vhodn´ y pro obnovu dat po havárii a pro klasické zálohován´ı dat. Nehod´ı se vˇsak v pˇr´ıpadˇe, kde je i minimáln´ı ztráta dat od posledn´ıho zálohován´ı nepˇr´ıpustná. Standardnˇe je nastaveno ukládán´ı po 60 vteˇrinách a pˇri 10 000 zmˇenách kl´ıˇc˚ u, nebo po kaˇzd´ ych pˇeti minutách a deseti zmˇenˇen´ ych kl´ıˇc´ıch, pˇr´ıpadnˇe za 15 minut a jedné zmˇenˇe kl´ıˇce. AOF (Append Only File) je bezpeˇcnˇejˇs´ı alternativou pro zálohován´ı dat. Umoˇzn ˇuje zapnout logován´ı vˇsech operac´ı ovlivˇ nuj´ıc´ı data v databázi do logovac´ıho souboru na pevném disku. V pˇr´ıpadˇe, ˇze dojde k obnovˇe dat, jsou vˇsechny pˇr´ıkazy z logu naˇcteny a provedeny. T´ım je databáze obnovena do posledn´ıho známého stavu. Nev´ yhodou AOF je, ˇze logovac´ı soubor b´ yvá ˇcasto vˇetˇs´ı neˇz ekvivalentn´ı RDB soubor. Kv˚ uli tomu b´ yvá obnova dat pomoc´ı AOF v´ yraznˇe pomalejˇs´ı neˇz pˇri obnovˇe dat v RDB. [Red12][Red14] 17

http://redis.io/topics/persistence

33

NoSQL databáze

Redis

Replikace Redis pouˇz´ıvá master-slave replikaci, která byla popsána v kapitole 4.5. Replikace je asynchronn´ı a neblokuj´ıc´ı a je vhodná pro zajiˇstˇen´ı redundance dat a také pro ˇskálovatelnost. D´ıky asynchronn´ı replikaci je moˇzné normálnˇe pracovat s databáz´ı, zat´ımco jsou data synchronizována s jin´ ym uzlem. Sekundárn´ı uzel m˚ uˇze b´ yt hlavn´ım uzlem pro dalˇs´ı uzly a vytváˇr´ı se tak stromová struktura. V pˇredchoz´ıch verz´ıch Redisu bylo umoˇznˇeno zapisovat data i na sekundárn´ı uzly, které se ale pˇri synchronizaci s hlavn´ım uzlem pˇrepsaly. Od verze 2.6 jsou sekundárn´ı uzly defaultnˇe nastaveny pro ˇcten´ı. Replikace se spravuje pˇr´ıkazy SYNC a SLAVEOF pro urˇcen´ı primárn´ıho a sekundárn´ıho uzlu. U sekundárn´ıch uzl˚ u je moˇzné nastavit prioritu, podle které pˇri v´ ypadku hlavn´ıho uzlu vybere Redis Sentinel nov´ y primárn´ı uzel. Redis Sentinel je zat´ım vyv´ıjen´ y systém pro správu nˇekolika bˇeˇz´ıc´ıch instanc´ı Redisu. Pouˇz´ıvá se pro monitorován´ı, notifikaci, automatické pov´ yˇsen´ı sekundárn´ıho uzlu na primárn´ı, pokud je hlavn´ı uzel nedostupn´ y. [Red12][Seg12] V nové beta verzi 3.0.0 poskytuje Redis moˇznost pouˇzit´ı Redis Cluster, kter´ y by poskytoval ˇreˇsen´ı pro automatické shardován´ı dat pˇres nˇekolik Redis uzl˚ u. Pro moˇznost ukládán´ı distribuovan´ ych dat je také moˇznost ˇreˇsen´ı na stranˇe klienta, kter´ y d´ıky svému algoritmu m˚ uˇze rozhodovat o instanci, na kterou budou data uloˇzena. Tˇret´ı moˇznost´ı rozdˇelen´ı dat je Twemproxy vyvinut´ y pro Twitter. Twemproxy je mezivrstva mezi klientem a instanc´ı Redisu . Klient tak nekomunikuje pˇr´ımo s Redisem ale s proxy, která pˇrepos´ılá poˇzadavky pro dan´ y uzel. [Red14]

Syst´ emov´ e rozhran´ı Redis pouˇz´ıvá klasickou architekturu klient-server a komunikuje pomoc´ı protokolu TCP/IP. Standardn´ı instance serveru bˇeˇz´ı na portu 6379. Server tvoˇr´ı vˇzdy jednovláknov´ y proces a klient je v základu reprezentován pˇr´ıkazovou ˇra´dkou Redis-cli. Alternativn´ı klienty lze implementovat pomoc´ı ˇcetn´ ych knihoven, v r˚ uzn´ ych programovac´ıch jazyc´ıch, jejichˇz seznam se nacház´ı na domovsk´ ych stránkách Redisu. K dispozici je i velké mnoˇzstv´ı nástroj˚ u a doplˇ nk˚ u. Stejnˇe jako nˇekteré jiné databáze umoˇzn ˇuje Redis volán´ı vlastn´ıch skript˚ u nad instanc´ı databáze. Skripty mus´ı b´ yt napsány v jazyce Lua. V konfiguraˇcn´ım souboru lze také nastavit poˇcet databáz´ı. Defaultn´ı poˇcet je nastaven na ˇsestnáct. Je vhodné poˇcet databáz´ı zmˇenit pˇred prvn´ım spuˇstˇen´ım serveru a dále ho jiˇz nemˇenit. Pokud se pokus´ı Redis po opˇetovném spuˇstˇen´ı naˇc´ıst data z dump.rdb, kter´ y má data uloˇzena pro jin´ y poˇcet databáz´ı, neˇz má aktuáln´ı instance Redisu, nejsou data korektnˇe

34

NoSQL databáze

Redis

naˇctena. [Red14]

Rozhran´ı pro programov´ an´ı aplikac´ı API neboli rozhran´ı pro programován´ı aplikaci poskytuje Redis pro ˇsirokou ˇskálu programovac´ıch jazyk˚ u18 . Oficiáln´ım klientem pro jazyk C je hiredis, kter´ y podporuje vˇsechny poskytované pˇr´ıkazy. Doporuˇcené knihovny pro jazyk C# jsou knihovna ServiceStack.Redis a novˇe vyvinut´ y StackExchange.Redis, kter´ y nahradil p˚ uvodn´ı projekt BookSleeve. Pro jazyk Java je k dispozici knihovna Jedis a Reddisson. Uvedeny jsou jen hlavn´ı zástupci pro nejpouˇz´ıvanˇejˇs´ı jazyky, na stránkách Redisu je ale mnohem vˇetˇs´ı seznam poskytuj´ıc´ı odkazy na dalˇs´ı projekty a knihovny. Redis podporuje mnoho pˇr´ıkaz˚ u. Vˇsechny jsou uvedeny na domovsk´ ych strán19 kách s podrobn´ ym popisem . Následuje pˇrehled nˇekter´ ych základn´ıch pˇr´ıkaz˚ u, jeˇz jsou souˇca´st´ı vˇetˇsiny poskytovan´ ych API. Pˇr´ıklady jsou psány ve formátu pro pˇr´ıkazovou ˇra´dku Redis-cli. >SET key1 Hello >GET key1

V´ yˇse uveden´ y pˇr´ıklad zobrazuje pˇridán´ı a následné vyhledán´ı ˇretˇezce oznaˇceného kl´ıˇcem key1 s hodnotou Hello. Pokud se provedla operace správnˇe a nevrac´ı ˇzádnou hodnotu, je vypsána hodnota OK. >LRANGE mylist 0 -1

Tento pˇr´ıkaz umoˇzn ˇuje vypsat cel´ y seznam. Podle zadaného intervalu je moˇzné vypsat jen nˇekteré hodnoty seznamu. Do mnoˇziny se nové hodnoty pˇridávaj´ı pˇr´ıkazem SADD. K v´ ypisu obsahu mnoˇziny pak slouˇz´ı pˇr´ıkaz SMEMBERS. Podobn´ ym pˇr´ıkazem je ZADD u seˇrazené mnoˇziny, nutné je vˇsak k nˇemu zadat ˇc´ıselné skóre. Moˇzné je zadávat souˇcasnˇe i v´ıce dvojic skóre hodnota. Následnˇe se seˇrazená mnoˇzina vyp´ıˇse obdobn´ ym pˇr´ıkazem, jako je u seznam˚ u. Pˇr´ıznak WITHSCORES umoˇzn ˇuje vypsat také skóre. >ZADD myzset 1 one 18 19

http://redis.io/clients http://redis.io/commands

35

NoSQL databáze

Redis

>ZADD myzset 2 two 1 uno >ZRANGE myzset 0 -1 WITHSCORES 1) "one" 2) "1" 3) "uno" 4) "1" 5) "two" 6) "2"

Pro vytvoˇren´ı nového hash kl´ıˇce je pouˇz´ıván pˇr´ıkaz HSET, u kterého se mus´ı zadat jméno kl´ıˇce, jméno hash kl´ıˇce a hodnota. Pro v´ ybˇer kl´ıˇce slouˇz´ı pˇr´ıkaz HGET. HGETALL je pro vypsán´ı vˇsech hash kl´ıˇc˚ u a hash hodnot uloˇzen´ ych pod dan´ ym kl´ıˇcem. >HSET user name Karel >HSET user surname Novak >HGETALL user 1) "name" 2) "Karel" 3) "surname" 4) "Novak"

Dále je uvedeno nˇekolik dalˇs´ıch zaj´ımav´ ych a uˇziteˇcn´ ych pˇr´ıkaz˚ u, které Redis podporuje. BGREWRITEAOF Asynchronnˇe pˇrep´ıˇse append-only soubor. CONFIG GET Vrát´ı hodnotu konfigurace podle zadaného parametru. EXPIRE Nastav´ı ˇcas ˇzivota kl´ıˇce ve vteˇrinách. MIGRATE Atomicky pˇresune kl´ıˇc z jedné instance Redisu do druhé. PING Ping serveru. RENAME Pˇrejmenuje kl´ıˇc. RPOPLPUSH Vezme posledn´ı prvek v seznamu, pˇridá ho do jiného a vyp´ıˇse jej. SAVE Synchronnˇe uloˇz´ı data na disk. SHUTDOWN Synchronnˇe uloˇz´ı data na disk a pak se vypne server. TTL Z´ıská zb´ yvaj´ıc ˇcas ˇzivota kl´ıˇce.

36

5 Porovnán´ı NoSQL databáz´ı s relaˇ cn´ımi datab´ azemi Relaˇcn´ı databáze vyuˇz´ıvaj´ıc´ı dotazovac´ı jazyk SQL jsou nejpouˇz´ıvanˇejˇs´ım dneˇsn´ım typem databáz´ı. Proˇsly si dlouh´ ym v´ yvojem a dnes jsou tak na vysoké u ´rovni poskytovan´ ych sluˇzeb a spolehlivosti. Za jejich nejvˇetˇs´ı pˇrednost je povaˇzovaná schopnost snadné transformace objekt˚ u z reálného svˇeta do tabulek a relac´ı. U relaˇcn´ıch databáz´ı je d´ıky transakˇcn´ımu zpracován´ı zajiˇstˇena silná konzistence dat. To se napˇr´ıklad hod´ı pro klasické bankovn´ı systémy, kde je vyˇzadováno dodrˇzen´ı ACID vlastnost´ı. Problém s relaˇcn´ımi databázemi m˚ uˇze nastat, pokud je potˇreba zpracovávat velké mnoˇzstv´ı r˚ uzn´ ych dat, která mohou b´ yt jeˇstˇe distribuovaná. Vzr˚ ustaj´ı tak poˇzaˇ sen´ım pak m˚ davky na v´ ykon, ˇskálovatelnost a flexibilitu. Reˇ uˇze b´ yt sloˇzité ˇr´ızen´ı shardován´ı v aplikaci nebo poˇr´ızen´ı drahého SQL ˇreˇsen´ı, ani jedna z moˇznost´ı nen´ı ideáln´ı. Dalˇs´ım problémem jsou relace mezi v´ıce tabulkami. Pro propojen´ı v´ıce tabulek se pouˇz´ıvá SQL pˇr´ıkaz JOIN. Pokud se tento pˇr´ıkaz pˇr´ıliˇs vyuˇz´ıvá, m˚ uˇze docházet k v´ yraznému sn´ıˇzen´ı rychlosti vykonáván´ı dotazu nad v´ıce tabulkami. V tˇechto pˇr´ıpadech se jev´ı v´ yhodnˇejˇs´ı pˇrej´ıt k NoSQL databáz´ım, které tyto problémy ˇreˇs´ı jednoduˇse a efektivnˇe. [Sto10] NoSQL databáze byly vytvoˇreny na základˇe potˇreby zpracovávat a uchovávat velké mnoˇzstv´ı nestrukturovan´ ych dat, která stále nar˚ ustaj´ı. Jsou vhodné pˇredevˇs´ım v oblastech, kde je velká pracovn´ı zátˇeˇz, ale dotazy na data nejsou nároˇcné. Pˇr´ıkladem pouˇzit´ı mohu b´ yt napˇr´ıklad u ´daje o uˇzivatel´ıch ze sociáln´ı s´ıtˇe, r˚ uzné sociáln´ı grafy atd. Data mohou m´ıt v dneˇsn´ı dobˇe r˚ uznou strukturu, kterou relaˇcn´ı databáze kv˚ uli svému pˇreddefinovanému schématu neum´ı uchovat. Na rozd´ıl od toho NoSQL databáze maj´ı dynamické schéma právˇe pro nestrukturovaná data. D´ıky jinému pˇr´ıstupu jsou NoSQL databáze horizontálnˇe ˇskálovatelné, ˇc´ımˇz umoˇzn ˇuj´ı distribuovat data na v´ıce server˚ u a rozloˇz´ı tak zat´ıˇzen´ı jednotliv´ ych uzl˚ u. Relaˇcn´ı databáze jsou pˇredevˇs´ım vertikálnˇe ˇskálovatelné, a tud´ıˇz u nich nar˚ ustaj´ı poˇzadavky na v´ ykon serveru. Nev´ yhodou NoSQL databáz´ı b´ yvá jejich jednoduch´ y model, nestandardn´ı dotazovac´ı jazyky oproti SQL a také jejich neznalost mezi programátory. Dalˇs´ım negativem nˇekter´ ych NoSQL databáz´ı je to, ˇze nepodporuj´ı integritn´ı omezen´ı a ACID. [Cat11]

37

Porovnán´ı NoSQL databáz´ı s relaˇcn´ımi databázemi

Obrázek 5.1: Ukázka pouˇzit´ı nˇekolika databázov´ ych systém˚ u v jednom projektu. [Sad12]

Jak relaˇcn´ı, tak NoSQL databáze maj´ı v dneˇsn´ı dobˇe svá opodstatnˇen´ı v urˇcit´ ych pˇr´ıpadech pouˇzit´ı. NoSQL nemá za u ´kol nahradit relaˇcn´ı databáze. Je to vlastnˇe jen alternativn´ı ˇreˇsen´ı, které je v nˇekter´ ych pˇr´ıpadech v´ yhodnˇejˇs´ı. U vˇetˇs´ıch aplikac´ı m˚ uˇze ale doj´ıt k tomu, ˇze napˇr. na nˇekterá data je vhodná relaˇcn´ı databáze, na dalˇs´ı data dokumentová NoSQL a na u ´plnˇe jiná data tˇreba key/value databáze. Potom se takov´ yto pˇr´ıstup, kdy se kombinuje v jednom projektu pouˇzit´ı v´ıce databáz´ı, znázornˇen´ y na obrázku 5.1, oznaˇcuje jako polyglot persistence. [Aug11]

38

6 Analýza problému V této ˇcásti diplomové práce se rozeb´ıraj´ı moˇznosti pro tvorbu správce NoSQL da´ tabáze. Ukolem je pro vybranou databázi vytvoˇrit správce, kter´ y bude poskytovat uˇzivatelsky pˇr´ıjemnou práci s uloˇzen´ ymi daty. Zde jsou popsány moˇznosti v´ ybˇeru typu NOSQL databáze a pˇr´ısluˇsného systému. Dále je vˇenována ˇca´st textu porovnán´ı webového nebo desktopového rozhran´ı. Následnˇe je uvedeno nˇekolik existuj´ıc´ıch ˇreˇsen´ı, která jsou v˚ uˇci v´ yslednému programu referenˇcn´ı, a z nich vypl´ yvaj´ıc´ı funkce v´ ysledné aplikace.

6.1

Typ NoSQL datab´ aze

Ve v´ yˇse zm´ınˇené podkapitole 4.10, byly uvedeny ˇctyˇri kategorie NoSQL databáz´ı. Kaˇzdá kategorie má svá vlastn´ı specifika a moˇznosti pouˇzit´ı. Jiˇz na zaˇcátku práce byla pozornost vˇenována pˇredevˇs´ım databáz´ım typu key/value. Grafové a dokumentovˇe orientované databáze jsou v dneˇsn´ı dobˇe totiˇz velmi obl´ıbené a tud´ıˇz existuje i velká ˇrada správc˚ u tˇechto databázov´ ych systém˚ u. Pro grafovou databázi Neo4j existuje napˇr. program Gephi1 nebo Linkurious2 , u MongoDB je to tˇreba program Fluentd3 a mnoho dalˇs´ıch. Zb´ yvaj´ıc´ı dva druhy NoSQL, key/value a sloupcové databáze, jsou si ve své podstatˇe velmi podobné, pouze sloupcové databáze maj´ı o trochu sloˇzitˇejˇs´ı datov´ y model. Pro tvorbu správce byla zvolena NoSQL databáze typu key/value, pˇredevˇs´ım kv˚ uli menˇs´ımu poˇctu kvalitn´ıch správc˚ u, a také kv˚ uli svému jednoduchému modelu, jenˇz plnˇe charakterizuje princip NoSQL databáz´ı.

6.2

Datab´ azov´ y syst´ em pro key/value datab´ azi

Pro databáze typu key/value existuje mnoho databázov´ ych systém˚ u. Mezi dva nejpouˇz´ıvanˇejˇs´ı open-source systémy patˇr´ı jiˇz zm´ınˇen´ y Riak a Redis. Hlavn´ı v´ yhoda Redisu je pˇredevˇs´ım jeho vysoká rychlost, nicménˇe Riak poskytuje zase lepˇs´ı odolnost v˚ uˇci pádu serveru. Oba dva systémy poskytuj´ı na sv´ ych domovsk´ ych stránkách podrobnou dokumentaci. Riak poskytuje oficiáln´ı knihovny jen pro jazyky Erlang, Java, PHP, Python a Ruby. Pˇrednost´ı Redisu je pˇredevˇs´ım, rychlost, podpora r˚ uz1

http://gephi.org/ http://linkurio.us/ 3 http://fluentd.org/ 2

39

Analýza problému

Databázový systém pro key/value databázi

n´ ych struktur dat a velká ˇskála kvalitn´ıch knihoven pro programovac´ı jazyky. Nejvˇetˇs´ı v´ yhoda Redisu je vˇsak podpora velkého mnoˇzstv´ı pˇr´ıkaz˚ u, které ˇcin´ı práci s r˚ uzn´ ymi druhy dat velmi jednoduchou. V tabulce 6.1 jsou znázornˇeny základn´ı vlastnosti Redisu a Riaku. Pro tvorbu správce byl nakonec zvolen systém Redis, kter´ y je pouˇz´ıvanˇejˇs´ı a v´ ykonnˇejˇs´ı neˇz Riak. Jméno

Riak

Redis

Popis

Distribuované, v˚ uˇci chybám odolné key/value uloˇziˇstˇe

In-memory databáze s moˇznost´ı nastaven´ı v´ ykonu oproti perzistenci

Open-source – Apache verze 2

Open-source – BSD

Typ databáze

Key/value

Key/value

API a ostatn´ı pˇr´ıstupové metody

HTTP/REST a nativn´ı Erlang rozhran´ı

Telnet / Proprietárn´ı

P2P

Master-slave replikace

C, C#, C++, Erlang, Java, JavaScript, Lisp, Perl, PHP, Python, Ruby, Smalltalk a dalˇs´ı

C, C#, C++, Erlang, Java, JavaScript, Lisp, Lisp, Lua, Objective-C, Perl, PHP, Python, Ruby, Smalltalk, Tcl a dalˇs´ı

Serverová skriptován´ı

Erlang, JavaScript

Lua

Map Reduce

Ano

Ne

Odoln´ y proti chybám

Velmi rychl´ y

Licence

Replikace Podporované programovac´ı jazyky

Hlavn´ı pˇrednosti

Tabulka 6.1: Srovnán´ı základn´ıch vlastnost´ı sytém˚ u Riak a Redis. [Dbe14]

Jak jiˇz bylo zm´ınˇeno Redis i Riak podporuj´ı mnoho jazyk˚ u. Jazyk Java je multiplatformn´ı, d´ıky tomu lze programy napsané v tomto jazyce spouˇstˇet na libovolném operaˇcn´ım systému, kde bˇeˇz´ı Java Virtual Machine. Jej´ı nev´ yhodou je pomalejˇs´ı start program˚ u a vˇetˇs´ı pamˇet’ová nároˇcnost. Jazyk C# má mnohem lepˇs´ı a modernˇejˇs´ı moˇznosti zobrazen´ı GUI (grafické uˇzivatelské rozhran´ı). Nev´ yhodou jazyka C# je, ˇze 40


Webové vs. desktopové ˇreˇsen´ı

aplikace v nˇem vytvoˇrené jsou spustitelné defaultnˇe pouze na systémech Microsoft Windows. PHP je jazyk pˇredevˇs´ım pro webové ˇreˇsen´ı. Posledn´ım krátce zm´ınˇen´ ym jazykem, kter´ y Redis podporuje, je jazyk C, kter´ y je velmi rozˇs´ıˇren´ y, ale v nˇekter´ ych ohledech je pro tvorbu GUI aplikac´ı zbyteˇcnˇe n´ızko´ urovˇ nov´ y. Ostatn´ı podporované jazyky nejsou moc rozˇs´ıˇrené.

6.3

Webov´ e vs. desktopov´ eˇ reˇ sen´ı

Základn´ı otázkou bylo, jestli bude v´ ysledn´ y program webov´ y nebo desktopov´ y. V dneˇsn´ı dobˇe je populárn´ım ˇreˇsen´ım vytvoˇrit webovou aplikaci, která je poskytovaná z webového serveru pˇres internet. Jej´ı nejvˇetˇs´ı v´ yhodou je pˇredevˇs´ım moˇznost pˇripojen´ı se odkudkoliv prostˇrednictv´ım webového prohl´ıˇzeˇce. S t´ım ale souvis´ı problém, ˇze mus´ı b´ yt k dispozici stálé pˇripojen´ı k internetu. Webové aplikace jsou v pˇr´ıpadˇe tenkého klienta nainstalovány pouze jednou na vzdáleném serveru. V´ ypoˇcetn´ı v´ ykon d´ıky tomu nezatˇeˇzuje poˇc´ıtaˇc uˇzivatele, protoˇze prob´ıhá vzdálenˇe. Pokud dojde k aktualizaci aplikace, nemus´ı se updatovat na kaˇzdém poˇc´ıtaˇci zvláˇst’, jako je tomu v pˇr´ıpadˇe desktopov´ ych aplikac´ı. Webové aplikaci jsou vˇsak ˇcastˇeji vystaveny bezpeˇcnostn´ım rizik˚ um. Mohou také kv˚ uli zv´ yˇsenému provozu reagovat pomaleji neˇz desktopové. V pˇr´ıpadˇe, kdy bude potˇreba napˇr. zobrazit ve webové aplikaci záznamy z NoSQL databáze, která je schopna obsahovat miliony kl´ıˇc˚ u, by mohlo b´ yt naˇc´ıtán´ı stránky pro uˇzivatele aˇz pˇr´ıliˇs zdlouhavé. Také, pokud jde o funkcionalitu, nen´ı webová aplikace schopna dosáhnout moˇznost´ı desktopov´ ych. Pˇr´ıkladem mohou b´ yt rozd´ıly u webov´ ych a desktopov´ ych manaˇzér˚ u pro správu relaˇcn´ıch databáz´ı, kdy desktopová varianta poskytuje vˇetˇs´ı mnoˇzstv´ı nástroj˚ u pro správu, modelován´ı a ˇr´ızen´ı dat. Na rozd´ıl od toho webová aplikace umoˇzn ˇuje klasické funkce, ale je limitována poˇctem a schopnostmi tˇechto funkc´ı. Desktopové aplikace jsou spolehlivé a d˚ uvˇeryhodné. I pˇres mnoho v´ yhod, které poskytuj´ı webové aplikace, jsou stále pouˇz´ıvané pˇredevˇs´ım kv˚ uli jejich uˇzivatelsky pˇr´ıjemnˇejˇs´ımu a intuitivnˇejˇs´ımu rozhran´ı. D´ıky z´ıskan´ ym poznatk˚ um byla zvolena desktopová verze manaˇzéru, která má splˇ novat poˇzadované vlastnosti. V´ ysledn´ y správce by mˇel b´ yt pro NoSQL databáze obdobn´ y jako manaˇzér Oracle SQL Developer, kter´ y poskytuje velkou funkcionalitu a stabilitu a umoˇzn ˇuje rychle zpracovávat zadané u ´koly, pro relaˇcn´ı databáze. Snahou je vytvoˇrit jednoduchou intuitivn´ı aplikaci, která bude pro uˇzivatele pˇr´ıjemnˇe ovladatelná. Jelikoˇz je stále mnoho bˇeˇzn´ ych uˇzivatel˚ u navykl´ ych pouˇz´ıvat klasické desktopové programy, byla vybrána právˇe tato varianta.

41


6.4

Existuj´ıc´ı ˇreˇsen´ı pro Redis

Existuj´ıc´ı ˇ reˇ sen´ı pro Redis

Pro zvolen´ y databázov´ y systém existuje jiˇz nˇekolik jednoduch´ ych desktopov´ ych 4 a webov´ ych manaˇzer˚ u. Mezi nˇe patˇr´ı napˇr. projekt Redsmin , kter´ y je orientovan´ y na v´ yvojáˇre a umoˇzn ˇuje správu sluˇzeb pro Redis. Zpˇr´ıstupnˇen byl na podzim v roce 2013. Je vytvoˇren jako komerˇcn´ı aplikace, kde je moˇznost si zdarma vyzkouˇset verzi s pˇripojen´ım na jeden server. Poskytuje mnoho funkc´ı, napˇr. pomoc´ı grafu zobrazuje poˇcet proveden´ ych operac´ı za dané obdob´ı, také poskytuje moˇznost pouˇz´ıván´ı pˇr´ıkazové ˇrádky Redisu. Jeho hlavn´ı nev´ yhodou je zobrazován´ı kl´ıˇc˚ u a hodnot pomoc´ı GUI, které je obˇcas nepˇrehledné a nut´ı uˇzivatele znát základn´ı pˇr´ıkazy Redisu. Dalˇs´ım zkouman´ ym programem pro Redis byl jednoduch´ y desktopov´ y manaˇzér 5 RedisConsole . V roce 2011 ho vytvoˇril Petr Trofimov, jelikoˇz nemohl naj´ıt ˇza´dn´ y desktopov´ y nástroj pro Windows, kter´ y by umˇel pracovat s Redis databáz´ı. Program je napsán v jazyce C++ a zaloˇzen na QT frameworku. Umoˇzn ˇuje zadat nastaven´ı pro pˇripojen´ı k databázi a veˇskeré operace jsou u nˇej zadávány skrze pˇr´ıkazovou ˇra´dku. Zobrazuje jednoduch´ y seznam kl´ıˇc˚ u a ke kaˇzdému kl´ıˇci umoˇzn ˇuje zobrazit jeho hodnotu, která je pouze text ve formátu JSON. Tento program je ve v´ ysledku pouze vzdálenou pˇr´ıkazovou ˇra´dkou Redisu. Redis Desktop Manager6 je multiplatformn´ı open-source GUI manaˇzér pro Redis vytvoˇren´ y Igorem Malinovskiym na podzim roku 2013. Tento manaˇzer splˇ nuje mnoho funkc´ı, které z nˇeho tvoˇr´ı velmi kvalitn´ı nástroj pro správu Redis databáz´ı. Projekt je stále ve v´ yvoji a jeho posledn´ı verze byla vydána v dubnu 2014. Podporuje správu pˇripojen´ı pomoc´ı SSH protokolu k v´ıce server˚ um. Pˇripojen´ı jsou seˇrazena ve stromˇe, kter´ y dovoluje rozbalen´ı a zobrazen´ı jednotliv´ ych databáz´ı a kl´ıˇc˚ u. V hlavn´ım oknˇe, jsou pak zobrazeny záloˇzky, na kter´ ych jsou hodnoty daného kl´ıˇce a pomoc´ı tlaˇc´ıtek je moˇzno tyto hodnoty pohodlnˇe upravovat. Dalˇs´ım prvkem je Redis konzole, která podporuje vˇetˇsinu pˇr´ıkaz˚ u Redisu. Nˇekteré jednoduché operace jako napˇr. pˇridán´ı nového kl´ıˇce, je moˇzné provádˇet pouze pˇres konzoli. Souˇcasnˇe s obˇcasnou nestabilitou patˇr´ı zp˚ usob pˇridáván´ı nového kl´ıˇce k jednomu z mála nev´ yhod tohoto novˇe vznikaj´ıc´ıho nástroje. 4

https://redsmin.com/ http://ptrofimov.wordpress.com/2011/06/19/redisconsole-windows-gui-tool-toview-redis-databases/ 6 http://redisdesktop.com/ 5

42


6.5

Základn´ı funkce správce

Z´ akladn´ı funkce spr´ avce

Z anal´ yzy existuj´ıc´ıch ˇreˇsen´ı pro systém Redis byly vyvozeny základn´ı funkce, které by mˇel v´ ysledn´ y správce umoˇzn ˇovat. Jak jiˇz bylo v´ yˇse zm´ınˇeno, byla zvolena desktopová varianta s uˇzivatelsky pˇr´ıjemn´ ym GUI, které by mˇelo umoˇzn ˇovat pˇridávat a spravovat nová pˇripojen´ı k databázovému systému. Také by mˇely b´ yt vˇsechny dvojice kl´ıˇc˚ u a hodnot pˇrehlednˇe zobrazeny. Dalˇs´ı vlastnost´ı, která by mˇela b´ yt urˇcitˇe podporována, je pˇridáván´ı, mazán´ı a editace poˇzadovaného kl´ıˇce a hodnoty. S t´ım samozˇrejmˇe souvis´ı podpora vˇsech pˇeti datov´ ych struktur, které Redis nab´ız´ı. Vˇsechny zm´ınˇené operace by mˇely b´ yt pˇr´ıstupné i uˇzivateli, kter´ y nezná základn´ı pˇr´ıkazy Redisu. Poˇzadovanou funkc´ı na program, byla moˇznost exportovat a importovat data z databáze do formátu JSON. Uvedené funkce jsou pouze základn´ımi poˇzadavky z´ıskan´ ymi z anal´ yzy databázového systému a jeho manaˇzér˚ u.

43

7 Realizace správce databáze V rámci této diplomové práce bylo navrˇzeno a realizováno ˇreˇsen´ı správce NoSQL databáz´ı typu key/value pro databázov´ y systém Redis, které se naz´ yvá NoSqlManager. V následuj´ıc´ım textu je popsán jeho návrh a ˇreˇsen´ı.

7.1

N´ avrh spr´ avce datab´ aze

Pro správce byl zvolen pouze jedin´ y databázov´ y systém, a to Redis, pˇredevˇs´ım kv˚ uli neuniverzálnosti pˇr´ıkaz˚ u, které pouˇz´ıvaj´ı NoSQL databáze. Na rozd´ıl od relaˇcn´ıch databáz´ı, které vyuˇz´ıvaj´ı jednotn´ y jazyk SQL, u NoSQL zat´ım neexistuje standardizovan´ y pˇr´ıstup. Jak jiˇz bylo zm´ınˇeno v anal´ yze, podkapitola 6.5, vytvoˇren´ y program bude poskytovat základn´ı funkce. Tˇemi jsou pˇridáván´ı nového kl´ıˇce a hodnoty pro vˇsechny struktury dat, editace hodnot kl´ıˇc˚ u a také odstranˇen´ı poˇzadovaného kl´ıˇce. Dalˇs´ı vlastnost´ı, kterou aplikace umoˇzn ˇuje, je vytvoˇren´ı nového pˇripojen´ı, podle zadané IP adresy, jména serveru, portu, na kterém databáze bˇeˇz´ı, a hesla, které slouˇz´ı k pˇripojen´ı zabezpeˇcené databáze. Vˇsechny u ´daje o pˇripojen´ı jsou uloˇzeny, aby mohly b´ yt pˇri dalˇs´ım pouˇzit´ı programu znovu naˇcteny. Program také umoˇzn ˇuje zobrazit podrobné informace o serveru, jako je napˇr. verze Redisu, poˇcet pˇripojen´ ych klient˚ u nebo vyuˇzit´ı pamˇeti. V pr˚ ubˇehu realizace byla dodána jeˇstˇe konzole, která umoˇzn ˇuje vyuˇz´ıvat veˇskeré pˇr´ıkazy Redis-cli. Konzole v´ yraznˇe rozˇsiˇruje moˇznosti pouˇzit´ı správce a poskytuje znalému uˇzivateli moˇznost plnˇe vyuˇz´ıvat funkcionalitu Redisu.

7.1.1

Programovac´ı jazyk

K napsán´ı programu byl zvolen vysoko´ urovˇ nov´ y objektovˇe orientovan´ y jazyk C#, kter´ y byl vytvoˇren firmou Microsoft spoleˇcnˇe s platformou .NET. Na rozd´ıl do Javy je C# rychlejˇs´ı a nezab´ırá tolik operaˇcn´ı pamˇeti. Hlavn´ı motivac´ı pro zvolen´ı jazyka C# bylo zejména prohlouben´ı znalost´ı v tomto jazyce a v pouˇz´ıván´ı v´ yvojového prostˇred´ı Visual Studio. Pro tvorbu byly pouˇzity nové technologie, jako je napˇr. WPF (Windows Presentation Foundation) se znaˇckovac´ım jazykem XAML (Extensible Application Markup Language) umoˇzn ˇuj´ıc´ı data binding.

44

Realizace správce databáze

7.1.2

Návrh správce databáze

Rozvrˇ zen´ı programu

Aplikace je vytvoˇrena podle návrhového vzoru MVVM (Model View ViewModel) ˇ pro WPF aplikace. MVVM oddˇeluje data, stav aplikace a uˇzivatelské rozhran´ı. Reˇsen´ı MVVM umoˇzn ˇuje, aby proces bˇeˇz´ıc´ı na pozad´ı nebyl závisl´ y na oknˇe, které konzumuje informace tohoto procesu. Vrstva Model popisuje jednotlivá data, se kter´ ymi aplikace pracuje. View reprezentuje uˇzivatelské rozhran´ı napsané v jazyce XAML. ViewModel spojuje vrstvy Model a View pomoc´ı bindingu. Provád´ı se v nˇem filtrován´ı dat podle stavu aplikace, a proto mus´ı b´ yt implementováno rozhran´ı INotifyPropertyChanged. Struktura projektu je rozdˇelena do ˇctyˇr sloˇzek, Helpers, Images, Model a View. View obsahuje jeˇstˇe jednu vloˇzenou sloˇzku pojmenovanou Partial. Podle vzoru MVVM jsou zde uloˇzeny XAML a jejich code-behind (kód na pozad´ı) v pˇr´ısluˇsn´ ych CS (zdrojové soubory pro C#) souborech. N´ıˇze je struˇcnˇe popsána charakteristika vˇsech soubor˚ u v projektu NoSqlManager. Ve sloˇzce Images jsou obrázky pouˇz´ıvané u kontrolek v GUI. Soubory um´ıstˇené ve View jsou následuj´ıc´ı: • AddWindow – slouˇz´ı pro pˇridán´ı nov´ ych dat do databáze. • ConnectWindow – poskytuje moˇznost vytvoˇren´ı nového pˇripojen´ı k serveru. • ConsoleWindow – tˇr´ıda reprezentuj´ıc´ı okno a funkce konzole. • EditConnectWindow – upravuje nastaven´ı pˇripojen´ı k serveru. • EditValuesWindow – umoˇzn ˇuje upravovat hodnoty kl´ıˇc˚ u r´ uzn´ ych struktur dat Redisu. • EditWindow – poskytuje náhled na data, která mohou b´ yt dále editována. • InfoWindow – zobrazuje informace z´ıskané od serveru, na kterém bˇeˇz´ı Redis. • MainWindow – hlavn´ı okno aplikace, které poskytuje pˇrehledné zobrazen´ı poˇzadovan´ ych prvk˚ u a základn´ı logiku aplikace. Ve sloˇzce Partial jsou um´ıstˇené XAML soubory, které se vkládaj´ı do jin´ ych oken. DatabaseGrid slouˇz´ı pro zobrazen´ı dat z databáze v tabulce, která je um´ıstˇena v záloˇzce na hlavn´ım oknˇe. TabCloseButton reprezentuje tlaˇc´ıtko na záloˇzce, které umoˇzn´ı jej´ı zavˇren´ı. Model obsahuje objekty, které zastupuj´ı data, se kter´ ymi aplikace operuje. Dále je uveden jejich pˇrehled. 45



• CloseableTabItem – je tˇr´ıda, reprezentuj´ıc´ı záloˇzku, kterou je moˇzné zav´ırat pomoc´ı tlaˇc´ıtka popsaného v TabCloseButton.xaml. • DatabaseNode – reprezentuje databázi pˇr´ısluˇsného serveru a jej´ı obsah. • DatabaseRow – zastupuje cel´ y ˇrádek z databáze. Obsahuje, o jak´ y typ dat se jedná, kl´ıˇc a hodnoty. • ITreeViewItem – interaface pro stromovou strukturu, zobrazuj´ıc´ı servery a databáze. • IValue – interface pro typ, kl´ıˇc a hodnotu. • ServerNode – pˇredstavuje server, jeho nastaven´ı a pˇr´ısluˇsné potomky, které jsou zastoupeny jako DatabaseNode. Také se zde udrˇzuje informace o roli (slave nebo master) serveru. Helpers je sloˇzka, která v sobˇe obsahuje r˚ uzné tˇr´ıdy potˇrebné pro ˇreˇsen´ı nˇekter´ ych u ´kol˚ u. • InverseBooleanConverter – slouˇz´ı pro inverzi Boolean hodnoty. • RedisBackgroundWorker – patˇr´ı k nejd˚ uleˇzitˇejˇs´ım tˇr´ıdám, obsahuje logiku práce na pozad´ı pˇri dotazován´ı na server. • SerializeHelper – slouˇz´ı k uloˇzen´ı seznamu pˇripojen´ı do config.xml souboru. • TypeTemplateSelector – pomáhá urˇcovat strukturu v´ ypisu v tabulce pro r˚ uzné typy dat. • VisibilityToNullableBooleanConverter – converter pro inverzi viditelnosti kontrolek. V pˇr´ıloze B je zobrazen graf závislost´ı jednotliv´ ych jmenn´ ych prostoru znázorˇ nuj´ıc´ı v´ yˇse popsané tˇr´ıdy a vztahy mezi nimi. Diagram byl vygenerován pomoc´ı Visual Studia.

7.1.3

GUI

Rozloˇzen´ı jednotliv´ ych ˇca´sti GUI bylo navrˇzeno tak, aby byla uˇzivateli poskytnuta pohodlná a intuitivn´ı práce s manaˇzerem. Inspirac´ı pro um´ıstˇen´ı nˇekter´ ych prvk˚ u 46



rozhran´ı byly existuj´ıc´ı nástroje, popsané v podkapitole 6.4. Na obrázku 7.1 je znázornˇené v´ ysledné grafické rozhran´ı vytvoˇrené aplikace.

Obrázek 7.1: Hlavn´ı okno programu NoSqlManager.

Program se skládá z hlavn´ıho okna, které je rozdˇeleno na dvˇe základn´ı ˇca´sti. V levé ˇcásti je stromová struktura, ve které jsou zobrazeny jednotlivé servery se sv´ ymi databázemi. Druhá ˇca´st hlavn´ıho okna zobrazuje tabulku s dvojicemi kl´ıˇc a hodnota, které jsou abecednˇe seˇrazené, pro zvolenou databázi. Pro moˇznost jednoduchého pˇrep´ınán´ı mezi databázemi a porovnáván´ı obsahu, jsou pouˇzity záloˇzky. Kaˇzdá záloˇzka obsahuje pouze data z jedné databáze. Na záloˇzce jsou pak um´ıstˇena tlaˇc´ıtka pro pˇridán´ı, smazán´ı a editaci kl´ıˇce, dále také pro aktualizaci dat a pro import/export dat do/z JSON souboru. Tlaˇc´ıtka jsou um´ıstˇena v horn´ı ˇcásti záloˇzky, simuluj´ı tak nástrojovou liˇstu. Pod tlaˇc´ıtky je pak zobrazena tabulka, která je rozdˇelena na tˇri sloupce, kl´ıˇc, hodnotu a typ kl´ıˇce. V kaˇzdém ˇrádku je znázornˇen náhled na hodnoty dat, a jelikoˇz Redis podporuje pˇet r˚ uzn´ ych datov´ ych struktur, je moˇzno po rozkliknuti pˇr´ısluˇsného kl´ıˇce zobrazit podrobnˇejˇs´ı strukturu jeho hodnot, napˇr. u mapy je po kliknut´ı zobrazena dalˇs´ı tabulka s hashkey a hodnotami. V horn´ı ˇca´sti hlavn´ıho okna je um´ıstˇena liˇsta, která pod nab´ıdkou File posky47



tuje moˇznost Add New Connection. Pomoc´ı nab´ıdky se tak otevˇre okno pro pˇridán´ı nového pˇripojen´ı. Nad názvy jednotliv´ ych server˚ u ve stromové struktuˇre je moˇzno prav´ ym tlaˇc´ıtkem vyvolat kontextové menu, které nab´ız´ı otevˇren´ı konzole nad dan´ ym serverem, editaci nastaven´ı serveru, zobrazen´ı základn´ıch informac´ı o serveru, aktualizaci stavu serveru a také smazán´ı nastaven´ı serveru.

Obrázek 7.2: Konzole programu NoSqlManager.

Zvláˇstn´ım oknem je konzole, zobrazena na obrázku 7.2, která zpˇr´ıstupˇ nuje uˇzivateli pˇr´ıkazovou ˇrádku Redis-cli. Skládá se ze dvou ˇca´st´ı, prvn´ı zobrazuje napsané pˇr´ıkazy a odpovˇed’ serveru. Spodn´ı ˇca´st reprezentuje pole, do kterého se zadávaj´ı pˇr´ıkazy. Pro pˇrehlednost bylo pˇridáno tlaˇc´ıtko Send k odeslán´ı pˇr´ıkazu. Pro poslán´ı pˇr´ıkazu také staˇc´ı stisknout klávesu Enter. Uzavˇren´ı okna lze provést pˇr´ıkazem exit. Ostatn´ı okna aplikace, která se otevˇrou po zvolen´ı jednotliv´ ych nab´ıdek nebo po kliknut´ı na tlaˇc´ıtko, a funkce programu jsou bl´ıˇze popsány v uˇzivatelské pˇr´ıruˇcce, která je souˇca´st´ı pˇr´ılohy.

48


7.2

Vývojové nástroje

V´ yvojov´ e n´ astroje

Pro tvorbu programu bylo zvoleno v´ yvojové prostˇred´ı Microsoft Visual Studio Ultimate 2013 s .NET Frameworkem 4.5.1., které je distribuováno spoleˇcnˇe s jazykem C#. Verze Redisu, pro kterou se program vyv´ıjel, je 2.8.2. Ke správˇe projektu byl pouˇzit Team Foundation Server (TFS) od spoleˇcnosti Microsoft, kter´ y umoˇzn ˇuje spravovat zdrojové kódy, podporuje verzován´ı a mnoho dalˇs´ıch funkc´ı. TFS byl nasazen na extern´ım serveru pˇredevˇs´ım pro potˇreby zálohován´ı projektu. Dalˇs´ı v´ yhodou takovéhoto pˇr´ıstupu je moˇznost pˇri v´ yvoji porovnat jednotlivé verze kódu mezi sebou. Pro kaˇzd´ y commit proveden´ y na server je pˇridán krátk´ y popis proveden´ ych zmˇen. V projektu jsou pouˇz´ıvané r˚ uzné knihovny. Pro umoˇznˇen´ı exportován´ı a importován´ı dat do JSON soubor˚ u byla pouˇzita knihovna Json.net. Knihovna Extended WPF Toolkit byla pouˇzita pouze pro jedinou kontrolku IntegerUpDown. Ta se pouˇz´ıvá v oknˇe pro pˇridán´ı nového pˇripojen´ı u nastaven´ı ˇc´ısla portu. Pro API k Redisu je pouˇzitá knihovna ServiceStack.Redis1 . Druhá knihovna, která byla uvaˇzována, byla BookSleeve2 . Jej´ı hlavn´ı nev´ yhodou byla témˇeˇr neexistuj´ıc´ı dokumentace. Na jaˇre 2014 byla nahrazena knihovnou StackExchange.Redis3 , která jiˇz poskytuje základn´ı dokumentaci. Zvolená knihovna ServiceStack.Redis poskytuje velmi dobrou dokumentaci a jej´ı dalˇs´ı pˇrednost´ı je obl´ıbenost u komunity, která poskytuje mnoho rad v této oblasti. ServiceStack.Redis je nab´ızena pod licenc´ı GNU Affero General Public License, verze 34 . P˚ uvodnˇe byla v projektu zahrnuta pomoc´ı NuGetu (open-source bal´ıˇckovac´ı systém pro platformu .NET). Pˇri v´ yvoji konzole bylo vˇsak potˇreba upravit zdrojov´ y kód knihovny a zpˇr´ıstupnit tak nˇekteré metody. Proto bylo nutné do projektu knihovnu pˇridat jako dalˇs´ı projekt. S n´ı byly pˇridány i dalˇs´ı potˇrebné knihovny od ServiceStack5 . Tˇemi jsou ServiceStack.Text, ServiceStack.Common a ServiceStack.Interfaces. 1

https://github.com/ServiceStack/ServiceStack.Redis https://code.google.com/p/booksleeve/ 3 https://github.com/StackExchange/StackExchange.Redis 4 http://www.gnu.org/licenses/agpl-3.0.html 5 https://github.com/ServiceStack 2

49


7.3

Pˇripojen´ı k databázi

Pˇ ripojen´ı k datab´ azi

Vytvoˇren´ y správce NoSqlManager umoˇzn ˇuje pˇripojit se k serveru s bˇeˇz´ıc´ım systémem Redis pomoc´ı knihovny ServiceStack.Redis. Nejprve se vytvoˇr´ı objekt RedisClient, jehoˇz vstupn´ı parametry konstruktoru jsou Host – adresa serveru, Port – ˇc´ıslo portu, na kterém bˇeˇz´ı Redis, a Auth – heslo, které se pouˇz´ıvá, pokud je instance Redisu zabezpeˇcena. Pro jednoduˇsˇs´ı práci s objektem je pouˇzité kl´ıˇcové slovo using, které se pouˇz´ıvá pro korektn´ı uvolˇ nován´ı zdroj˚ u. 1 2 3 4

using (var redisClient = new RedisClient(Host, Port, Auth)) { var info = redisClient.Info; }

Pokud se provede dotazován´ı na server, které m˚ uˇze trvat urˇcit´ y ˇcas, mohlo se stát, ˇze by aplikace tzv. zamrzla a uˇzivatel by se poté mylnˇe domn´ıval, ˇze program nefunguje. Pro tento pˇr´ıpad je oˇsetˇrena veˇskerá komunikace s databáz´ı pomoc´ı vláken. Pˇri jakémkoliv dotazován´ı na databázi se vytvoˇr´ı nové vlákno, které obsluhuje pˇr´ısluˇsn´ y dotaz, neboli pracuje na pozad´ı. Mezit´ım hlavn´ı vlákno aplikace stále umoˇzn ˇuje vyuˇz´ıvat aplikaci, i kdyˇz jen v omezené m´ıˇre, napˇr. nˇekterá tlaˇc´ıtka jsou v pr˚ ubˇehu práce vedlejˇs´ıho vlákna nedostupná. 1 2 3 4 5 6 7 8 9 10 11 12

RedisBackgroundWorker.BackgroundAction = delegate { using (var redisClient = new RedisClient(Host, Port, Auth)) { var info = redisClient.Info; } }; RedisBackgroundWorker.OnActionFail = ...; RedisBackgroundWorker.OnActionComplete = ...; RedisBackgroundWorker.Start("Information about server " + server.Name + " ...");

K obsluze práce na pozad´ı slouˇz´ı tˇr´ıda RedisBackgroundWorker, která ve svém konstruktoru nastavuje informativn´ı hláˇsku zobrazenou v doln´ı liˇstˇe hlavn´ıho okna. Pro spuˇstˇen´ı nového vlákna je zde metoda Start, která se provede, jestliˇze jiˇz nebˇeˇz´ı jiná práce na pozad´ı. Obˇe dvˇe vlákna pak bˇeˇz´ı asynchronnˇe. Jelikoˇz nen´ı ve v´ıcevláknov´ ych aplikac´ı povoleno zavolat metodu pro ovládac´ı prvek jin´ ym vláknem neˇz t´ım, které prvek vytvoˇrilo, je nutné pouˇz´ıt metodu Dispat50



cher.Invoke. Pomoc´ı n´ı se m˚ uˇze pˇresmˇerovat volán´ı metody z pracovn´ıho vlákna na hlavn´ı. BackgroundWorker je pomocná tˇr´ıda, která obaluje pracovn´ı vlákno a automaticky volá podle potˇreby Dispatcher.Invoke. Aby se mohl pouˇz´ıt BackgroundWorker, bylo nutné vytvoˇrit handler pro událost DoWork a zavolat metodu RunWorkerAsync, která spust´ı instanci BackgroundWorkeru. Událost RunWorkerCompleted, která je také souˇcást´ı BackgroundWorkeru, se provede, kdyˇz DoWork dokonˇc´ı svoj´ı práci. Pokud dojde bˇehem vykonáván´ı DoWork k chybˇe, napˇr. server, na kter´ y je dotazováno, je nedostupn´ y, je oˇsetˇrena v´ yjimka a uˇzivatelovi je zobrazeno chybové okno s hláˇskou, kterou vrac´ı pˇr´ımo systém. Následnˇe je v´ yjimka pˇredána zpˇet volaj´ıc´ımu vláknu. D´ıky tomu je zajiˇstˇeno jej´ı snadnˇejˇs´ı oˇsetˇren´ı. Chybová hláˇska je prezentována v jazyce systému, ve kterém je program spouˇstˇen. 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31

public void Start(string statusMessage) { if (!_backgroundWorker.IsBusy) { _backgroundWorker = new BackgroundWorker(); MainWindow.Status = statusMessage; _backgroundWorker.DoWork += delegate { try { BackgroundAction.Invoke(); } catch (Exception e) { MainWindow.Dispatcher.Invoke(delegate { ... MessageBox.Show(e.GetBaseException().Message, "Error", MessageBoxButton.OK, MessageBoxImage.Error); }); } }; _backgroundWorker.RunWorkerCompleted += delegate { MainWindow.IsWorkOnBackground = false; MainWindow.Status = DefaultStatus; OnActionFail = null; if (OnActionComplete != null)

51


32 33 34 35 36 37 38 39 40 41 42


{ OnActionComplete.Invoke(); } OnActionComplete = null; }; MainWindow.IsWorkOnBackground = true; _backgroundWorker.RunWorkerAsync(); } else{...} }

Také je moˇzno zadat dalˇs´ı chován´ı aplikace pˇri vyvolán´ı v´ yjimky pomoc´ı akce OnActionFail, která napˇr. pˇri ne´ uspˇeˇsném pˇripojen´ı k databázi nastav´ı roli serveru jako nepˇripojen´ y a zavˇre záloˇzky, které náleˇz´ı nedostupnému serveru. Obdobnˇe je po u ´spˇeˇsném ukonˇcen´ı práce vlákna moˇznost zavolat akci OnActionComplete, která provede dalˇs´ı ˇcinnost, jako je tˇreba aktualizace dat v databázi. 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17

RedisBackgroundWorker.OnActionFail = delegate { Role = RoleNotConnected; var tabs = Children.Select(child => RedisBackgroundWorker.MainWindow.TabList .FirstOrDefault(m => m.HeaderText == Name + ":" + child. Name)) .Where(tab => tab != null); foreach (var tab in tabs) { RedisBackgroundWorker.MainWindow.TabList.Remove(tab); } Children.Clear(); };

RedisBackgroundWorker.OnActionComplete = dbNode.Refresh;

V´ yˇse popsan´ y zp˚ usob umoˇzn ˇuje hlavn´ımu vláknu stále komunikovat s uˇzivatelem. Nedocház´ı tak k zbyteˇcnému zamrznut´ı aplikace, jeˇz m˚ uˇze b´ yt pro uˇzivatele nepˇr´ıjemné.

52


7.4

Konzole

Konzole

Pro poskytnut´ı kompletn´ı funkˇcnosti správce byla do projektu bˇehem v´ yvoje pˇridána konzole. Konzole podporuje veˇskeré pˇr´ıkazy Redisu, napˇr. vypnut´ı serveru s databáz´ı pˇr´ıkazem SHUTDOWN, proto je lepˇs´ı, kdyˇz j´ı pouˇz´ıvá jen zkuˇsen´ y uˇzivatel. Jedná se o velmi uˇziteˇcn´ y nástroj, d´ıky kterému se m˚ uˇze NoSqlManager ˇradit mezi nej´ uˇcinnˇejˇs´ı správce pro systém Redis. Konzole je tvoˇrena ConsoleWindow.xaml a jej´ım code-behindem. Vstupn´ım parametrem konstruktoru je objekt ServerNode urˇcuj´ıc´ı server, nad kter´ ym byla konzole zavolána. Popsán´ı logiky z´ıskáván´ı odpovˇedi od serveru je uvedeno ve tˇr´ıdˇe ConsoleContent, která implementuje interface INotifyPropertyChanged. Metoda RunCommand v této tˇr´ıdˇe se zavolá po kliknut´ı na tlaˇc´ıtko Send, nebo stisknut´ım klávesy Enter. Nejprve se pˇridá na v´ ystup prompt obsahuj´ıc´ı adresu serveru, port, ˇc´ıslo databáze (na poˇca´tku nastaveno defaultnˇe na nulu) a zadan´ y pˇr´ıkaz uˇzivatele. Následnˇe je zavolán RedisBackgroudWorker, viz pˇredchoz´ı kapitola, a docház´ı k pˇripojen´ı k serveru. Nad redisClient se zavolá CreatePipelineCommand, t´ım se pˇriprav´ı prostˇred´ı pro odeslán´ı pˇr´ıkazu. Poté je pomoc´ı regulárn´ıho v´ yrazu rozdˇelen vstupn´ı ˇretˇezec, vˇcetnˇe správného urˇcen´ı jednotliv´ ych ˇca´st´ı pˇr´ıkazu podle uvozovek. Zpracovan´ y pˇr´ıkaz je následnˇe pˇreveden na pole byt˚ u pomoc´ı ToUtf8Bytes. Takto upraven´ y pˇr´ıkaz je zapsán do vyrovnávac´ı pamˇeti metodou WriteAllToSendBuffer a zaslán na server pomoc´ı FlushSendBuffer. 1 2 3 4 5 6 7 8 9 10 11 12 13

redisClient.CreatePipelineCommand(); var regex = new Regex(@"((""((?.*?)(?[\S]+))(\s)*)"); var cmd = new List<string>(); foreach (Match m in regex.Matches(ConsoleInput)) { if (m.Groups["token"].Success) cmd.Add(m.Groups["token"].Value); } var commands = cmd.Select(c => c.ToUtf8Bytes()); redisClient.WriteAllToSendBuffer(commands.ToArray()); redisClient.FlushSendBuffer();

Pro moˇznost pˇreˇc´ıst odpovˇed’, kterou server poˇsle zpˇet správci, bylo nutné provést menˇs´ı zmˇeny ve zdrojovém kódu knihovny ServiceStack.Redis. Bylo nutné zpˇr´ıstupnit private a protected metody z tˇr´ıdy RedisNativeClient um´ıstˇené v RedisNativeClient_Utils.cs. Vˇsechny n´ıˇze uvedené metody z knihovny byly pˇre53


Konzole

psány na public. private int SafeReadByte() protected string ReadLine() private byte[] ParseSingleLine(string r) protected public string SendExpectString(params byte[][] cmdWithBinaryArgs) private byte[] ReadData() private byte[] ParseSingleLine(string r)

Pomoc´ı metody SafeReadByte je pˇreˇctena odpovˇed’ serveru, která je pomoc´ı switche zpracována dál. Kód, kter´ y je uvnitˇr bloku switch, je inspirován obsahem jednotliv´ ych metod ze tˇr´ıdy RedisNativeClient. Pokud je v odpovˇedi na zaˇca´tku znak $“ a metoda ReadLine vrát´ı hodnotu -1“, je na v´ ystup konzole pˇridán v´ ypis ” ” (nill). Pokud nevrát´ı -1“, zavolá se metoda ParseSingleLine s odpovˇed´ı serveru ” jako parametrem. V´ ysledek je pak pˇridán na v´ ystup do konzole. V pˇr´ıpadˇe, ˇze odpovˇed’ zaˇc´ıná symbolem :“, -“ nebo +“, dojde k zavolán´ı me” ” ” tody ReadLine a jej´ı v´ ystup je pˇredán na v´ ystup konzole. Pokud odpovˇed’ zaˇc´ıná symbolem *“, opˇet se zavolá metoda ReadLine a jej´ı v´ ysledek se dále zpracovává. ” Pomoc´ı int.TryParse se z´ıská poˇcet ˇca´st´ı, které byly vráceny metodou ReadLine. Je-li poˇcet roven nule, na konzoli je pˇridán v´ ypis ”(empty list or set)” a znamená to, ˇze dotaz do databáze nenaˇsel pod poˇzadovan´ ym kl´ıˇcem ˇza´dn´ y seznam ani mnoˇzinu. Pˇri kladném poˇctu je v´ ysledek pˇreveden na ˇretˇezec a pˇridán na v´ ystup konzole. Pomoc´ı pˇr´ıkazu dispatcher.Invoke(() => ConsoleOutput.Add(output)); je v´ ystup pro konzoli pˇredán hlavn´ımu vláknu, a uloˇzen do ConsoleOutput. D´ıky zmˇenˇe této vlastnosti je pak zobrazena odpovˇed’ serveru na konzoli. 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16

string readLine; var redisAnswer = redisClient.SafeReadByte(); switch (redisAnswer) { case ’$’: readLine = redisClient.ReadLine(); if (readLine == "-1") { dispatcher.Invoke(() => ConsoleOutput.Add("(nill)")); } else { var parsingLine = new byte[2][]; parsingLine[1] = redisClient.ParseSingleLine(string.Concat(char. ToString((char)redisAnswer), readLine)); var output = string.Join("\n", parsingLine.Where(m => m != null).

54


Konzole

Select(b => b.FromUtf8Bytes())); 17 18 19 20 21 22 23 24 25

dispatcher.Invoke(() => ConsoleOutput.Add(output)); } break; case ’:’: case ’-’: case ’+’: readLine = redisClient.ReadLine(); dispatcher.Invoke(() => ConsoleOutput.Add(readLine)); if (cmd.First().Equals("select", StringComparison. InvariantCultureIgnoreCase) && (cmd.Count == 2)) { _dbNumber = cmd.Last().ToInt64(); } break; case ’*’: int count; readLine = redisClient.ReadLine(); if (int.TryParse(readLine, out count)) { if (count == -1) { throw new Exception(); } if (count == 0) { dispatcher.Invoke(() => ConsoleOutput.Add("(empty list or set) ")); } else { var result = new byte[count][];

26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57

for (int i = 0; i < count; i++) result[i] = redisClient.ReadData(); var output = string.Join("\n", result.Where(m => m != null). Select(b => b.FromUtf8Bytes())); dispatcher.Invoke(() => ConsoleOutput.Add(output)); } } break; }

55


7.5

Import a export JSON soubor˚ u


Za základn´ı funkci programu byla jiˇz na zaˇca´tku v´ yvoje programu stanovena moˇznost exportovat data ze správce do JSON souboru a také funkce, která umoˇzn´ı zpˇetné importován´ı dat ze souboru. V programu je tato funkcionalita ˇreˇsena za pomoci knihovny Json.net. Po kliknut´ı na tlaˇc´ıtko Export je nejdˇr´ıve vytvoˇrena instance dialogu pro uloˇzen´ı. Automaticky je k názvu souboru pˇridána pˇr´ıpona .json. 1 2 3 4 5 6

var dlg = new Microsoft.Win32.SaveFileDialog { FileName = "", DefaultExt = ".json", Filter = "JSON text documents (.json)|*.json" };

Pro zápis do souboru je pouˇzit blok using s novou instanc´ı StreamWriteru, kter´ y slouˇz´ı k zapisován´ı do textov´ ych soubor˚ u. Dále je podobn´ ym zp˚ usobem pouˇzit JsonTextWriter, kter´ ym je za pomoci objektu JsonSerializer uloˇzen obsah databáze do StreamWriteru. Do souboru se vlastnˇe zapisuj´ı objekty DatabaseRow. 1 2 3 4 5 6 7 8 9

using (var sw = new StreamWriter(filename)) { using (JsonWriter jw = new JsonTextWriter(sw)) { jw.Formatting = Formatting.Indented; var serializer = new JsonSerializer(); serializer.Serialize(jw, dbNode.ContentOfDb); } }

Jelikoˇz je poˇzadováno uloˇzen´ı jen kl´ıˇce, typu a hodnoty, je u vlastnosti SetList, HashList a Value pouˇzit atribut serializace [JsonIgnore], d´ıky kterému nebudou zvolené vlastnosti serializovány. U vlastnosti ValueData je uveden atribut [JsonProperty("Value")], kter´ y slouˇz´ı k pˇrejmenován´ı názvu promˇenné ve v´ ysledném JSON souboru. [JsonProperty("Value")] public T ValueData { get; set; }

Pˇri importu dat z JSON souboru je postup trochu sloˇzitˇejˇs´ı. Nejprve se vytvoˇr´ı OpenFileDialog, kter´ y umoˇzn ˇuje vybrat pouze soubory s pˇr´ıponou .json. Následnˇe 56



je pomoc´ı StreamReader a JsonTextReader deserializován zvolen´ y soubor. Metoda Deserialize vrac´ı objekty, které je nutno jeˇstˇe pˇretypovat. Podle Type se rozdˇel´ı naˇctené prvky. Následnˇe se podle r˚ uzn´ ych datov´ ych struktur z´ıskaj´ı hodnoty. Spoleˇcnˇe se poté hodnoty s kl´ıˇcem a typem importuj´ı do správce. Pro SortedSet a Hash jsou data ukládána podobnˇe, proto z´ıskávaj´ı data stejn´ ym zp˚ usobem. Je tomu také v pˇr´ıpadˇe Listu a Setu. 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34

var json = serializer.Deserialize<JArray>(jr); var result = new BindingList(); foreach (var element in json) { switch (element["Type"].Value()) { case (int)RedisKeyType.SortedSet: case (int)RedisKeyType.Hash: var hashValues = element["Value"].Select( item =>new KeyValuePair<string, string>(item["Key"].Value<string>(), item["Value"].Value<string>())).ToList(); result.Add(new DatabaseRow>> { Type = (RedisKeyType)element["Type"].Value(), Key = element["Key"].Value<string>(), ValueData = hashValues }); break; case (int)RedisKeyType.String: result.Add(new DatabaseRow<string> { Type = RedisKeyType.String, Key = element["Key"].Value<string>(), ValueData = element["Value"].Value<string>() }); break; case (int)RedisKeyType.List: case (int)RedisKeyType.Set: ... break; } }

Ukázka exportovaného souboru JSON s daty je uvedena n´ıˇze. Typy dat jsou urˇceny ˇc´ıselnˇe podle enumerátoru RedisKeyType. Napˇr´ıklad typ String je enumerátorem oznaˇcen jako ˇc´ıslo jedna, List jako ˇc´ıslo dva atd.

57


1 2 3 4 5 6 7 8 9 10 11 12 13

Ukládán´ı konfigurace pˇripojen´ı

[ {"Type": 1, "Key": "Key1", "Value": "Hello World!"}, {"Type": 2, "Key": "ShoppingList", "Value": [ "milk", "butter", "bread", "eggs" ] }, {"Type": 5, "Key": "User:1234", "Value": [ {"Key": "Name", "Value": "Peter"}, {"Key": "Surname", "Value": "Black"} ] } ]

7.6

Ukl´ ad´ an´ı konfigurace pˇ ripojen´ı

V aplikaci je moˇzné pˇridávat nastaven´ı pro pˇripojen´ı k server˚ um s Redisem. Konfigurace je ukládána do souboru config.xml, kter´ y je vytvoˇren v c:\Users\\AppData\Local\Temp\. K ukládán´ı docház´ı pokaˇzdé, kdyˇz dojde ke zmˇenˇe v seznamu s pˇripojen´ımi. Do souboru se ukládaj´ı základn´ı informace, kter´ ymi jsou jméno serveru, jeho adresa, port a heslo pro pˇr´ıpadné pˇripojen´ı k zabezpeˇcenému serveru. V aplikaci se jeˇstˇe uchovává informace o roli, která urˇcuje, zda je server v roli primárn´ıho nebo sekundárn´ıho uzlu. V pˇr´ıpadˇe, ˇze se k serveru nepodaˇrilo pˇripojit, je oznaˇcen jako notconnected“. Informace o roli se z´ıskává vˇzdy aktuálnˇe pˇri pˇripojen´ı ” k serveru, proto se tato informace neukládá do konfiguraˇcn´ıho souboru a vlastnost Role je tud´ıˇz doplnˇena o atribut [XmlIgnore]. Aktuáln´ı seznam pˇripojen´ı je udrˇzován v aplikaci a souˇcasnˇe je i pˇri jakékoliv zmˇenˇe uloˇzen také na disk. 1 2 3 4

private void ConnectionListOnListChanged(object sender, ListChangedEventArgs listChangedEventArgs) { SerializeToXml>(Path.GetTempPath() + ConfigName, ConnectionList); }

Pro ukládán´ı se opˇet vyuˇz´ıvá serializace, která je podrobnˇeji popsána v pˇredchoz´ı kapitole. Tentokrát je ale pro formát XML. XML serializaci poskytuje pˇr´ımo .NET Framework. Pouˇz´ıvá se k tomu tˇr´ıda XmlSerializer patˇr´ıc´ı do jmenného prostoru Syst´ em.Xml.Serialization.

58


1 2 3 4 5 6 7 8


public static void SerializeToXml(string path, object obj) { var xs = new XmlSerializer(typeof(T)); using (var fs = File.Create(path)) { xs.Serialize(fs, obj); } }

Naˇc´ıtán´ı aktuáln´ıho konfiguraˇcn´ıho souboru je vˇzdy voláno na zaˇcátku spuˇstˇen´ı aplikace pˇri inicializaci hlavn´ıho okna aplikace. Pokud konfiguraˇcn´ı soubor neexistuje, vytvoˇr´ı se nov´ y seznam pro ukládán´ı nastaven´ı server˚ u. V opaˇcném pˇr´ıpadˇe je pouˇzita deserializace souboru config.xml. V´ ysledek, kter´ y je vrácen metodou Deserialize, je pˇreveden na aktuáln´ı seznam pˇripojen´ı. 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20

private void LoadConfig() { if (!File.Exists(Path.GetTempPath() + ConfigName)) { ConnectionList = new BindingList<ServerNode>(); } else { ConnectionList = DeserializeFromXml>(Path. GetTempPath() + ConfigName); } } public static T DeserializeFromXml(string path) { var xs = new XmlSerializer(typeof(T)); using (var fs = File.OpenRead(path)) { return (T)xs.Deserialize(fs); } }

Metody SerializeToXml a DeserializeFromXml jsou uvnitˇr tˇr´ıdy SerializeHelper, která se nacház´ı ve sloˇzce Helpers. N´ıˇze je uveden pˇr´ıklad obsahu souboru config.xml. 1 2

59


3 4 5 6 7 8 9 10 11


<ServerNode> School 147.228.67.125 6379 <ServerNode> ...

60

8 Testován´ı Tato kapitola je vˇenována samotnému testován´ı vytvoˇreného správce pro databáze. C´ılem je ovˇeˇrit správnou funkˇcnost programu v r˚ uzn´ ych testovac´ıch pˇr´ıpadech. Proces testován´ı aplikace prob´ıhal na lokáln´ım poˇc´ıtaˇci s operaˇcn´ım systémem Windows. Databázov´ y systém Redis byl spouˇstˇen na lokáln´ım poˇc´ıtaˇci pomoc´ı verze 1 pro Windows . Dále byl Redis spuˇstˇen na virtualizovaném operaˇcn´ım systému Debian pomoc´ı nástroje VirtualBox a následnˇe byla také databáze zprovoznˇena na tˇrech stroj´ıch v´ ypoˇcetn´ıho clustru, které poskytla univerzita opˇet s operaˇcn´ım systémem Debian. D´ıky tomu mohly b´ yt vyzkouˇseny vlastnosti master-slave replikace.

Konfigurace poˇ c´ıtaˇ ce Testován´ı aplikace probˇehlo na poˇc´ıtaˇci s následuj´ıc´ı konfigurac´ı: • Procesor: Intel Core2 Duo CPU • Pamˇ et’ RAM: 3GB • Operaˇ cn´ı syst´ em: Windows 7 Professional • Typ syst´ emu: 32bitov´ y operaˇcn´ı systém • Hardisk: 500 GB

8.1

Testovac´ı sc´ en´ aˇ re

Pro moˇznost otestován´ı správné funkˇcnosti aplikace se mohou pouˇz´ıt tzv. testovac´ı scénáˇre. Jedná se o popis vstupn´ıch podm´ınek a hodnot pro vykonáván´ı scénáˇre a oˇcekávan´ y v´ ysledek po proveden´ı scénáˇre. Následuj´ıc´ı scénáˇre zachycuj´ı chován´ı aplikace pˇri zadán´ı nové hodnoty do databáze, pˇri pokusu smazán´ı záznamu z databáze, která je v roli slave, a pˇri smazán´ı hodnoty v seznamu.

1

https://github.com/MSOpenTech/redis

61

Testován´ı

Testovac´ı sc´ en´ aˇ r

Testovac´ı scénáˇre

Pˇridán´ı kl´ıˇce do databáze

Popis

Uˇzivatel chce zadat novou dvojici kl´ıˇc hodnota do zvolené databáze. V aplikaci má jiˇz nastavené poˇzadované pˇripojen´ı k aktivn´ımu serveru s databáz´ı.

Pr˚ ubˇ eh

V hlavn´ım oknˇe aplikace je dvojklikem zobrazen seznam databáz´ı bˇeˇz´ıc´ıch na poˇzadovaném serveru. Dalˇs´ım dvojklikem se otevˇre záloˇzka se seznamem vˇsech kl´ıˇc˚ u v dané databázi. V horn´ı ˇca´sti je zvoleno tlaˇc´ıtko Add key pro pˇridán´ı nového kl´ıˇce. V nab´ıdce pro pˇridán´ı je zvolen typ kl´ıˇce String, název kl´ıˇce a pomoc´ı tlaˇc´ıtka, oznaˇceného symbolem tuˇzky, je nastavena pˇr´ısluˇsná hodnota kl´ıˇce. Pro pˇridán´ı kl´ıˇce do databáze je stisknuto tlaˇc´ıtko Add v hlavn´ı nab´ıdce. Kl´ıˇc je u ´spˇeˇsnˇe pˇridán do databáze a tabulka v´ ypisem obsahu databáze je automaticky aktualizována.

V´ ysledek

V´ yˇse zm´ınˇen´ y popis pˇridán´ı nového kl´ıˇce do databáze funguje korektnˇe. Kl´ıˇc i s poˇzadovanou hodnotou se uloˇz´ı do databáze a následnˇe se zobraz´ı ve v´ ypisu. V pˇr´ıpadˇe, ˇze pˇri nastavován´ı kl´ıˇce pro pˇridán´ı se stane server nedostupn´ y, tud´ıˇz do nˇej nen´ı moˇzno zapisovat, je uˇzivatel upozornˇen, ˇze pˇripojen´ı nemohlo b´ yt vytvoˇreno. Tento testovac´ı scénáˇr potvrdil správnou funkˇcnost pˇridáván´ı kl´ıˇce do databáze. Tabulka 8.1: Testován´ı pˇridán´ı kl´ıˇce do databáze.

62

Testován´ı



Smazán´ı kl´ıˇc˚ u z databáze v roli slave

Popis

V pˇr´ıpadˇe, ˇze je databáze v roli slave, která umoˇzn ˇuje pouze ˇcten´ı a replikuje si data z uzlu master, nen´ı moˇzno smazat ˇza´dn´ y kl´ıˇc (plat´ı to i pro pˇridán´ı kl´ıˇce).

Pr˚ ubˇ eh

Jsou aktivn´ı dva servery, jeden v roli master a druh´ y v roli slave. Po dvojkliku na poˇzadované pˇripojen´ı je uzel typu slave oznaˇcen ˇsedivou ikonkou. Následnˇe je uˇzivatelem otevˇrena záloˇzka s obsahem pˇr´ısluˇsné databáze. Uˇzivatel si pomoc´ı tlaˇc´ıtka Ctrl m˚ uˇze zvolit v´ıce kl´ıˇc˚ u, které chce najednou smazat. Poté stiskne tlaˇc´ıtko Delete key pro smazán´ı zvolen´ ych kl´ıˇc˚ u. Uˇzivatel je dotázán, zda opravdu chce vybrané kl´ıˇce smazat. Pˇri kladné odpovˇedi je ale uˇzivatel následnˇe upozornˇen, ˇze databáze je readonly slave a nem˚ uˇze se do n´ı zapisovat, tud´ıˇz ani odstraˇ novat hodnoty.

V´ ysledek

Poˇzadovaná operace smazán´ı hodnot z databáze, která je v roli slave, probˇehla pˇresnˇe podle oˇcekáván´ı. Uˇzivatel byl korektnˇe upozornˇen, ˇze poˇzadovaná akce nemohla b´ yt provedena a data z˚ ustala nezmˇenˇena. Tabulka 8.2: Testován´ı smazán´ı kl´ıˇce.

63

Testován´ı



Smazán´ı jedné hodnoty v kl´ıˇci typu List

Popis

Uˇzivatel poˇzaduje smazán´ı jedné hodnoty v kl´ıˇci, kter´ y je typu List. V aplikaci je otevˇrena záloˇzka s daty poˇzadované databáze.

Pr˚ ubˇ eh

Na záloˇzce jsou zobrazena data. Po dvojkliku na kl´ıˇc, kter´ y je oznaˇcen jako typ List, se otevˇre náhledové okno, stejné, které by se otevˇrelo po zvolen´ı ˇra´dku s dan´ ym kl´ıˇcem a stisknut´ı tlaˇc´ıtka Edit key. Po zvolen´ı tlaˇc´ıtka se symbolem tuˇzky se otevˇre editaˇcn´ı okno, ve kterém jsou uvedeny jednotlivé hodnoty patˇr´ıc´ı zvolenému kl´ıˇci. Hodnota, která má b´ yt odstranˇena, se oznaˇc´ı a pomoc´ı klávesy Delete se zavolá dotaz do databáze a poˇzadovaná hodnota se odstran´ı. Tabulka s daty je automaticky po provedeném dotazu do databáze aktualizována.

V´ ysledek

Smazán´ı hodnoty v kl´ıˇci, kter´ y je typu List, probˇehlo správnˇe. Obdobnˇe zm´ınˇen´ y postup funguje i pro dalˇs´ı typy dat. V pˇr´ıpadˇe, ˇze bˇehem odstraˇ nován´ı doˇslo k v´ ypadku serveru, je uˇzivatel opˇet upozornˇen pˇr´ısluˇsn´ ym chybov´ ym hláˇsen´ım. Tabulka 8.3: Testován´ı smazán´ı hodnoty v seznamu.

64

9 Závˇer ´ Ukolem diplomové práce bylo navrhnout a realizovat správce pro NoSQL databázi. Tomu pˇredcházelo seznámen´ı se s moˇznostmi a souˇcasn´ ymi nerelaˇcn´ımi databázov´ ymi systémy. Pˇri ˇreˇsen´ı a návrhu se vycházelo z porovnán´ı r˚ uzn´ ych typ˚ u NoSQL databáz´ı a klasick´ ych relaˇcn´ıch databázov´ ych systém˚ u. Z nab´ızen´ ych moˇznost´ı byl zvolen databázov´ y systém Redis, kter´ y je zástupcem key/value NoSQL databáz´ı. Druh´ ym zvaˇzovan´ ym ˇreˇsen´ım bylo pouˇzit´ı systému Riak. Z d˚ uvodu lepˇs´ı podpory a vˇetˇs´ı rozˇs´ıˇrenosti byl vybrán v´ yˇse uveden´ y distribuovan´ y systém Redis, kter´ y umoˇzn ˇuje master-slave replikaci. API poskytované Redisem bylo d˚ ukladnˇe prostudováno a z´ıskané poznatky byly vyuˇzity pˇri tvorbˇe v´ ysledného správce – NoSqlManager. Pro realizaci byl pouˇzit programovac´ı jazyk C# s knihovnou ServiceStack.Redis, která poskytuje vhodné prostˇredky pro komunikaci se systémem Redis. Pomoc´ı tˇechto nástroj˚ u byl vytvoˇren správce NoSqlManager, kter´ y umoˇzn ˇuje uˇzivatelsky jednoduchou správu databáze. Podporuje základn´ı funkˇcnost, kterou je pˇridán´ı nového kl´ıˇce, odstranˇen´ı vybran´ ych kl´ıˇc˚ u a jejich hodnot, editace stávaj´ıc´ıch dat a také import a export do souboru ve formátu JSON. Nav´ıc byla v pr˚ ubˇehu v´ yvoje pˇridána do programu konzole, která zpˇr´ıstupˇ nuje veˇskeré instrukce pˇr´ıkazové ˇrádky Redis-cli. T´ım byla dosaˇzena kompletn´ı funkcionalita, kterou systém Redis nab´ız´ı. D´ıky tomu m˚ uˇze NoSqlManager konkurovat existuj´ıc´ım ˇreˇsen´ım a zaˇradit se tak mezi správce, kteˇr´ı poskytuj´ı uˇzivatelsky pˇr´ıjemné a pˇritom u ´ˇcinné prostˇred´ı. Ovˇeˇren´ı v´ ysledk˚ u práce bylo provedeno za pomoci nˇekolika testovac´ıch scénáˇr˚ u, jeˇz byly vybrány tak, aby pokr´ yvaly co nejˇsirˇs´ı mnoˇzinu situac´ı, ke kter´ ym by mohlo v reálném pˇr´ıpadˇe pouˇz´ıván´ı doj´ıt. NoSqlManager je vytvoˇren tak, aby poskytoval uˇzivateli základn´ı i pokroˇcilé funkce Redisu. Vzhledem k tomu, ˇze se v souˇcasné dobˇe NoSQL databáze stále rychle vyv´ıjej´ı, bylo by pˇr´ıpadnˇe moˇzné v budoucnu NoSqlManager dále rozˇsiˇrovat a pouˇz´ıt i pro dalˇs´ı verze NoSQL databázov´ ych systém˚ u.

65

Seznam zkratek ACID

Atomicity, Consistency, Isolation, Durability

AOF

Append Only File

API

Aplication Programming Interface

BASE

Basically Available, Soft-state, Eventually Consistent

BLOB

Binary Large Object

BSON

Binary JSON

CAP

Consistency, Availability, Partition tolerance

CQL

Cassandra Query Language

DCL

Data Control Language

DDL

Data Definition Language

DML

Data Manipulation Language

GQL

Google Query Language

GUI

Graphical User Interface

HQL

Hypertable Query Language

HTTP

Hypertext Transfer Protocol

JSON

JavaScript Object Notation

MVVM

Model View ViewModel

NoSQL

Not Only Structured Query Language

RAM

Random Access Memory 66

Závˇer

RDB

Random Database File

RDBMS Relational Database Management System REST

Representation State Transfer

SQL

Structured Query Language

ˇ SRBD

Systém ˇr´ızen´ı báze dat

UnQL

Unstructured Data Query Language

TCP/IP Transmission Control Protocol/Internet Protocol TCL

Transaction Control Language

WPF

Windows Presentation Foundation

XAML

Extensible Application Markup Language

XML

Extensible Markup Language

67

Literatura [Aug11]

´ AUGUSTYN, Michal. Zamyˇslen´ı nad NoSQL. Augiho web [online]. 29. 10. 2011 [cit. 2014-04-28]. Dostupné z: http://www.augi.cz/ programovani/zamysleni-nad-nosql/

[Bla10]

BLACK, Benjamin. Introduction to Cassandra: Replication and Consistency. SlideShare [online]. 29. 4. 2010 [cit. 2014-0425]. Dostupné z: http://www.slideshare.net/benjaminblack/ introduction-to-cassandra-replication-and-consistency

[Cat11]

CATTELL, Rick. Scalable SQL and NoSQL data stores. ACM SIGMOD Record. 2011-05-06, vol. 39, issue 4, s. 12- [cit. 2014-04-26]. DOI: 10.1145/1978915.1978919. Dostupné z: http://portal.acm.org/ citation.cfm?doid=1978915.1978919

[Con09]

CONOLLY, Thomas, Carolyn E BEGG a Richard HOLOWCZAK. Mistrovstv´ı – databáze: profesionáln´ı pr˚ uvodce tvorbou efektivn´ıch databáz´ı. Vyd. 1. Brno: Computer Press, 2009, 584 s. ISBN 978-80-251-2328-7.

[Dat14]

Cassandra: Getting Started Documentation. DataStax [online]. 2014 [cit. 2014-04-25]. Dostupné z: http://www.datastax. com/documentation/getting_started/doc/getting_started/ gettingStartedCassandraIntro.html

[Dbe14]

Redis vs. Riak Comparison. DB-Engines: Knowledge Base of Relational and NoSQL Database Management Systems [online]. 2014 [cit. 2014-0501]. Dostupné z: http://db-engines.com/en/system/Redis%3BRiak

[Dea04]

DEAN, Jeffrey a Sanjay GHEMAWAT. GOOGLE, Inc. MapReduce: Simplied Data Processing on Large Clusters. 3. 10. 2004 [cit. 201404-22]. Dostupné z: http://static.googleusercontent.com/media/ research.google.com/cs//archive/mapreduce-osdi04.pdf

68

LITERATURA

LITERATURA

[Dol11]

´ Ondˇrej. Big data: Nové zp˚ DOLAK, usoby zpracován´ı a anal´ yzy velk´ ych objem˚ u dat. In: SystemOnLine [online]. 2011 [cit. 2014-04-16]. Dostupné z: http://www.systemonline.cz/clanky/big-data.htm

[Flo12]

FOWLER, Martin. NosqlDefinition. Martin Fowler [online]. 9. 1. 2012 [cit. 2014-04-22]. Dostupné z: http://martinfowler.com/bliki/ NosqlDefinition.html

[Gro09]

GRONINGEN, Martijn. Introduction to Hadoop. Trifork Blog [online]. 4. 8.2009 [cit. 2014-04-22]. Dostupné z: http://blog.trifork.com/ 2009/08/04/introduction-to-hadoop/

[Her06]

HERNANDEZ, Michael J. Návrh databáz´ı. 1. vyd. Praha: Grada, 2006, 408 s. ISBN 80-247-0900-7.

[Hof09]

HOFF, Todd. Neo4j: a Graph Database that Kicks Buttox. High Scalability [online]. 13. 6. 2009 [cit. 2014-04-25]. Dostupné z: http: //highscalability.com/neo4j-graph-database-kicks-buttox

[Hof10]

HOFF, Todd. Troubles with Sharding: What can we learn from the Foursquare Incident?. High Scalability [online]. 15. 10. 2010 [cit. 2014-04-24]. Dostupné z: http://highscalability.com/blog/2010/10/15/troubles-withsharding-what-can-we-learn-from-the-foursquare.html

[Cha11]

CHAPPLE, Mike. Abandoning ACID in Favor of BASE. About.com [online]. 2011 [cit. 2014-04-22]. Dostupné z: http://databases.about. com/od/otherdatabases/a/Abandoning-Acid-In-Favor-Of-Base. htm

[Jak07]

ˇ ÍK, Ondˇrej. Srovnán´ı databázov´ JAKUBC ych server˚ u. Linux EXPRES [online]. 2007 [cit. 2014-04-22]. Dostupné z: http://www.linuxexpres. cz/software/srovnani-databazovych-serveru

[Kal12]

ˇ Jindˇrich a Ludmila KALUZOV ˇ A. ´ Modelován´ı dat v inforKALUZA, maˇcn´ıch systémech. 1. vyd. Praha: Ekopress, 2012, 125 s. ISBN 978-8086929-81-1.

[Kat12]

KATSOV, Ilya. NoSQL Data Modeling Techniques. Highly Scalable Blog [online]. 1. 3. 2012 [cit. 2014-04-22]. Dostupné z: http://highlyscalable.wordpress.com/2012/03/01/ nosql-data-modeling-techniques/

69

LITERATURA

LITERATURA

[Klo12]

´ KLOBASA, Pavel. Letm´ y technologick´ y pohled na MongoDB. VsadNaJavu.cz: Odborný weblog o vývoji webových aplikac´ı nad platformou Java a J2EE [online]. 23. 1. 2012 [cit. 2014-0424]. Dostupné z: http://vsadnajavu.cz/2012-01/databaze/ letmy-technologicky-pohled-na-mongodb/

[Kos99]

KOSEK, Jiˇr´ı. Aplikace na Webu: Jak pracuj´ı databáze na Webu: Co je ˇ O WWW [online]. to databáze. Domovská stránka Jirky Koska: VSE 1999 [cit. 2014-04-22]. Dostupné z: http://www.kosek.cz/clanky/ iweb/12.html

[Kul08]

´ KULHAN, Jakub a Zdenˇek LEHOCKY. Normalizace relaˇcn´ıch databáz´ı. Programujte.com [online]. 2008 [cit. 201404-22]. Dostupné z: http://programujte.com/clanek/ 2008071900-normalizace-relacnich-databazi/

[Lac12]

LACHLAN, James. Why Big Data and Business Intelligence Are Like One Direction. SmartData Collective [online]. 2. 10. 2012 [cit. 201404-25]. Dostupné z: http://smartdatacollective.com/yellowfin/ 75616/why-big-data-and-business-intelligence-one-direction

[Mam11]

MAMTANI, Vinod. Cassandra Data Model. NimbleDais [online]. 1. 6. 2011 [cit. 2014-04-25]. Dostupné z: http://nimbledais.com/?p=150

[MaS08]

Market Share. MySQL [online]. 2008 [cit. 2014-04-22]. Dostupné z: http://www.mysql.com/why-mysql/marketshare/

[Mon14]

The MongoDB 2.6 Manual. MongoDB [online]. 2014 [cit. 2014-04-24]. Dostupné z: http://docs.mongodb.org/manual/

[MSSQL01] Microsoft SQL Server 2000: administrace systému MCSE Training Kit. Vyd. 1. Praha: Computer Press, 2001, xxii, 651 s. ISBN 80-722-6526-1. [MyS11]

Co je to databáze MySQL?. Artic Studio Webdesign [online]. 2011 [cit. 2014-04-22]. Dostupné z: http://www.artic-studio.net/ slovnicek-pojmu/databaze-mysql/

[Nia13]

NIAH, Omer. Four category of NoSQL databases with examples. Database Diary [online]. 12. 12. 2013 [cit. 2014-04-23]. Dostupné z: http://dbdiary.com/ four-category-of-nosql-databases-with-examples/

[Norm07]

Teorie relaˇcn´ıch databáz´ı: Normalizace. Manualy.net [online]. 2007 [cit. 2014-04-22]. Dostupné z: http://www.manualy.net/article. php?articleID=13 70

LITERATURA

LITERATURA

[Opp06]

OPPEL, Andrew. Databáze bez pˇredchoz´ıch znalost´ı. Vyd. 1. Brno: Computer Press, 2006, 319 s. ISBN 80-251-1199-7.

[Pok12]

´ Jaroslav. NoSQL databáze: souˇcasn´ POKORNY, y stav v´ yvoje. In: Modern´ı databáze 2012: Zpracován´ı velkých objem˚ u dat a transakc´ı. Praha: KOMIX s.r.o., 2012, s. 11. ISBN 978-80-905231-0-4. Dostupné z: http://www.analyzyareporting.cz/sitecore/content/ Komix_cs-CZ/Home/Produkty/MD/2012/~/media/Komix/Downloads/ Konference_Moderni_databaze/Moderni_databaze_2012/Sbornik_ konference_Moderni_databaze_2012.ashx

[Pok97]

´ Jaroslav. Základy implementace soubor˚ POKORNY, u a databáz´ı. 1. vyd. Praha: Karolinum, 1997, 196 s. ISBN 80-718-4472-1.

[Rah10]

RAHIEN, Ayende. That No SQL Thing: Column (Family) Databases. Ayende @ Rahien [online]. 14. 5. 2010 [cit. 2014-04-25]. Dostupné z: http://ayende.com/blog/4500/ that-no-sql-thing-column-family-databases

[Red12]

REDMOND, Eric, Jim R WILSON a Jacquelyn CARTER. Seven databases in seven weeks: a guide to modern databases and the NoSQL movement [online]. Dallas, Tex.: Pragmatic Bookshelf, 2012, xiii, 333 p. [cit. 2014-04-26]. Pragmatic programmers. ISBN 19-343-5692-1.

[Red14]

Documentation: Redis. Redis [online]. 2014 [cit. 2014-04-27]. Dostupné z: http://redis.io/documentation

[Ria11]

Why Riak. Riak Docs [online]. 2011 [cit. 2014-04-26]. Dostupné z: http: //docs.basho.com/riak/latest/theory/why-riak/

[Sad12]

SADALAGE, Pramod J. a Martin FOWLER. Introduction to Polyglot Persistence: Using Different Data Storage Technologies for Varying Data Storage Needs: Polyglot Data Store Usage. InformIT [online]. 5. 9. 2012 [cit. 2014-04-28]. Dostupné z: http://www.informit.com/ articles/article.aspx?p=1930511&seqNum=2

[Sad13]

SADALAGE, Pramod J a Martin FOWLER. NoSQL distilled: a brief guide to the emerging world of polyglot persistence. Upper Saddle River, NJ: Addison-Wesley, c2013, xix, 164 p. ISBN 03-218-2662-0.

[Seg12]

SEGUIN, Karl. The Little Redis Book. 23. 1. 2012. Dostupné z: http: //openmymind.net/2012/1/23/The-Little-Redis-Book/

[Sch88]

SCHEBER, Anton. Databázové systémy. 1. vyd. Praha: SNTL, 1988, 321 s. 71

LITERATURA

LITERATURA

[Skˇr00]

ˇ SKRIVAN, Jarom´ır. Databáze a jazyk SQL. Interval.cz [online]. 2000 [cit. 2014-04-22]. Dostupné z: http://interval.cz/clanky/ databaze-a-jazyk-sql/

[Skˇr02]

ˇ SKRIVAN, Jarom´ır. Databáze nejsou jen MySQL. Interval.cz [online]. 2002 [cit. 2014-04-22]. Dostupné z: http://interval.cz/clanky/ databaze-nejsou-jen-mysql/

[Sto10]

STONEBRAKER, Michael. SQL databases v. NoSQL databases. Communications of the ACM [online]. 2010-04-01, vol. 53, issue 4, s. 10[cit. 2014-04-28]. DOI: 10.1145/1721654.1721659. Dostupné z: http: //portal.acm.org/citation.cfm?doid=1721654.1721659

[Str11]

STRAUCH, Christof. NoSQL Databases. Stuttgart, 2011. Dostupné z: http://www.christof-strauch.de/nosqldbs.pdf

ˇ [Sel11]

ˇ SELENG, Martin a Michal LACLAVÍK. Dostupné ˇskálovatelné rieˇsenia pre spracovanie velkého objemu dát a dátové sklady. Mikulov: DATAKON 2011, 2011, 22 s. Dostupné z: http://laclavik.sk/ publications/datakon_final_2011.pdf

[Tiw11]

TIWARI, Shashank C. Professional nosql. 1. vydán´ı. Indianapolis: Wiley Pubishing, Inc., 2011. ISBN 04-709-4224-X.

[Ver13]

VERMA, Ananda. CAP Theorem. TechSpritz: Stay Tuned to Technology [online]. 17. 5. 2013 [cit. 2014-04-22]. Dostupné z: http://www. techspritz.com/cap-theorem/

72

A Uˇzivatelská pˇr´ıruˇcka Tato uˇzivatelské pˇr´ıruˇcka popisuje pouˇzit´ı aplikace NoSqlManager pro databázov´ y systém Redis, která slouˇz´ı pro jednoduchou správu. Je uveden i postup pro zprovoznˇen´ı serveru s Redisem.

Zprovoznˇ en´ı datab´ azov´ eho syst´ emu Redis Pro spuˇstˇen´ı databázového systému jsou uvedeny tˇri moˇznosti, kde prvn´ı je urˇcena pro spuˇstˇen´ı na operaˇcn´ım systému Windows, druhá pomoc´ı VirtualBoxu a tˇret´ı pro operaˇcn´ı systém Linux. Na oficiáln´ıch stránkách Redisu je odkaz na projekt skupiny Microsoft Open Tech group1 , která vyv´ıj´ı a udrˇzuje verzi Redisu pro operaˇcn´ı systém Windows. Poskytuje moˇznost si stáhnout zip soubor s funkˇcn´ı verz´ı, kter´ y je um´ıstˇen na stránkách projektu v /bin/release/. Tento soubor staˇc´ı rozbalit a následnˇe spustit redisserver.exe. Systém pak následnˇe bˇeˇz´ı jako localhost na portu 6379. Je také moˇzno si z poskytnut´ ych zdrojov´ ych soubor˚ u vytvoˇrit vlastn´ı build. Druhou moˇznost´ı je otevˇr´ıt si pomoc´ı programu VirtualBox virtualizovan´ y obraz operaˇcn´ıho systému Debian, kter´ y je souˇcást´ı pˇriloˇzeného DVD. Ve virtualizovaném systému jsou nastaveni dva uˇzivatelé, user s heslem user a root, kter´ y má administrátorská práva a heslo je opˇet stejné, root. Po pˇripojen´ı staˇc´ı spustit server pˇr´ıkazem redis-server. Dále jsou uvedeny podrobnosti o virtualizovaném obrazu. • Uˇ zivatel: user • Heslo: user • Administr´ ator: root • Heslo administr´ atora: root • IP adresa: 192.168.56.101 • Hostname: debian1 • Operaˇ cn´ı syst´ em: Debian 3.2.51-1 i686 GNU/Linux 1

https://github.com/MSOpenTech/redis

73

Uˇzivatelská pˇr´ıruˇcka

Posledn´ı moˇznost´ı je nainstalovat si systém Redis na operaˇcn´ı systém Linux. Postup instalace je pˇrevzat z domovsk´ ych stránek Redisu. Redis se nejprve stáhne, pak rozbal´ı a zkompiluje pomoc´ı následuj´ıc´ıch pˇr´ıkaz˚ u. $ $ $ $

wget http://download.redis.io/releases/redis-2.8.2.tar.gz tar xzf redis-2.8.2.tar.gz cd redis-2.8.2 make

Je nutné doinstalovat také tcl verze 8.5 a provést test. Poté lze Redis spustit ve sloˇzce src opˇet pomoc´ı pˇr´ıkazu redis-server. $ apt-get install tcl $ make test $ make install

Vytvoˇren´ı distribuované databáze s master-slave replikac´ı prob´ıhá pˇres pˇr´ıkazovou ˇra´dku Redis-cli. Na vˇsech stroj´ıch mus´ı bˇeˇzet vlastn´ı instance Redisu, poté lze na uzlu, kter´ y bude v roli slave, zadat pˇr´ıkaz slaveof host port. Pomoc´ı pˇr´ıkazu slaveof no one se zruˇs´ı replikace na daném uzlu. >slaveof 192.168.56.101 6379

74


NoSqlManager

Obrázek A.1: Ukázka hlavn´ıho okna programu NoSqlManager.

Po spuˇstˇen´ı programu NoSqlManager.exe se zobraz´ı uˇzivateli hlavn´ı okno aplikace, viz obrázek A.1. To je rozdˇeleno do nˇekolika ˇcást´ı. Levou ˇca´st zab´ırá okno pro v´ ypis stromové struktury pro pˇripojen´ı, pravou ˇcást pak zab´ıraj´ı záloˇzky s daty. V horn´ı ˇcásti je liˇsta obsahuj´ıc´ı dvˇe nab´ıdky File a About. Doln´ı ˇcást zab´ırá stavov´ y ˇra´dek, ve kterém jsou zobrazovány r˚ uzné stavové informace. Pˇri prvn´ım spuˇstˇen´ı je nutno pˇridat nové pˇripojen´ı k serveru s bˇeˇz´ıc´ım Redisem. Pomoc´ı nab´ıdky File → Add New Connection se otevˇre okno pro zadán´ı jména serveru, kter´ ym se bude prezentovat v aplikaci, IP adresa oznaˇcena v oknˇe jako Host, port, na kterém bˇeˇz´ı instance Redisu a v pˇr´ıpadˇe, ˇze je Redis zabezpeˇcen, se m˚ uˇze zadat i heslo. Okno pro pˇridán´ı nového pˇripojen´ı je stejné jako pro editaci stávaj´ıc´ıho pˇripojen´ı, viz obrázek A.2. Nastavená pˇripojen´ı se ukládaj´ı do konfiguraˇcn´ıho souboru a pˇri spuˇstˇen´ı jsou opˇetovnˇe naˇctena do stromové struktury.

75


Obrázek A.2: Okno pro pˇridán´ı a editaci pˇripojen´ı.

V levé ˇcásti aplikace je názornˇe zobrazen seznam zadan´ ych pˇripojen´ı. Na zaˇca´tku jsou oznaˇceny ˇcerven´ ym symbolem, kter´ y znamená, ˇze se k serveru jeˇstˇe nepˇripojovalo nebo ˇze je pˇr´ıpadnˇe server nedostupn´ y. Po dvojkliku na název serveru se stav aktualizuje. V pˇr´ıpadˇe u ´spˇeˇsného pˇripojen´ı se zmˇen´ı ikonka na zelenou a otevˇre se seznam databáz´ı. Pokud je server v roli slave, je opˇet pˇri dvojkliku otevˇren seznam databáz´ı, ale ikonka je zobrazena ˇsedivou barvou. T´ım je uˇzivatel upozornˇen, ˇze se jedná pouze o sekundárn´ı uzel, do kterého se nezapisuje. Na obrázku A.3 je znázornˇen seznam pˇripojen´ı. Pokud na daném serveru Redis nebˇeˇz´ı nebo je poˇzadovaná adresa neplatná, je uˇzivatel upozornˇen chybov´ ym hláˇsen´ım, ˇze se nepodaˇrilo pˇripojit k databázi.

Obrázek A.3: Ukázka stromové struktury seznamu pro pˇripojen´ı.

Nad názvem serveru je moˇzné zavolat dalˇs´ı nab´ıdku zobrazenou na obrázku A.4 pomoc´ı stisknut´ı pravého tlaˇc´ıtka myˇsi. Je zde moˇzné zvolit editován´ı nastaven´ı pˇripojen´ı, moˇznost aktualizovat stav pˇripojen´ı pomoc´ı Refresh a také pomoc´ı nab´ıdky 76


Obrázek A.4: Ukázka nab´ıdky nad zvolen´ ym serverem. Delete zvolené nastaven´ı smazat ze stromové struktury. Dalˇs´ı poskytovanou nab´ıdkou je moˇznost zobrazen´ı informac´ıch o Redisu na zvoleném serveru. Informace jsou zobrazeny formou v´ ypisu, kter´ y vrac´ı po dotazu Redis, v samostatném oknˇe, jehoˇz ukázka je na obrázku A.5. Je zde napˇr´ıklad uvedena verze systému Redis, poˇcet pˇripojen´ ych klient˚ u a mnoˇzstv´ı kl´ıˇc˚ u v jednotliv´ ych databáz´ıch.

Obrázek A.5: Ukázka okna s informacemi o serveru. V nab´ıdce je také uvedena moˇznost otevˇren´ı konzolového okna pro zvolen´ y server. Konzole je zobrazena jako jednoduché okno s ˇcern´ ym pozad´ım a b´ıl´ ym textem, viz obrázek A.6. Okno konzole je rozdˇeleno na dvˇe ˇcásti. Prvn´ı ˇcást zobrazuje poˇzadované dotazy a jejich v´ ysledky. Pro pˇrehlednost je vˇzdy pˇred dotazem zobrazena adresa serveru a ˇc´ıslo aktuáln´ı databáze. V´ ypis odpov´ıdá pˇr´ıkazové ˇra´dce Redis-cli. 77


Pˇr´ıkazy se zadávaj´ı do pole, které je um´ıstˇeno v doln´ı ˇca´sti. Pro jednoduˇsˇs´ı odes´ılán´ı dotaz˚ u je zde um´ıstˇeno tlaˇc´ıtko Send, které je aktivn´ı pouze, pokud je v poli pro dotazy zapsán nˇejak´ y text. Po zapsán´ı dotazu do vstupn´ıho pole je moˇzné také odeslat dotaz pomoc´ı klávesy Enter. Okno se zavˇre bud’ pˇr´ıkazem exit, nebo klasicky kˇr´ıˇzkem v pravém horn´ım rohu. Konzolov´ ych oken m˚ uˇze b´ yt otevˇreno v´ıce a je moˇzné pˇrep´ınat mezi hlavn´ım oknem aplikace a konzol´ı, d´ıky ˇcemuˇz m˚ uˇze uˇzivatel pouˇz´ıvat jak grafické rozhran´ı, tak pˇr´ıkazovou ˇrádku.

Obrázek A.6: Konzolové okno. Po dvojkliku na zvolenou databázi serveru ve stromové struktuˇre se otevˇre v hlavn´ı ˇcásti okna nová záloˇzka s daty. Pro jednoduˇsˇs´ı orientaci je záloˇzka vˇzdy oznaˇcena jménem serveru a oznaˇcen´ım databáze. Kaˇzdá zvolená databáze má otevˇrenu pouze jednu záloˇzku. V pˇr´ıpadˇe, ˇze záloˇzka je otevˇrena, ale nen´ı aktivn´ı, a uˇzivatel chce znovu zobrazit daná data, staˇc´ı se pˇrepnout na záloˇzku nebo znova otevˇr´ıt dvojklikem danou databázi, záloˇzka se zvolenou databáz´ı se poté stane aktivn´ı. Záloˇzky je také moˇzné pomoc´ı tlaˇc´ıtka v záhlav´ı zavˇr´ıt. Na obrázku A.7 je znázornˇena ukázka hlavn´ıho okna, ve kterém je otevˇreno nˇekolik záloˇzek.

78


Obrázek A.7: Ukázka s nˇekolika záloˇzkami. Obsah kaˇzdé záloˇzky tvoˇr´ı ˇsest tlaˇc´ıtek a tabulka s daty. Tabulka je tvoˇrena tˇremi sloupci, Key, Value a Type. Key zobrazuje jméno kl´ıˇce. Value zobrazuje hodnotu u dat typu String, u zb´ yvaj´ıc´ıch typ˚ u je zde uveden zjednoduˇsen´ y v´ ypis hodnot. Type pak urˇcuje typ dat. Pomoc´ı postrann´ıch ˇsipek tabulky je moˇzné si rozbalit podrobnˇejˇs´ı zobrazen´ı hodnot. U typ˚ u List s Set je pak zobrazen seznam hodnot. U Hash a SortedSet je po rozbalen´ı uvedena menˇs´ı tabulka. V pˇr´ıpadˇe Hash je tvoˇrena dvˇema sloupci Hash key a Value. SortedSet má také dva sloupce, Value a Score.

Obrázek A.8: Ukázka okna pro pˇridán´ı nového kl´ıˇce do databáze. 79


Nová hodnota do databáze se pˇridá pomoc´ı tlaˇc´ıtka Add key. Zobraz´ı se okno s moˇznost´ı v´ ybˇeru typu kl´ıˇce, viz obrázek A.8. Dále je nutno zadat jméno kl´ıˇce. Hodnota se pˇridává pomoc´ı tlaˇc´ıtka oznaˇceného symbolem tuˇzka. Po kliknut´ı na toto tlaˇc´ıtko se otevˇre dalˇs´ı okno, kde je umoˇznˇeno podle zvoleného typu zadávat hodnoty. V pˇr´ıpadˇe zvolen´ı typu String, je moˇzno zadat pouze jednu hodnotu. V ostatn´ıch pˇr´ıpadech je umoˇznˇeno po vyplnˇen´ı jedné ˇra´dky v tabulce stisknout Enter a zadat dalˇs´ı hodnoty. Okno pro pˇridáván´ı hodnot je zobrazeno na obrázku A.9. Tlaˇc´ıtkem Ok se potvrd´ı zvolené hodnoty a uˇzivatel je vrácen do okna pro nastavován´ı jména a typu kl´ıˇce. M˚ uˇze opˇetovnˇe zavolat okno pro u ´pravu hodnot. V pˇr´ıpadˇe, ˇze uˇzivatel jiˇz vyplnil nˇejaké hodnoty a zmˇen´ı typ dat, je upozornˇen, ˇze m˚ uˇze o nastavené hodnoty pˇrij´ıt. Po stisknut´ı tlaˇc´ıtka Add dojde k pˇripojen´ı k databázi a pˇridán´ı hodnoty. Pokud je zvoleno tlaˇc´ıtko Cancel nedojde k ˇzádné akci.

Obrázek A.9: Ukázka okna pro pˇridáván´ı a u ´pravu hodnot kl´ıˇce typu Hash.

Tlaˇc´ıtko Delete key vymaˇze z databáze vybrané kl´ıˇce. Kl´ıˇc se mus´ı nejprve oznaˇcit kliknut´ım na jeho ˇra´dek. V pˇr´ıpadˇe v´ ybˇeru v´ıce kl´ıˇc˚ u pro smazán´ı staˇc´ı pˇridrˇzet klávesu Ctrl a pomoc´ı myˇsi udˇelat hromadn´ y v´ ybˇer. Po vybrán´ı kl´ıˇc˚ u staˇc´ı kliknout na tlaˇc´ıtko Delete key a poˇzadované kl´ıˇce jsou z databáze smazány.

80


Obrázek A.10: Ukázka okna pro zobrazen´ı náhledu kl´ıˇce.

Pro u ´pravu dat je moˇzné uˇz´ıt tlaˇc´ıtko Edit key nebo dvojklik na poˇzadovan´ y ˇrádek v tabulce. Zobraz´ı se náhledové okno, které je zobrazeno na obrázku A.10, kde jsou uvedeny podrobnˇejˇs´ı informace, jako je typ kl´ıˇce, jméno kl´ıˇce a náhled na hodnoty. Pro u ´pravu je nutno stisknout tlaˇc´ıtko se symbolem tuˇzky. Otevˇre se stejná tabulka, která je pˇri pˇridáván´ı dat do databáze, viz A.9. Hlavn´ım rozd´ılem oproti pˇridán´ı nové hodnoty je, ˇze jiˇz v této tabulce docház´ı k dotaz˚ um do databáze. Napˇr´ıklad v pˇr´ıpadˇe, ˇze pomoc´ı klávesy Delete smaˇzeme nˇejakou hodnotu, dojde rovnou k proveden´ı odstranˇen´ı hodnoty v databázi. Pˇri u ´pravˇe je moˇzné pouze pˇridávat nové hodnoty nebo mazat stávaj´ıc´ı. Tlaˇc´ıtko Refresh umoˇzn ˇuje aktualizovat tabulku s daty. Pomoc´ı tlaˇc´ıtka Export je umoˇznˇeno uloˇzit aktuáln´ı data uvedená na zvolené záloˇzce do souboru ve formátu JSON. Po kliknut´ı na tlaˇc´ıtko je zobrazeno klasické dialogové okno pro uloˇzen´ı souboru. Obdobnˇe je tomu i pˇri kliknut´ı na tlaˇc´ıtko Import, které poskytuje moˇznost nahrát data do databáze ze zvoleného JSON souboru. V pˇr´ıpadˇe, ˇze se jiˇz v databázi nacházej´ı nˇejaká data, jsou pˇri importu doplnˇena o data uloˇzená v souboru. Pokud dojde k duplicitˇe kl´ıˇc˚ u, je stávaj´ıc´ı kl´ıˇc pˇrepsán importovan´ ym kl´ıˇcem a jeho hodnotami. Pouze v pˇr´ıpadˇe kl´ıˇce typu List dojde k dvojitému pˇridán´ı hodnot. Jedná se o oˇcekávané chován´ı, které je zp˚ usobeno jednoduch´ ym pˇr´ıstupem Redisu k dat˚ um.

81

B Graf závislost´ı

Obrázek B.1: Graf závislost´ı jednotliv´ ych jmenn´ ych prostor˚ u vygenerovan´ y Visual Studiem.

82

C Obsah DVD Pˇr´ılohou této diplomové práce je DVD, které má následuj´ıc´ı strukturu: ˇ mˇ • Cti e.txt – Textov´ y soubor, obsahuj´ıc´ı popis jednotliv´ ych adresáˇr˚ u uloˇzen´ ych na médiu. • Dokumentace – Obsahuje elektronickou verzi této diplomové práce. • Program NoSqlManager – Obsahuje vˇsechny souˇcásti programu, jako jsou spustiteln´ y soubor a zdrojové kódy. – bin – Obsahuje zazipovanou spustitelnou verzi programu s pˇriloˇzen´ ymi knihovnami. – doc – Vygenerovaná programátorská dokumentace. – src – Obsahuje zdrojové kódy programu a graf závislosti jmenn´ ych prostor˚ u. • Programov´ e vybaven´ı – Obsahuje nástroje pro spuˇstˇen´ı databázového systému Redis. – Instal´ ator .NET Framework 4.5.1 – Obsahuje instalaˇcn´ı program Microsoft .NET Framework 4.5.1. – MSOpenTech.Redis – Obsahuje verzi databázového systému Redis, která je spustitelná na operaˇcn´ım systému Windows. – VirtualBox – Obsahuje virtualizovan´ y obraz operaˇcn´ıho systému Debian s nainstalovan´ ym systémem Redis

83

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

Recommend Documents