Aplikace pro správu MySQL databází implementovaná v JAVĚ Lubor Petr

České vysoké učení technické v Praze Fakulta elektrotechnická Katedra počítačů

Bakalářská práce

Aplikace pro správu MySQL databází implementovaná v JAVĚ Lubor Petr

Vedoucí práce:

Ing. Jiří Daněček

Studijní program: Elektrotechnika a informatika, strukturovaný, Bakalářský Obor: Výpočetní technika 12. května 2010

iv

v

Poděkování Poděkování patří především mým rodičům za velkou podporu během studií a panu ing. Daněčkovi za vedení této práce.

vi

vii

Prohlášení Prohlašuji, že jsem práci vypracoval samostatně a použil jsem pouze podklady uvedené v přiloženém seznamu. Nemám závažný důvod proti užití tohoto školního díla ve smyslu §60 Zákona č. 121/2000 Sb., o právu autorském, o právech souvisejících s právem autorským a o změně některých zákonů (autorský zákon).

V Praze dne 12. května 2010

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

viii

ix

Abstract This bachelor thesis is aimed on describing features of database engine MySQL and on implementing simple thick client, usefull for beginers during their starting work with this database system.

Abstrakt Tento text je implementačně/rešeršní bakalářskou prací, zabývající se popisem vlastností databázového serveru MySQL a implementací jednoduchého tlustého klienta, sloužícího především začátečníkům jako pomocný nástroj v začátcích práce s tímto databázovým systémem.

x

Obsah

1 Úvod 1.1 Úvodem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.2 Popis práce . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 Databázový systém MySQL 2.1 Co je MySQL? . . . . . . . . . . . . . . . . . . . . 2.2 Historie MySQL . . . . . . . . . . . . . . . . . . . . 2.3 Architektura systému . . . . . . . . . . . . . . . . . 2.3.1 Rozdělení MySQL serveru do modulů . . . . 2.3.2 Interakce modulů serveru během vykonávání 2.4 Výhody a nevýhody MySQL . . . . . . . . . . . . 2.4.1 Výhody . . . . . . . . . . . . . . . . . . . . 2.4.2 Nevýhody . . . . . . . . . . . . . . . . . . . 2.5 Srovnání MySQL s dalšími databázovými stroji . . 3 Transakce v MySQL 3.1 Co jsou transakce? . . . . . . . . . . . . . . . . . . 3.2 Příklad využití transakcí . . . . . . . . . . . . . . . 3.3 Pravidla ACID . . . . . . . . . . . . . . . . . . . . 3.4 Řízení transakcí . . . . . . . . . . . . . . . . . . . . 3.4.1 Spouštění transakcí . . . . . . . . . . . . . . 3.4.2 Body obnovy . . . . . . . . . . . . . . . . . 3.4.3 Automatické ukončování transakcí . . . . . . 3.4.4 Spouštění transakcí mimo interpreta MySQL 4 Typy úložišť (tabulek) v MySQL 4.1 Modulární systém úložných systémů . . . . . . . . 4.2 MyISAM . . . . . . . . . . . . . . . . . . . . . . . 4.2.1 Typy MyISAM tabulek a jejich vlastnosti 4.2.2 Vlastnosti . . . . . . . . . . . . . . . . . .

xi

. . . .

. . . . . . . . . . . . . . . . dotazů . . . . . . . . . . . . . . . .

. . . . . . . .

. . . .

. . . . . . . .

. . . .

. . . . . . . .

. . . .

. . . . . . . .

. . . .

. . . . . . . . .

. . . . . . . .

. . . .

. . . . . . . . .

. . . . . . . .

. . . .

. . . . . . . . .

. . . . . . . .

. . . .

. . . . . . . . .

. . . . . . . .

. . . .

. . . . . . . . .

. . . . . . . .

. . . .

1 1 1

. . . . . . . . .

3 3 4 6 6 7 10 10 11 13

. . . . . . . .

17 17 17 18 19 19 19 20 20

. . . .

21 21 22 22 23

xii

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

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

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

23 24 24 24 25 25 25 25 25 26 26 26 27 27 27 28 29 29 29 30 30 30 30 30 31 31 32 32

5 Optimalizace konfigurace serveru, databáze a dotazů 5.1 Optimalizace konfigurace serveru . . . . . . . . . . . . . . . . . . 5.1.1 Linkování a kompilace . . . . . . . . . . . . . . . . . . . . 5.1.2 Modifikace nejdůležitějších parametrů serveru . . . . . . . 5.1.2.1 Konfigurační soubory . . . . . . . . . . . . . . . . 5.1.2.2 Umístění konfiguračních souborů . . . . . . . . . 5.1.2.3 Vzorové konfigurační soubory . . . . . . . . . . . 5.1.2.4 Důležité konfigurační parametry MySQL serveru 5.1.3 Parametry důležité pro optimalizaci výkonu databáze. . . . 5.1.4 Ostatní faktory ovlivňující výkon . . . . . . . . . . . . . . 5.2 Optimalizace databáze . . . . . . . . . . . . . . . . . . . . . . . . 5.2.1 Faktory ovlivňující výkon databáze . . . . . . . . . . . . . 5.2.2 Doporučení pro návrh výkonné databáze . . . . . . . . . . 5.2.3 Optimalizace výkonu pomocí indexů . . . . . . . . . . . . 5.2.4 Interní nástroje pro optimalizaci . . . . . . . . . . . . . . . 5.2.4.1 ANALYZE TABLE . . . . . . . . . . . . . . . . . 5.2.4.2 OPTIMIZE TABLE . . . . . . . . . . . . . . . .

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

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

33 33 33 34 34 35 35 36 36 37 38 38 38 39 39 39 40

4.3

4.4

4.5

4.6

4.7

4.8

4.9

4.2.3 Fyzická struktura tabulek . . . . . . . . InnoDB . . . . . . . . . . . . . . . . . . . . . . 4.3.1 Vlastnosti . . . . . . . . . . . . . . . . . 4.3.2 Fyzická struktura tabulek . . . . . . . . Memory (Heap) . . . . . . . . . . . . . . . . . . 4.4.1 Vlastnosti . . . . . . . . . . . . . . . . . 4.4.2 Fyzická struktura tabulek . . . . . . . . Merge . . . . . . . . . . . . . . . . . . . . . . . 4.5.1 Vlastnosti . . . . . . . . . . . . . . . . . 4.5.2 Fyzická struktura tabulek . . . . . . . . 4.5.3 Příklad práce s Merge tabulkou . . . . . 4.5.3.1 Vytvoření Merge tabulky . . . 4.5.3.2 Dotaz nad výslednou tabulkou Archive . . . . . . . . . . . . . . . . . . . . . . 4.6.1 Vlastnosti . . . . . . . . . . . . . . . . . 4.6.2 Porovnání velikosti datových souborů . . 4.6.3 Fyzická struktura tabulek . . . . . . . . Federated . . . . . . . . . . . . . . . . . . . . . 4.7.1 Vlastnosti . . . . . . . . . . . . . . . . . 4.7.2 Fyzická struktura tabulek . . . . . . . . CSV . . . . . . . . . . . . . . . . . . . . . . . . 4.8.1 Vlastnosti . . . . . . . . . . . . . . . . . 4.8.2 Fyzická struktura tabulek . . . . . . . . 4.8.3 Ukázka struktury CSV tabulky . . . . . Blackhole . . . . . . . . . . . . . . . . . . . . . 4.9.1 Vlastnosti . . . . . . . . . . . . . . . . . 4.9.2 Použití . . . . . . . . . . . . . . . . . . . 4.9.3 Fyzická struktura tabulek . . . . . . . .

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

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

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

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

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

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

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

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

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

xiii

5.3

Optimalizace dotazů . . . . . . . . . . 5.3.1 Interní optimalizace dotazů . . 5.3.2 Testování dotazů . . . . . . . . 5.3.3 Analýza provádění dotazů . . . 5.3.4 Protokolování pomalých dotazů

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

40 40 40 41 42

6 Zálohování a obnovení dat po havárii 6.1 Zálohování a obnova . . . . . . . . . . . . . . . . . . . . . 6.1.1 Mysqldump . . . . . . . . . . . . . . . . . . . . . . 6.1.2 Mysqlhotcopy . . . . . . . . . . . . . . . . . . . . . 6.1.3 Ruční záloha a obnova . . . . . . . . . . . . . . . . 6.1.4 Zálohování pomocí BACKUP a RESTORE TABLE 6.1.5 Obnova z binárního protokolu . . . . . . . . . . . . 6.2 Kontrola a oprava tabulek . . . . . . . . . . . . . . . . . . 6.2.1 Příkazy CHECK a REPAIR . . . . . . . . . . . . . 6.2.2 Myisamchk . . . . . . . . . . . . . . . . . . . . . . 6.2.3 Mysqlcheck . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

43 43 43 44 44 44 45 45 45 46 46

7 JDBC, aplikační rozhraní pro přístup k relačním databázím v JAVĚ . . . . . . . . . . . . . . . . . . . . .

47 47 48 48 49 49 49 50 50 50 50 51 51 51 51 51 51 52 52 52 53 53

8 Dostupné aplikace a jejich porovnání 8.1 Tlustí klienti . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8.1.1 MySQL Administrator . . . . . . . . . . . . . . . . . . . . . . 8.1.2 ORACLE SQL Developer . . . . . . . . . . . . . . . . . . . .

55 55 55 56

7.1

7.2

7.3

Architektura JDBC . . . . . . . . . . . . . . . . . . . . . . . . 7.1.1 Hlavní komponenty JDBC . . . . . . . . . . . . . . . . 7.1.2 Interakce komponent při navazovaní spojení s databází Ovladače databáze . . . . . . . . . . . . . . . . . . . . . . . . 7.2.1 Ovladač typu 1 . . . . . . . . . . . . . . . . . . . . . . 7.2.1.1 Výhody . . . . . . . . . . . . . . . . . . . . . 7.2.1.2 Nevýhody . . . . . . . . . . . . . . . . . . . . 7.2.2 Ovladač typu 2 . . . . . . . . . . . . . . . . . . . . . . 7.2.2.1 Výhody . . . . . . . . . . . . . . . . . . . . . 7.2.2.2 Nevýhody . . . . . . . . . . . . . . . . . . . . 7.2.3 Ovladač typu 3 . . . . . . . . . . . . . . . . . . . . . . 7.2.3.1 Výhody . . . . . . . . . . . . . . . . . . . . . 7.2.3.2 Nevýhody . . . . . . . . . . . . . . . . . . . . 7.2.4 Ovladač typu 4 . . . . . . . . . . . . . . . . . . . . . . 7.2.4.1 Výhody . . . . . . . . . . . . . . . . . . . . . 7.2.4.2 Nevýhody . . . . . . . . . . . . . . . . . . . . Práce s JDBC . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.3.1 Registrace ovladače . . . . . . . . . . . . . . . . . . . . 7.3.2 Připojení k databázi . . . . . . . . . . . . . . . . . . . 7.3.3 Provádění dotazů . . . . . . . . . . . . . . . . . . . . . 7.3.4 Ukázka práce s JDBC . . . . . . . . . . . . . . . . . .

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

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

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

xiv

8.2

8.1.3 Tencí 8.2.1 8.2.2 8.2.3

Shrnutí vlastností klienti . . . . . . . phpMyAdmin . . Adminer . . . . . Shrnutí vlastností

tlustých klientů . . . . . . . . . . . . . . . . . . . . . . . . . . . tenkých klientů

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

9 Analýza funkcionalit vytvářené aplikace

56 56 57 57 58 59

10 Popis implementace 10.1 Výběr programovacího jazyka . . . . . . . . 10.2 Vývojové prostředí . . . . . . . . . . . . . . 10.3 Vývoj grafického prostředí aplikace . . . . . 10.3.1 AWT . . . . . . . . . . . . . . . . . . 10.3.2 Swing . . . . . . . . . . . . . . . . . 10.4 Hibernate framework vs. JDBC . . . . . . . 10.5 Charakter aplikace . . . . . . . . . . . . . . 10.5.1 Charakter klienta . . . . . . . . . . . 10.5.2 MDI . . . . . . . . . . . . . . . . . . 10.6 Konzole . . . . . . . . . . . . . . . . . . . . 10.7 DB Manager . . . . . . . . . . . . . . . . . . 10.8 Editor SQL . . . . . . . . . . . . . . . . . . 10.9 Algoritmus zvýrazňování klíčových slov . . . 10.9.1 Popis algoritmu . . . . . . . . . . . . 10.9.2 Popis tříd obstarávající zvýrazňování

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

61 61 62 62 62 62 63 63 63 63 64 64 64 65 65 67

. . . . . . . . .

69 69 70 70 70 71 72 73 73 74

12 Závěr 12.1 Náměty na další úpravy aplikace . . . . . . . . . . . . . . . . . . . . 12.2 Shrnutí práce . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

75 75 75

A Uživatelská příručka A.1 Instalace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A.2 HW a SW požadavky . . . . . . . . . . . . . . . . . . . . . . . . . . . A.3 Popis nejdůležitějších částí aplikace . . . . . . . . . . . . . . . . . . .

77 77 77 78

B Seznam zkratek

83

11 Testování 11.1 Nezávislí uživatelé . . . . . . . . . . 11.2 Dumb monkey testing . . . . . . . . 11.3 JMeter . . . . . . . . . . . . . . . . . 11.3.1 Monitor běhu vláken . . . . . 11.3.2 Test spotřeby času procesoru 11.3.3 Analýza alokované paměti . . 11.4 JConsole . . . . . . . . . . . . . . . . 11.5 JUnit testy . . . . . . . . . . . . . . 11.6 Track . . . . . . . . . . . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

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

. . . . . . . . .

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

. . . . . . . . .

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

. . . . . . . . .

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

. . . . . . . . .

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

. . . . . . . . .

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

. . . . . . . . .

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

. . . . . . . . .

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

. . . . . . . . .

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

. . . . . . . . .

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

. . . . . . . . .

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

. . . . . . . . .

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

. . . . . . . . .

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

. . . . . . . . .

xv

C UML Diagramy

85

D Obsah CD

89

xvi

Kapitola

1

Úvod

1.1

Úvodem

Fenoménem dnešní doby se zcela jistě stal internet a webové aplikace. Velké množství lidí pravidelně kontroluje příspěvky na různých sociálních sítích jako např. Facebook apod., nahrává či stahuje množství souborů z různých serverů pro výměnu dat nebo prostě a jednoduše surfuje na internetových stránkách. Všechny tyto činnosti produkují velké množství dat, které je potřeba efektivně zpracovat, ukládat a spravovat. Velmi rozšířeným a oblíbeným databázovým systémem nasazovaným v této oblasti je open source1 relační databáze2 MySQL. Tuto technologii využívají i takové giganty jako je např. Google, Nokia a webové portály Wikipedia, Facebook, YouTube. MySQL v sobě spojuje rychlost a výhodné licenční podmínky3 , jež umožňují ve většině případů nasazení tohoto systému bez placení licenčních poplatků a širokou podporu ve všech nejpoužívanějších programovacích a skriptovacích jazycích (Java, C, C++, PHP, Perl, Python, Ruby, C# a Visual Basic).

1.2

Popis práce

Ve své bakalářské práci jsem se rozhodl zaměřit na problematiku správy databází v MySQL. Cílem práce je shrnutí všech základních vlastností databázového stroje MySQL a vytvoření jednoduché aplikace pro správu databází, která by mohla být používána tam, kde není možné použít phpMyAdmin4 nebo jiného podobného ná1

Open source je počítačový software s otevřeným zdrojovým kódem. Slovo databáze je v této práci chápáno ve dvou významech. Jednak je jím označován samotný databázový systém ale je jím také označována konkrétní databáze(katalog) uchovávající v sobě tabulky a jiné struktury. 3 MySQL je zdarma pokud ho používáte jako samostatný celek. Pokud vyvíjíte a prodáváte aplikaci, jejíž nedílnou součástí je MySQL server, je nutno zakoupit licenci. 4 phpMyAdmin je open source nástroj implementovaný v PHP zaměřený na administraci MySQL. Nemůže být nasazen tam, kde chybí HTTP server s podporou PHP. 2

2

Úvod

stroje. Tato aplikace by také mohla pomáhat méně zkušeným uživatelů v začátcích práce s tímto systémem.

Kapitola

2

Databázový systém MySQL

Tato kapitola se věnuje popisu historie a architektury systému MySQL. Porovnává tento systém s ostatními produkty a uvádí jeho výhody a nevýhody.

2.1

Co je MySQL?

MySQL je open source multiplatformní relační databázový systém (RDBMS) původně vyvíjený švédskou firmou MySQL AB. Za jeho hlavní tvůrce jsou považováni programátoři Michael Monty Widenius, David Axmark a Allan Larsson. V současnosti je vyvíjen a podporován firmou SUN1 vlastněnou firmou ORACLE2 . Zajímavostí je, že systém nese jméno MySQL podle dcery jednoho z tvůrců jménem My. Vzhledem k tomu, že MySQL bylo od počátku vyvíjeno s důrazem na rychlost, dosahuje v některých testech mnohem lepších výsledků než konkurence. Na druhou stranu je třeba říci, že v některých oblastech značně pokulhává (viz. Výhody a nevýhody MySQL 2.4). Kvůli rychlosti, jednoduchosti použití a spolehlivosti je rozšířena na většině malých i velkých web serverech. Programátoři webových stránek si oblíbili kombinaci MySQL, PHP, a Apache3 . Tato trojice se stala do jisté míry základním standardním software webových serverů. Ve velké míře je využívána státními4 a neziskovými institucemi. Velkou roli také hraje ve velkých podnikových aplikacích. Její oblíbenost dokládá fakt, že za dobu existence MySQL bylo staženo více než 100 miliónů kopií tohoto softwaru. MySQL je založeno na relačním modelu. Data jsou uspořádána do jednotlivých tabulek (relací), nad nimiž jsou definovány přípustné operace. Tabulky se skládají ze sloupců (atributů) a řádků (záznamů). Pro potřebu jednoznačné identifikace jsou záznamy označovány primárním klíčem. Může to být speciální redundantní atribut nebo atribut entity či kombinace několika atributů. 1

Sun Microsystems, Inc. - celosvětový výrobce počítačů, počítačových komponent a software Oracle - společnost vlastnící a vyvíjející stejnojmenný databázový systém 3 Apache - velice oblíbený HTTP server původně vytvořený na universitě v Illinois 4 MySQL využívá NASA - National Aeronautics and Space Administration, Národní úřad pro letectví a kosmonautiku USA nebo Census Bureau - Úřad pro sčítání lidu Spojených států 2

4


Jak název napovídá, komunikace s databází probíhá pomocí jazyka SQL. Je to jazyk speciálně navržený pro manipulaci s daty v relačních databázích. Za jeho prvotní tvůrce můžeme považovat Donalda D. Chamberlina a Raymona F. Boyce z firmy IBM5 , kteří v sedmdesátých letech minulého století vytvořili jazyk podobný dnešnímu SQL s názvem SEQUEL. Tento jazyk byl primárně určen pro firemní relační databázový systém IBM System R. Od původního SQL vzniklo mnoho dialektů (SQL-86, SQL-89, SQL-92, SQL:1999, SQL:2003,SQL:2008). Dnešní SQL je standardizováno podle normy ISO/IEC 9075.

2.2

Historie MySQL

Historie MySQL sahá až do roku 1979, kdy Monty Widenius pracoval pro malou firmu jménem TcX. Pro ní v BASICu 6 vytvořil nástroj pro správu verzí zdrojového kódu. Během času byl tento nástroj přepsán v jazyce C, portován na Unix a pojmenován Unireq. O několik let později se M. Widenius stal spoluvlastníkem firmy TcX, mohl tedy rozhodovat co a jak se bude implementovat do jeho původního kódu. Někdy kolem roku 1990 začali zákazníci požadovat po firmě TcX, aby byl původní Unireq doplněn o SQL interface. Bylo zvažováno několik možností implementace. Jedna z nich byla postavena na využití některé komerční databáze, ale M. Widenius nebyl spokojen ani s jednou z nich. Největší problém spatřoval v nedostatečné rychlosti dostupných databází. Pokoušel se využít částí zdrojového kódu mSQL 7 a snažil se je propojit se svým nízkoúrovňovým databázovým strojem. Stále však nedosahoval takových výsledků, jaké by si přál. Jak sám řek: I’ ve had enough of those tools that somebody else wrote that don’ t ” work! I’ m writing my own!“ Rozhodl se tedy, že nebude navazovat na práci jiných a systém začne vytvářet od začátku bez použití cizích knihoven. V květnu roku 1996 byla vydána 1. verze MySQL. Tato verze byla distribuována omezené skupině vývojářů a testerů. O pár měsíců později, v říjnu roku 1996, byla vypuštěna první veřejná verze s označením 3.11.1. Tato prvotní verze byla poskytována ve formě binárních souborů pro systém Solaris8 . O měsíc později byly vydány zdroje a binární soubory pro Linux9 . V dalších dvou letech bylo MySQL portováno na mnoho dalších operačních systémů a množina funkcionalit pomalu rostla. MySQL bylo původně vydáno pod speciální 5

IBM - nadnárodní společnost zabývající se vývojem počítačů a konzultacemi v oblasti IT BASIC - programovací jazyk původně určený pro výuku programovaní, díky své jednoduchosti se stal velice oblíbený, jeho tvůrci jsou John G. Kemeny a Thomas E. Kurtz 7 mSQL - Mini SQL, jednoduchá databáze od firmy Hughes Technologies vyvíjená od roku 1994 8 Solaris - operační systém unixového typu, jeho nynějším vlastníkem je firma Oracle 9 Linux - operační systém unixového typu založený na jádru Linux 6

2.2 Historie MySQL

5

licencí, která umožňovala komerční využití těm firmám, které MySQL neredistribuují s jejich vlastním software. Pro prodej software s MySQL si musela firma opatřit speciální placenou licenci. Během několika dalších měsíců dospělo MySQL do verze 3.22. Tato verze podporovala většinu SQL příkazů, byl přidán velmi sofistikovaný optimalizer. API bylo doplněno o řadu funkcí, což umožnilo snadnější psaní klientských aplikací. Na druhou stranu stále chyběla podpora transakcí, vnořených dotazů, cizích klíčů, uložených procedur a pohledů. Zámky byly implementovány pouze na úrovni tabulek, to mohlo velice drasticky zpomalovat vykonávaní dotazů. Stále však převládal názor, že MySQL je spíš hračka pro děti než užitečné datové úložiště. Proto se v této době jen minimum programátorů a DB specialistů rozhodlo pro přechod z Oraclu nebo z SQL Serveru na MySQL. Okolo roku 1999 - 2000 byla založena společnost MySQL AB, která zaměstnávala pouze několik vývojářů. Tato společnost začala spolupracovat s firmou Sleepycat10 , což vedlo k vytvoření SQL interface pro Berkeley DB11 . Dále byla od Berkeley DB převzata podpora transakcí. Po dalších úpravách v kódu zajišťujících integraci s Berkeley DB byla vydána verze 3.23. Vývojáři MySQL dlouho nemohli vyladit všechny chyby spojené s Berkeley DB, tabulky nebyly stabilní a docházelo k neefektivnímu využití systémových prostředků. Důsledkem toho bylo vytvoření univerzálního rozhraní, které umožňovalo připojení mnoha různých mechanizmů ukládání dat. Od dubna roku 2000 byla přidána, za finanční podpory portálu Slashdot12 , podpora master-slave replikace. Starý úložný systém ISAM nepodporující transakce byl přepracován a nazván MyISAM. Přibyla také podpora full-textového vyhledávání, uzamykání na úrovni řádků a byl implementován nový úložný systém InnoDB. Další přelomovou verzí se stala verze 4.0. Do systému byla přidána Query cache, která významně vylepšila výkon mnoha aplikací. Kód obstarávající master-slave replikaci byl přepsán. Nyní využíval dvě vlákna: jedno pro I/O operace mastera a druhé pro procesy udržující aktuální data. Vylepšení se také dočkal optimalizer a komunikační protokol, který pro zabezpečení komunikaci začal využívat SSL. V červnu 2004 byla vypuštěna verze 4.1, stejně jako verze 4.0 přinesla mnoho vylepšení. Asi nejvýznamnější a nejočekávanější z nich byla podpora vnořených dotazů. Úložný systém MyISAM dostal vylepšení v podobě podpory indexování. Implementována také byla podpora Unicode. Velkých změn se dočkal i klient/server protokol, byla vylepšena jeho bezpečnost a nově podporoval předpřipravené dotazy. Velmi významná a dlouho očekávaná byla verze 5.0, která přinesla podporu uložených procedur, kurzory na serverové straně, triggery, pohledy, distribuované transakce. Významného zlepšení se také dočkal optimalizer dotazů. V současné době je stabilní verze 5.1.42. Ta přinesla podporu fragmentace dat v tabulkách, podporu replikace řádků, plánovač událostí a standardizaci plug-in API, které usnadňuje integraci nových úložných mechanizmů. 10

Sleepycat - společnost vyvíjející Barkeley DB, zanikla roku 2006, kdy byla koupena Oraclem Berkeley DB - velice výkonná multiplatformní databáze s podporou v mnoha programovacích jazycích 12 Slashdot - webový portál přinášející novinky z oblasti IT technologií 11

6


2.3

Architektura systému

V této části práce se budu věnovat stručnému popisu vnitřní architektury a průběhu vykonávání dotazů uvnitř MySQL serveru.

2.3.1

Rozdělení MySQL serveru do modulů

MySQL je velice rozsáhlý software. Jeho důkladný popis by byl velice náročný a ani není cílem této práce, zabíhat do úplných podrobností. Proto pro zjednodušení popisu zavádím jednotku modul. Moduly jsou části kódu vykonávající nějakou určitou důležitou funkci. Logicky na sebe navazují. MySQL server můžeme rozdělit na tyto hlavní moduly: • Inicializační modul - stará se o inicializaci serveru po startu • Správce spojení - obsluhuje požadavky na připojení uživatelů • Plánovač vláken - vytváří a ukončuje uživatelská řídící vlákna • Řídící uživatelské vlákno - vlákno uchovávající informace o spojení • Plánovač příkazů - plánuje jakým způsobem se bude příkaz provádět • Logging modul - obstarává zaznamenávání (protokolování) informací • Parser - analyzuje syntaktickou strukturu dotazů • Cache dotazů - uchovává v sobě výsledky často prováděných dotazů • Optimalizer - optimalizuje požadavky tak, aby byly prováděny co možná s nejmenším využitím systémových prostředků • Table Modification, Table Maintenance, Replication a Status modul - moduly sloužící pro interpretaci dotazů, starají se například o modifikaci, defragmentaci a replikaci tabulek • Modul přístupových práv - rozhoduje o povolení přístupu uživatele k daným datům • Table modul - pracuje s daty, které získává voláním abstraktního úložného sytému • Abstraktní úložný systém - abstrakce fyzického úložného systému, umožňující jednotný přístup k rozdílným úložným systémům • I/O modul - stará se o nízkoúrovňovou síťovou komunikaci

2.3 Architektura systému

2.3.2

7

Interakce modulů serveru během vykonávání dotazů

Pokud je server spuštěn z příkazového řádku, aktivuje se Inicializační modul, který projde konfigurační soubory, nastaví se podle parametrů zadaných z příkazového řádku, alokuje globální paměť, inicializuje globální proměnné a další paměťové struktury. Dále nahraje tabulku přístupových práv a spustí další inicializační úlohy. Po dokončení inicializace je řízení předáno správci spojení, ten začne ve smyčce čekat na připojení klientů. Když se klient připojí k serveru, správce spojení otestuje korektnost probíhající komunikace a předá řízení Plánovači vláken, ten vytvoří speciální vlákno uchovávající informace o spojení, toto vlákno budeme nazývat Řídící uživatelské vlákno. Řídící uživatelské vlákno může být uloženo do cache vláken, nebo naopak vyvoláno z cache a aktivováno. Pokud je řídícímu vláknu předáno řízení, jako první zkontroluje přihlašovací údaje a následně je uživateli umožněno pracovat s databází. Pokud uživatel odešle nějaký požadavek, řídící vlákno předá data z požadavku do plánovače příkazů. V terminologii MySQL se požadavky od klientů rozdělují do dvou skupin: dotaz a příkaz. Dotazy jsou takové požadavky, které musí být před vykonáním analyzovány parserem. Příkaz je takový požadavek, který analyzován být nemusí. Příkazy mohou být plánovačem příkazů přesměrovány přímo, pokud se jedná o komplexnější požadavek je směrován přes další speciální moduly. Typický příkazem je například změna aktivní databáze, výpis stavových proměnných, ukončení spojení atd. Plánovač příkazů předává dotazy do praseru přes cache dotazů. Cache dotazů ověří, jestli daný dotaz do ní může být uložen a zda neobsahuje předpřipravená data pro tento dotaz. Následně je dotaz analyzován parserem, který rozhodne v závislosti na jeho typu, jak bude dotaz vykonán. Poté je dotaz vykonán a řízení je předáno řídícímu vláknu a je možno provést další dotaz. Pokud je zapnuto protokolování, plánovač příkazů odesílá dotazy do Logging modulu, kde jsou podle priority zpracovány na plain-text a uloženy. Ve full logging konfiguraci jsou všechny dotazy uloženy, mimo těch co mají nesprávnou syntaxi nebo těch co vyvolaly chybu. V MySQL dále existují tyto moduly: Optimizer, Table Modification, Table Maintenance, Replication a Status modul. Dotazy typu SELECT jsou předány do Optimizeru. Dotazy jako UPDATE, INSERT, DELETE, případně dotazy vytvářející databáze a tabulky jsou směrovány do příslušného Table Modification Modulu, ten se dále dělí na Delete, Create, Update, Insert a Alter modul. Dotazy upravující statistiky klíčů a defragmentující tabulky jsou předány do Table Maintenance modulu. Dotazy spojené s replikací směřují do Replication modulu. Dotazy spojené s informacemi o stavu serveru jdou do Reporting modulu. Všechny moduly, které převzaly řízení od Parseru, projdou seznam tabulek přiložený v dotazu a za pomoci modulu přístupových práv ověří, zda uživatel má přístup k daným datům. Následně jsou data odeslána do Table modulu a otevřou se tabulky a všechny potřebné zámky nad daty. V tomto okamžiku je Table modul připraven vykonávat operace nad daty. Samotné datové operace jsou prováděny abstraktním

8


úložným systémem. Table modul pouze využívá jeho služeb v podobě volání jeho specifických funkcí. Abstraktní úložný systém automaticky přeloží volání od Table modulu na konkretní metodu daného úložného systému. Abstrakce úložného systému přináší výhodu v tom, že se volaný a volající modul nemusí starat o přesnou podobu datových objektů daného úložného systému. Pro všechny systémy bude volání vypadat naprosto identicky. Po vykonání dotazu nebo příkazu odpovídající modul pošle části výsledku požadavku klientovi. Výsledkem můžou být i varování a chybové zprávy. Pokud nastane chyba, klientská i serverová strana jsou o tom uvědoměny a provedou odpovídající opatření. Klient nepřijímá další data od serveru a další chybové a varovné zprávy, dokud server nepředá řízení zpět vláknu spojení. Pokud úložný sytém vykoná nějakou změnu v datech, je aktivováno binární protokolování. Tento modul je zodpovědný za předání zprávy do Logging modulu. Ten zapíše do katalogu provedenou změnu. Tato operace se někdy označuje jako replication log nebo binlog. Po dokončení všech operací nad daty je řízení vráceno uživatelskému řídícímu vláknu. Řídící vlákno provede dealokaci všech používaných prostředků a opět začne ve smyčce čekat na další požadavek. Spojení je definitivně přerušeno až po obdržení příkazu QUIT. Detailní schéma interakce jednotlivých modulů v MySQL ukazuje obrázek 2.1

2.3 Architektura systému

Obrázek 2.1: Schéma interakce jednotlivých modulů MySQL

9

10


2.4

Výhody a nevýhody MySQL

Nyní se zaměříme na popis základních výhod a nevýhod MySQL serveru. Problémem je to, že všichni výrobci databází jednotně tvrdí, že právě jejich produkt je ten nejlepší, nejpoužívanější, nejbezpečnější atd. Nezávislému pozorovateli dá hodně práce, aby rozeznal skutečné kvality od pouhých reklamních sloganů. Uvedu tedy jen ty vlastnosti, které považuji za důležité a které dle mého názoru nejsou jen marketingová hesla.

2.4.1

Výhody

• Rychlost - Rychlost byla při vývoji MySQL vždy klíčovým faktorem, proto se nové funkce přidávaly až tehdy, pokud je bylo možné implementovat bez snížení výkonu. I když to někdy znamená pomalejší přidávání funkcionality, než by si uživatelé přáli. • Cena - Cena se porovnává asi nejsnáze. Pro celou řadu aplikací je MySQL zdarma. Licence GPL Vám umožní používat software, modifikovat zdrojový kód a distribuovat MySQL dalším lidem, kteří budou následně také vázáni GPL licencí. Za určitých okolností, chcete-li například redistribuovat MySQL jako část komerčního software, si musíte koupit komerční licenci. • Komerční licence - MySQL spadá do kategorie open-source databází jako například PostgreSQL a Firebird. Z těchto systémů pouze MySQL vlastní pouze jedna společnost, která vlastní všechna práva k duševnímu vlastnictví a nabízí plné komerční licence včetně odpovědnosti a odškodnění, což vyžadují velké organizace. • Stabilita - Všechny verze MySQL publikované v binární podobě, dokonce i alfa-verze, musí projít důkladnými testy. Testují se jednak funkce a další funkčnost, ale také výsledky operací, kde byla v minulosti opravena chyba, tím se zajistí, že se chyby nikdy nemohou náhodně znovu objevit. Vývojáři také musí upřednostňovat opravy chyb před jinými vývojovými úkoly. V podstatě pozastaví ostatní práci, dokud neopraví chyby týkající se oblasti jejich kvalifikace. Pravidlem je, že verze MySQL by měly být oproštěny od všech známých a opakovatelných chyb. • Komunitní vývoj - Kvalita verzí je také zajištěna prostřednictvím zákazníků a komunity MySQL. Se systémem pracuje přes čtyři milióny uživatelů, kteří používají různá prostředí. Tím vzniká vysoká pravděpodobnost nalezení chyb, a to i v raných fázích vývoje. • Systém ohlašování chyb - MySQL má veřejně přístupný systém oznamování chyb. Kdokoliv může nahlásit nalezenou chybu, což vede k rychlejšímu nalezení a opravě chyb. • Multiplatformnost - MySQL je podporováno na mnoha operačních systémech - AIX, Amiga, BSDI, DEC, FreeBSD, HP-UX, Linux, Mac OS X server,

2.4 Výhody a nevýhody MySQL

11

NetBSD, OpenBSD, OS/2, SGI Irix, Solaris, SunOs, SCO OpenServer a UnixWare, Tru64 Unix, Window • Snadné použití - Instalace a konfigurace je velice snadná. Systém nemusíte složitě nastavovat. Server do jisté míry funguje přímo po instalaci s tím, že výchozí hodnoty se nastaví na minimální využívání diskových a paměťových prostředků. S přenastavením serveru nám pomohou přiložené konfigurační soubory.

2.4.2

Nevýhody

• Funkční výbava I když se vývojáři úpěnlivě snaží dohnat ostatní konkurenční databázové systémy, stále ještě MySQL nenabízí takovou širokou paletu funkcionalit a podpůrných nástrojů jako například ORACLE. • Výkon Na výkonu MySQL se podepisuje velikost dané databáze, při velikosti databáze řádově desítky TB a stovky přístupů za sekundu je její výkon nesrovnatelně nižší než například u PosgresSQL. Nemá tedy dostatečný výkon v opravdu náročných (extrémně zatěžovaných) webových aplikacích. Tehdy se používají konkurenční databáze, PostgreSQL nebo Oracle. • Konfigurace Celková konfigurovatelnost a laditelnost MySQL serveru je minimální • Clustering Velkou nevýhodu vidím v tom, že podpora clusteringu je dostupná ve verzi Enterprise a komunitní verze je o ní ochuzena. • Nevhodná implementace některých funkcionalit: – Pohledy Pohledy se v MySQL vyhodnocují při každém dotazu znovu. Na rozdíl od jiných databázových serverů nedokáže MySQL vytvořit tzv. materializovaný pohled, který by data fyzicky ukládal (a při změně aktualizoval) a nad kterým by třeba šly definovat i indexy. – Sestupné indexy MySQL při definici indexů ignoruje požadavek na sestupné třídění položek (skupina DESC, pořadí) vytvoří stejný index jako (skupina, pořadí). – Uložené procedury 1. Oproti PostgreSQL MySQL zvládá nejen funkce, ale i procedury se vstupními a výstupními parametry (PostgreSQL podporuje pouze procedury bez výstupních parametrů, ty MySQL nepodporuje).

12


2. Chybí možnost dynamicky vykonávat SQL dotazy, vyvolat chyby, jakákoliv rozumná možnost trasování 3. Ve funkcích není dovoleno (je omezeno) používání SQL příkazů. Množiny jsou přístupné pouze pomocí kurzorů. 4. Dočasné tabulky vytvářené v uložené proceduře mají pouze session platnost (stejně jako v PostgreSQL). To mírně komplikuje procedury, které si vytvářejí vlastní dočasné tabulky, například pro uložení mezivýsledků, atd. 5. Rychlost interpretace procedur je i v jednoduchých případech desetkrát pomalejší oproti PL/pgSQL. – Transakce 1. Provádění transakcí nad některými úložišti není dostatečně efektivní. 2. Všechny příkazy pracující se strukturou tabulek vyvolají implicitní COMMIT právě probíhající transakce. Platí to i pro další příkazy, např. ty pro práci s uživateli a donedávna třeba i pro příkaz LOAD DATA. – Indexy nad výsledkem funkce MySQL na rozdíl třeba od PostgreSQL nedovoluje vytvářet indexy nad výsledkem funkce. Pokud na sloupec v dotazu aplikujeme nějakou funkci, tak se index až na výjimky nepoužije. – Triggery 1. Trigger nemůže měnit data ve stejné tabulce, pro kterou je definován. 2. Triggery se nespustí při kaskádovém mazání. Pokud definujeme cizí klíč s příznakem ON DELETE CASCADE a v tabulce je definovaný trigger pro smazání, tak se tento trigger nespustí, pokud se záznam smaže v důsledku kaskády. – Omezující podmínky MySQL ignoruje omezující podmínky definované klauzulí CHECK při vytváření tabulky. Nedostatky výše uvedené jen potvrzují to, že MySQL je ještě v celku mladý, dynamicky se vyvíjející systém. Triggery, pohledy, uložené procedury atd. byly ještě v nedávné době na okraji zájmu vývojářů z MySQL. Vůbec mě tedy nepřekvapuje, že nové verze systému trpí dětskými nemocemi, které se snad v průběhu několika dalších verzí podaří úspěšně odstranit.

2.5 Srovnání MySQL s dalšími databázovými stroji

2.5

13

Srovnání MySQL s dalšími databázovými stroji

Jak již bylo několikrát uvedeno, na trhu je spousta dalších open-source i komerčních databází přímo i nepřímo konkurujících MySQL. Nyní se zaměříme na porovnání MySQL s dalšími velkými hráči z oblasti databázového průmyslu. Za oponenty MySQL jsem vybral následující produkty: • DB2 - je relační databázový server vyvíjený společností IBM. Primárně je určen pro operační systém Unix, Windows a Linux. DB2 byla první komerční databáze využívající pro komunikaci jazyk SQL, který byl původně vyvinut pro experimentální databázový systém IBM System R. • Firebird - je open-source relační databázový server určený pro platformy Unix, Linux a Windows. Databáze byla odvozena v roce 2000 z open-source edice InterBase firmy Borland. • Informix Dynamic Server - je relační databázový systém původně vyvíjený firmou Informix Software Inc., nyní je ve vlastnictví firmy IBM. • Microsoft Access - je relační databáze, která kombinuje Microsoft Jet Database Engine s grafickým rozhraním a vývojovými nástroji. Access je částí kancelářského balíku Microsoft Office, ale může být zakoupen i samostatně. Access ukládá data ve vlastním datovém formátu, ale také dokáže data přímo importovat do všech ODBC kompatibilních databází jako např. Microsoft SQL Server, Oracle, MySQL a PostgreSQL. Systém Access jsem do porovnání zahrnul z toho důvodu, že MySQL je často přirovnáváno k tomuto systému, chtěl bych tedy tuto fámu vyvrátit a poukázat na to, že MySQL je mnohem vyspělejší systém. • Microsoft SQL Server - je relační databázový server, jeho primárními dotazovací jazyky jsou T-SQL a ANSI SQL. Původní jádro systému bylo převzato z Sybase SQL Serveru. • ORACLE - je jeden z nejstarších zástupců relačních databází. Jeho historie sahá až do roku 1977, kdy Larry Ellison a Bob Miner založili firmu zabývající se konzultacemi v oboru IT. Tato společnost vyvinula první verzi tohoto systému. V dnešní době je ORACLE jedním z lídrů databázového průmyslu. • PostgreSQL - je open-source objektově-relační databáze (ORDBMS) PostgreSQL, jako mnoho dalších open-source programů, není vlastněn a kontrolován pouze jednou firmou, ale je spravován celosvětovou komunitou vývojářů. • SQLite - je odlehčený relační databázový systém kompatibilní s konceptem ACID (viz. 3.3 Pravidla ACID). Systém obsahuje relativně malou( 225 kB) C knihovnu, to umožnilo jeho rozšíření jako integrovaného úložiště pro různé aplikace.

14


• Teradata - je relační databáze určená pro systémy Unix a Linux. Tato databáze je nasazována ve velkých datových skladech. Je oblíbena pro dobrý poměr mezi velikostí databáze a její efektivitou. Průměrná velikost databáze ukládaná do tohoto úložiště je okolo 120PB. Tabulka 2.1 ukazuje, jak dlouho jsou vyvíjeny jednotlivé produkty a kdo je jejich vlastníkem. Největšími nováčky v této oblasti jsou databáze Firebird a SQLite. Jejich prvotní verze byly vydány kolem roku 2000. Naopak nejdéle vyvíjenými databázemi jsou ORACLE a DB2, což se odráží i na jejich možnostech, funkcionalitě i ceně. Jméno

Vlastník

Vydání první verze

Poslední stabilní verze

DB2

IBM

1982

9.7

Firebird

Firebird project

2000

2.1.3

Informix Dynamic Server

IBM

1985

11.50.xC6

Microsoft Access

Microsoft

1992

12

Microsoft

1989

10

Sun Microsystems

1996

5.1.42

Oracle Corporation

1979

11g

1989

8.4.2

BSD4

2000

3.6.22

1984

V12

PD5 Vlastní licence

Microsoft SQL Server MySQL ORACLE

SQLite

PostgreSQL Global Development Group D. Richard Hipp

Teradata

Teradata

PostgreSQL

Licence Vlastní licence IPL1 a IDPL2 Vlastní licence Vlastní licence Vlastní licence GPL3 Vlastní licence

1

IPL - InterBase Public License IDPL - Initial Developer’s Public License 3 GPL - GNU General Public License 4 BSD - Berkeley Software Distribution 5 PD - Public domain 2

Tabulka 2.1: Základní informace o konkurenčních databázích Tabulka 2.2 porovnává, které nejpoužívanější operační systémy databáze podporují. Jednoznačnými vítězi jsou v tomto srovnání databáze MySQL a SQLite, které podporují všechny běžně rozšířené systémy. Ostatní databáze většinou nepodporují pouze Symbian. To je v celku pochopitelné. Dost dobře si nedokážu představit, z jakého rozumného důvodu by se na systému pro mobilní zařízení měl instalovat např. ORACLE nebo DB2. Naopak produkty firmy Microsoft silně zaostávají v podpoře všech systémů mimo Windows. Jasně je v tom vidět produktová politika firmy podporující bez výjimky pouze vlastní produkty. V tabulce 2.3 jsou systémy porovnávány podle několika základních vlastností. Hodnoceno je, zda databáze vyhovují konceptu ACID(atomicity, consistency, isolation,

2.5 Srovnání MySQL s dalšími databázovými stroji

Jméno

Windows

DB2 Firebird Informix Dynamic Server Microsoft Access Microsoft SQL Server MySQL ORACLE PostgreSQL SQLite Teradata

ano ano

Mac OS X ne ano

ano

15

Linux

BSD

UNIX

Symbian

ano ano

ne ano

ano ano

ne ne

ano

ano

ano

ano

ne

ano

ne

ne

ne

ne

ne

ano

ne

ne

ne

ne

ne

ano ano ano ano ano

ano ano ano ano ne

ano ano ano ano ano

ano ne ano ano ne

ano ano ano ano ano

ano ne ne ano ne

Tabulka 2.2: Srovnání podpory operačních systémů durability; viz. 3.3 Pravidla ACID ), zda podporují referenční integritu, transakce, Unicode a přes jaké rozhraní je možno s databází komunikovat. Mimo Microsoft Access podporují ostatní databáze všechny vyjmenované vlastnosti. Drobně se pouze liší v tom, zda je možno k databázi přistupovat i přes grafické rozhraní nebo jen přes interpreta SQL. Jméno

ACID

DB2 Firebird Informix Dynamic Server Microsoft Access Microsoft SQL Server MySQL ORACLE PostgreSQL SQLite Teradata

ano ano

Referenční integrita ano ano

ano ano

Podpora Unicode ano ano

ano

ano

ano

ano

ne

ne

ano

ano

ano

ano

ano

ano

ano

ano

ano

ano ano ano ano ano

ano ano ano ano ano

ano ano ano ano ano

částečně ano ano ano ano

ne ano ne ne ne

Transakce

GUI ano ne

Tabulka 2.3: Porovnání základních vlastností Každý systém má své limity, ani databáze nejsou výjimkou. Tabulka 2.4 srovnává systémy podle toho, jaký největší ucelený balík dat jsou schopny uchovávat v jedné databázi, tabulce a řádku. V tomto porovnání dle mého názoru vítězí systém Teradata. Nemá omezenou velikost databáze ani tabulek a maximální velikostí řádku daleko převyšuje konkurenci. Potvrzuje to, že je především určen pro velké datové sklady, jak již bylo zmíněno výše. Na poslední místo bych opět umístil systém Access, který podporuje pouze databáze a tabulky o velikosti 2 GB a zaostává tím i za odlehčeným systémem SQLite.

16


Jméno DB2 Firebird Informix Dynamic Server Microsoft Access Microsoft SQL Server MySQL 5 ORACLE PostgreSQL SQLite Teradata

Max. velikost databáze 512 TB Neomezeno

Max. velikost tabulky 512 TB 32 TB

Max. velikost řádku 32 MB 65 MB

128 PB

128 PB

32 MB

2 GB

2 GB

16 MB

524 PB

524 PB

Neomezeno

Neomezeno Neomezeno Neomezeno 32 TB Neomezeno

256 TB MyISAM 4 GB * velikost bloku 32 TB ? Neomezeno

4 GB MyISAM 2 GB 1.6 TB ? 64 GB

1

GB - Giga Byte = 109 Bytů TB - Tera Byte = 1012 Bytů 3 PB - Peta Byte = 1015 Bytů 2

Tabulka 2.4: Srovnání limitů databází Poslední tabulka 2.5 porovnává systémy podle toho, zda podporují nějaké funkce aplikační logiky. Není žádným překvapením, že všechny vyspělé systémy jako ORACLE, DB2 nebo PostgreSQL podporují všechny zmiňované funkcionality. Drobný nedostatek vidím v tom, že MySQL nepodporuje doménovou integritu. Externími rutinami označujeme, zda je systém schopen vyvolat nějaký další spustitelný kód napsaný například v C++ nebo v Javě. Jméno DB2 Firebird Informix Dynamic Server Microsoft Access Microsoft SQL Server MySQL ORACLE PostgreSQL SQLite Teradata

Doménová integrita ano ano

ano ano

Funkce a Procedury ano ano

Externí rutiny ano ano

ano

ano

ano

ano

ano

ne

ne

ne

ano

ano

ano

ano

ano

ano

ne ano ano ne ne

ano ano ano ne ano

ano ano ano ano ano

ano ano ano ne ano

ano ano ano ano ano

Kurzory

Triggery

ano ano

ano

Tabulka 2.5: Porovnání funkcionalit

Kapitola

3

Transakce v MySQL

Tato část práce popisuje problematiku transakcí. Ukazuje na názorných příkladech jejich použití a uvádí jakým způsobem se v MySQL transakce spouští a řídí.

3.1

Co jsou transakce?

Transakce zabezpečují a zefektivňují operace nad databází. Transakce je skupina příkazů uzavřených mezi klíčová slova BEGIN nebo START TRANSACTION 1 a COMMIT. Tato skupina je nadále považována za nedělitelný celek. Pokud se korektně neprovede některý z dotazů v transakci, všechna data upravená předešlými dotazy v transakci jsou vrácena na stav před transakcí. Nemůže se tedy stát, pokud např. selže spojení se serverem, vypadne elektřina nebo selže počítač, že některá z transakcí nebude dokončena celá. Transakce nám také zaručují, že data nebudou modifikována dvěma uživateli zároveň. V neposlední řadě zjednodušují programování složitějších aplikací závislých na korektním provádění dotazů, protože transakce může být přerušena a vrácena do výchozího stavu v jakémkoliv bodě provádění. To přináší mnohem jednodušší obsluhu běhových chyb.

3.2

Příklad využití transakcí

Předpokládejme, že databáze slouží například k evidenci stavu bankovní účtů. Každý účet je jednoznačně identifikován accountid. Jak by mohl vypadat kód pro převod peněz z účtu na účet je ukázáno níže. UPDATE table SET value=value-100 WHERE accountid=123 UPDATE table SET value=value+100 WHERE accountid=456 1

START TRANSACTION - je zápis kompatibilní se standardem SQL-99, v praxi se často transakce uvozují buď slovem BEGIN nebo BEGIN WORK a to kvůli kompatibilitě s různými databázemi. Významový rozdíl mezi těmito zápisy není.

18

Transakce v MySQL

Pokud bychom pracovali v systému bez transakcí a nastala by nějaká neočekávaná chyba, mohlo by se například stát, že z účtu 123 budou odebrány peníze, ale už nebudou přičteny na účet 456. Při použití transakcí se těmto situacím dá úspěšně předcházet. Korektní zápis výše uvedené bankovní operace by měl vypadat takto: START TRANSACTION UPDATE table SET value=value-100 WHERE accountid=123 UPDATE table SET value=value+100 WHERE accountid=456 COMMIT

Takto zapsaná operace je již naprosto korektní. Pokud by nastala chyba během provádění těchto dvou dotazů, budou stavy obou dvou účtů vráceny do výchozího stavu před transakcí.

3.3

Pravidla ACID

Zkratka ACID byla poprvé použita v roce 1983 v díle Principles of TransactionOriented Database Recovery autorů Andrease Reutera2 a Theo Haerdera3 . Je složena ze slov Atomicity, Consistency, Isolation, Durability. V teorii databází jsou ACID pravidla považována za základní pilíře toho, aby mohlo k systému bezpečně přistupovat mnoho uživatelů zároveň. ACID pravidla zaručují korektnost a spolehlivost provádění transakcí, proto je zařazuji do této kapitoly. Databázový systém MySQL odpovídá ACID požadavkům, pracujeme-li s tabulkami typu InnoDB. • Atomicity (Atomičnost) - Znamená, že databázový systém bere jednotlivé operace obsažené v transakci, jako jediný celek. Příkazy jsou buď provedeny všechny nebo žádný z nich. Transakce jsou nedělitelné. Při výskytu vnější chyby, může proces obnovení dokončit jakoukoliv probíhající transakci, ale je také přijatelné, aby byly takové transakce zcela zrušeny. • Consistency (Konzistence) - Operace převádějí databázi z jednoho platného stavu do jiného platného stavu a neexistují žádné mezistavy, v nichž by nebyla databáze konzistentní. Kromě toho by měla databáze zakázat operace, které porušují omezení týkající se konzistence. Uchováváme-li například ve své databázi údaje o bankovních účtech, které mají určitou vazbu ke klientům banky, nelze vytvořit účet pro neexistujícího klienta nebo odstranit klienta z tabulky klientů, dokud jsou v tabulce účtů nějaké účty, jež se na něj odkazují. • Isolation (Izolace) - Mnoho transakcí může být prováděno paralelně bez toho, aniž by se vzájemně ovlivňovaly. Pokud transakce vloží, změní nebo smaže nějaká data, transakce běžící paralelně tuto změnu nevidí. 2 3

Andreas Reuter - zaměstnanec IBM Research Laboratory Theo Haerder - profesorem na universitě v Kaiserslautern

3.4 Řízení transakcí

19

• Durability (Trvanlivost) - Data vyprodukovaná bezchybně provedenou transakcí jsou natrvalo uložena do databáze. Dále si databáze vede záznamy o tom, jaké transakce nebyly dokončeny a jaká data změnila. Když z nějakého důvodu server selže během provádění transakce, po restartu se opět databáze nastaví do konzistentního stavu. Pokud v záznamech najde nějaké transakce, které byly úspěšně ukončeny, ale nebyl na nich vyvolán COMMIT, jsou prohlášeny za korektní a změny jimi provedené jsou uloženy.

3.4

Řízení transakcí

3.4.1

Spouštění transakcí

Ve výchozím nastavení je v MySQL aktivován režim auto commit. Každý jednotlivý dotaz je spouštěn jako jedna malá transakce. Existují dva způsoby, jak v MySQL spouštět množinu dotazů jako transakci: • Jak již bylo zmíněno výše, transakci lze započít klíčovými slovy START TRANSACTION nebo BEGIN, BEGIN WORK a ukončujeme ji COMMIT nebo přerušujeme ROLLBACK • Režim auto commit můžeme vypnout. Následně pak všechny prováděné dotazy budou považovány za jednu velkou transakci. Tu opět můžeme potvrdit příkazem COMMIT a přerušit příkazem ROLLBACK. Nevýhodou tohoto způsobu je, že pokud nestačíme potvrdit transakci a dojde k selhání serveru, přijdeme většinou o velký balík neuložených dat. Poznámka: V úložišti InnoDB nelze provádět vložené transakce. Pokud vytvoříte novou transakci a předchozí je ještě nedokončena, bude následně explicitně ukončena příkazem COMMIT a předešlé změny uloženy.

3.4.2

Body obnovy

Od MySQL verze 4.0.14 podporuje InnoDB body obnovení. To nám dovoluje vytvořit v transakci body obnovy. Následně pak můžeme s takto označenou transakcí pracovat po částech. Bod obnovy vytvoříme příkazem SAVEPOINT jméno bodu. Pokud se chceme vrátit do určitého stavu v transakci označeném bodem obnovy, vyvoláme příkaz ROLLBACK TO SAVEPOINT jméno bodu. Tento příkaz ukončí provádění transakce a všechna data vytvořená nad bodem obnovy jsou prohlášena za platná a uložena, data pod bodem obnovy jsou vrácena do stavu před vykonáváním transakce. Body obnovy mohou být využívány pouze uvnitř transakcí. Po dokončení transakce jsou všechny body v ní obsažené smazány.

20

3.4.3

Transakce v MySQL

Automatické ukončování transakcí

Transakce jsou v MySQL implicitně ukončovány následujícími příkazy: ALTER TABLE, CREATE INDEX, CREATE TABLE, DROP DATABASE, DROP TABLE, LOCK TABLES, RENAME TABLE, SET AUTOCOMMIT = 1, TRUNCATE, UNLOCK TABLES . Vyvolání některého z těchto příkazů je ekvivalentní vyvolání příkazu COMMIT.

3.4.4

Spouštění transakcí mimo interpreta MySQL

Většina API a knihoven pro programování aplikací využívajících MySQL (například JDBC , ODBC, ADO, ADO.NET) , poskytuje speciální funkce a metody jak začínat a ukončovat transakce. Pokud však z nějakého důvodu nejsou funkční nebo nejsou implementovány, lze explicitně vyvolat již popisované příkazy START TRANSACTION, BEGIN, COMMIT, ROLLBACK nebo SET AUTOCOMMIT .

Kapitola

4

Typy úložišť (tabulek) v MySQL

Nyní se budeme věnovat popisu různorodých úložných systémů, které MySQL oficiálně podporuje. Shrnu jejich základní vlastnosti, strukturu a uvedu v jakých typických případech se používají.

4.1

Modulární systém úložných systémů

Od verze 3.23 je součástí MySQL univerzální rozhraní, které umožňuje využívání mnoha různých mechanismů ukládání dat. Toto rozhraní také umožňuje programátorům snadnější implementaci nových úložných systémů do MySQL. Úložný systém je speciální rozhraní, které poskytuje své služby dalším vrstvám serveru. Jeho hlavní úkoly jsou spolupráce s OS, dohled nad fyzickými daty a manipulace s nimi. Při vytváření tabulek si můžeme vybrat, jaký úložný systém se pro danou tabulku použije. Většina lidí, kteří i několik let pracují s MySQL, netuší, že existuje mnoho způsobů, jak se bude tabulka ukládat. To je způsobeno tím, že pokud uživatel explicitně neuvede, jaký typ tabulky (jaký úložný systém) chce použít, vytvoří se automaticky tabulka typu MyISAM. Oficiálně podporované úložné systémy jsou MyISAM, InnoDB, Memory (Heap), Merge, Archive, Federated,CSV, Blackhole, jejich vlastnosti popíši v dalších kapitolách. Mimo oficiálních, existuje i mnoho dalších neoficiálně podporovaných úložišť, například: PrimeBase XT (PBXT), RitmarkFS, atd. Schéma MySQL serveru s modulárním úložným systémem ukazuje obrázek 4.1. Příklad definice tabulky používající jiný než výchozí úložný systém:

CREATE TABLE t (i INT) ENGINE = INNODB;

22


Obrázek 4.1: Modulární systém uložišť v MySQL

4.2 4.2.1

MyISAM Typy MyISAM tabulek a jejich vlastnosti

Tabulky typu MyISAM rozdělujeme na dynamické, statické a komprimované. V závislosti na definici sloupců bude tabulka automaticky dynamická nebo statická. Pokud se v definici sloupců objevují typy jako varchar, text, blob, jedná se o dynamické typy, jejichž velikost není dopředu známa, tudíž se vytvoří dynamická tabulka. Pokud se v definici tabulky vyskytují pouze základní datové typy, jako int, char, vytvoří se statická tabulka. Statická tabulka má celou řadu výhod. Vyhledávání ve statické tabulce je rychlejší než v dynamické nebo komprimované tabulce. Pro databázi je velice snadné vybrat na základě indexu konkrétní záznam, jestliže každý záznam má konkrétní posun od začátku souboru. Statické tabulky se snadno ukládají do cache. Závažné poškození není v případě zhroucení tak pravděpodobné, protože obvykle lze obnovit řádky mimo poškozeného. Nevýhodou statických tabulek je, že ve většině případů plýtvají diskovým prostorem. Minimum záznamů naplno využije maximální velikost daného sloupce. Nevyplněné atributy zabírají plný nastavený rozsah. Práce s dynamickými tabulkami je pro MySQL mnohem náročnější. Ukládání záznamů do cache, hledání a oprava záznamů je mnohem komplikovanější než u statických tabulek. Je to způsobeno proměnlivou velikostí dynamických tabulek a postupnou fragmentací dat. Jestliže modifikujeme řádek a ten se následně zvětší, část jeho

4.2 MyISAM

23

dat zůstane v původním umístění a část se uloží jako nový fragment kdekoliv v souboru. Proto není zaručeno, že právě načtený segment souboru v cache bude obsahovat všechny části řádku. Poškozené segmenty se komplikovaně opravují, protože pokud se fragmenty nebo propojení ztratí, není následně zřejmé, k jakému řádku určitá oblast patří. Komprimované tabulky se nevytváří automaticky. Pro komprimaci tabulky použijeme nástroj myisamchk. I když komprimace může vypadat jako prospěšná věc, opak může být pravdou. Komprimované tabulky totiž nelze upravovat, pouze číst. Potřebujeme-li tabulku upravit, aktualizovat nebo do ní vložit data, musíme ji nejdříve celou dekomprimovat a následně je možné provést potřebné změny a znovu ji zkomprimovat.

4.2.2

Vlastnosti

Tabulky typu MyISAM jsou velice oblíbené díky rychlosti vyhledávání a jednoduchosti. Přenos dat z jednoho počítače na druhý není nijak komplikovaný, stačí pouze zkopírovat níže popsané soubory a přenést je na nějakém médiu na jiný počítač. Velmi užitečná je také podpora full-textového vyhledávaní. MyISAM je v MySQL nastaven jako výchozí úložný systém pro všechny nově vytvářené tabulky. MyISAM je netransakční úložný systém bez podpory cizích klíčů s uzamykáním na úrovni tabulek. Proto se tyto tabulky nehodí všude tam, kde je zapotřebí zabezpečit provádění úprav v databázi a zotavení tabulek po pádu serveru nebo tam, kde k dané tabulce přistupuje velké množství uživatelů zároveň.

4.2.3

Fyzická struktura tabulek

Každá tabulka typu MyISAM je na disku reprezentována třemi soubory. Tyto soubory nesou stejné jméno jako tabulka a liší se pouze příponou rozlišující typ souboru. V souboru .frm je uložena definice tabulky, v souboru .MYD jsou uložena data a konečně v souboru .MYI jsou uloženy indexy nad danou tabulkou. Maximální kost

veli-

256TB

Transakce

MVCC

ne

Podpora geografických dat

B-tree indexy

ano

Hash indexy

Cluster indexy

ne

Datová cache

Komprese dat

ano

Šifrovaní dat

Podpora kace

ano

Podpora klíčů

repli-

Cache dotazů

ano

Úroveň zamykání Indexování geoano grafických dat Full-textové ne indexy ne Cache indexů Podpora clusano teru Zálohování ne (point-in-time recovery) Historie změn ne

cizích

Tabulka 4.1: Shrnutí vlastností tabulek typu MyISAM

Tabulka ano ano ano ne ano ano

24


4.3 4.3.1

InnoDB Vlastnosti

InnoDB je transakčně zabezpečený úložný systém poskytující podporu zálohování v případě selhání serveru nebo připojení. Uzamykání je v tomto systému implementováno na úrovni řádků. To spolu s konzistentním neuzamčeným čtením v dotazech SELECT vylepšuje výkonnost systému v zátěžových aplikacích vyžadujících obsloužení velkého množství uživatelů zároveň. V InnoDB tabulkách je možné implementovat podporu datové integrity v podobě využívání cizích klíčů. Pro redukci I/O operací při vykonávání základních dotazů založených na primárních klíčích, využívá InnoDB cluster indexy. Tabulky typu InnoDB jsou produktem samostatné společnosti InnoBase Oy, ale i tak jsou dostupné pod stejnou smlouvou o duálním licencování jako MySQL. Celá řada velkých webových portálů založených na MySQL, např Slashdot, Google nebo Yahoo!, používá mechanismus ukládání InnoDB. Obzvláště se hodí pro rychlou manipulaci s velkými objemy dat v transakčně zabezpečených prostředích. Mechanismus ukládání InnoDB patří mezi nejrychlejší transakční systémy na světě, ale podpora transakcí není zadarmo, musíme zaplatit rychlostí. Ve většině případů budou tabulky MyISAM rychlejší, nicméně obecně nebude rozdíl nijak výrazný. Velkou nevýhodou InnoDB tabulek je chybějící podpora fulltextového vyhledávání.

4.3.2


Úložný systém InnoDB ukládá data a indexy do takzvaného tablespace zahrnujícího jeden či více souborů, které tvoří jakýsi druh virtuálního souborového systému. Tablespace soubory nikdy nezmenšují svoji velikost, pouze rostou. Není také možné, aby se uložená data dala přenášet pouhým kopírováním souborů jako tomu je u MyISAM tabulek. K těmto účelům se u tabulek InnoDB používá výhradně příkaz mysqldump. Maximální kost

veli-

64TB

Transakce

MVCC

ano


B-tree indexy

ano

Hash indexy

Cluster indexy

ano

Datová cache

Komprese dat

ano

Šifrovaní dat

Podpora kace

ano

Podpora klíčů

repli-

Cache dotazů

ano

Úroveň zamykání Indexování geoano grafických dat Full-textové ne indexy ano Cache indexů Podpora clusano teru Zálohování ano (point-in-time recovery) Historie změn ano

cizích

Tabulka 4.2: Shrnutí vlastností tabulek typu InnoDB

Řádek ne ne ano ne ano ano

4.4 Memory (Heap)

4.4 4.4.1

25

Memory (Heap) Vlastnosti

Heap tabulky jsou mimořádně rychlé tabulky, které jsou celé ukládány do operační paměti. Používají asociativní (Hash) a B-tree indexy, těm vděčí za svoji rychlost. Tabulky Heap jsou primárně určeny pro ukládání dočasných dat. Což je potřeba například při vykonávání složitějších dotazů nebo při vykonávání procedur. Není vhodné do nich ukládat velké množství dat. V praxi se často v definici tabulek určuje maximální počet řádků tabulky, a to následujícím způsobem: CREATE TABLE temptable( id INT NOT NULL PRIMARY KEY, data char(10) ) ENGINE=memory max_rows=100; Maximální velikost Heap tabulek je limitována systémovou proměnnou max heap table size. Ve výchozím nastavení je velikost tabulek omezena na 16MB. Velikost tabulek se explicitně omezuje, aby se předešlo situaci, kdy by byla vyčerpána celá operační paměť. V porovnání s ostatními, mají tyto tabulky celou řadu omezení. Datové typy TEXT, BLOB, VARCHAR nelze používat. Jednotlivé záznamy lze prohledávat pouze pomocí operátorů = a <=>. Ostatní operátory <, >, <= a >= nelze použít. Indexy mohou být vytvořeny pouze nad sloupci definovanými jako NOT NULL. Automatická inkrementace položek není podporována.

4.4.2


Jak již bylo řečeno, tabulky typu Heap jsou ukládány do operační paměti. Z toho plyne, že při vypnutí počítače přijdeme o všechna data uložená v tabulce. Tabulka samotná však existuje dále. Její definice je uložena na pevném disku v souboru .frm. Pokaždé, když se server restartuje, bude tabulka připravena k použití ale bohužel prázdná.

4.5 4.5.1

Merge Vlastnosti

Tabulka typu Merge je soubor identických MyISAM tabulek, ke kterým je možno přistupovat jako k jediné fyzické tabulce. Tabulky jsou identické ve smyslu, že definice jejich sloupců a indexů je shodná. Nemůžeme spojit MyISAM tabulky, které mají rozdílné pořadí sloupců, nemají přesně stejný počet sloupců nebo nemají nastaveny indexy ve stejném pořadí. Jakákoliv zdrojová MyISAM tabulka může být komprimována. Pokud máte příslušná práva, můžete provádět všechny běžné dotazy typu

26


Maximální kost

veli-

MVCC

Velikost Transakce RAM Podpora geograne fických dat

B-tree indexy

ano

Hash indexy

Cluster indexy

ne

Datová cache

Komprese dat

ne

Šifrovaní dat

Podpora kace

ano

Podpora klíčů

repli-

Cache dotazů

cizích

ano

Úroveň zamykání Indexování geone grafických dat Full-textové ano indexy ne Cache indexů Podpora clusano teru Zálohování ne (point-in-time recovery) Historie změn ne

Tabulka ne ne ne ne ano ano

Tabulka 4.3: Shrnutí vlastností tabulek typu Memory(Heap) SELECT, DELETE, UPDATE a INSERT tak, jako v případě jednoduché MyISAM tabulky. U Merge tabulek se objevují menší problémy s přístupovými právy. Pokud má uživatel přístup k MyISAM tabulce t, může vytvořit Merge tabulku m, která bude využívat tabulku t. Jestliže budou uživateli odebrána přístupová práva k tabulce t, nemůže měnit tabulku t, ale stále má dovolenu editaci tabulky m, jež využívá data z tabulky t. Tudíž může tabulku t touto nepřímou cestou editovat i po odebrání přístupových práv. Tento problém se standardně řeší smazáním tabulky typu Merge a jejím opětovným vytvořením. Toto řešení je však dosti neefektivní. Pokud bychom například vedli velkou databázi uživatelů, jejichž práva se často mění, museli bychom při každé změně práv znovu vytvářet danou tabulku. Jiné řešení tohoto problému zatím není. Ani oficiální zdroje neuvádí efektivnější řešení a doporučují použít výše popsaný postup.

4.5.2


Tabulky Merge jsou uloženy na disku ve dvou souborech. Soubory se jmenují stejně jako tabulka a liší se pouze příponou. V souboru .FRM je uložena definice tabulky a soubor .MRG obsahuje jména MyISAM tabulek, která jsou zdrojem této tabulky a která se mají tvářit jako jeden celek. Merge tabulka nemusí být umístěna ve stejné databázi jako její zdrojové tabulky.

4.5.3

Příklad práce s Merge tabulkou

4.5.3.1

Vytvoření Merge tabulky

CREATE TABLE t1 ( a INT NOT NULL AUTO_INCREMENT PRIMARY KEY, message CHAR(20) ) ENGINE=MyISAM;

4.6 Archive

27

CREATE TABLE t2 ( a INT NOT NULL AUTO_INCREMENT PRIMARY KEY, message CHAR(20) ) ENGINE=MyISAM; INSERT INTO t1 (message) VALUES (’Testing’),(’table’),(’t1’); INSERT INTO t2 (message) VALUES (’Testing’),(’table’),(’t2’); CREATE TABLE total ( a INT NOT NULL AUTO_INCREMENT, message CHAR(20), INDEX(a) ) ENGINE=MERGE UNION=(t1,t2) INSERT_METHOD=LAST;

Uvedený dotaz vytvoří 2 identické tabulky odlišující se pouze v jménu. V nich je definován primární klíč a a atribut message. Následně do každé z nich vložím množinu testovacích dat. Po vložení dat vytváříme Merge tabulku. Všechny atributy Merge tabulky mají shodné vlastnosti jako v MyISAM tabulkách. Výsledná tabulka je ”naplněna” daty ze zdrojových MyISAM tabulek. 4.5.3.2

Dotaz nad výslednou tabulkou

Po vytvoření výše popsané tabulky můžeme s vloženými MyISAM tabulkami pracovat jako s jednotným celkem. Příklad ukazuje, jak by vypadal výpis všech uložených dat z výsledné Merge tabulky. SELECT * FROM total; +---+---------+ | a | message | +---+---------+ | 1 | Testing | | 2 | table | | 3 | t1 | | 1 | Testing | | 2 | table | | 3 | t2 | +---+---------+

4.6 4.6.1

Archive Vlastnosti

Dalším z úložných systémů MySQL je systém Archive. Jeho největší odlišností od ostatních typů je, že do něj lze data pouze ukládat. Příkazy typu DELETE, REPLACE,

28


UPDATE nejsou podporovány. Nad tabulkou nelze definovat indexy. Tento úložný systém je netransakční s uzamykáním a komprimací na úrovni řádků. Maximální velikost tabulky není nijak omezena, proto se používá všude tam, kde je zapotřebí ukládat velké množství dat, která následně již nejsou editována. Výhodou Archive tabulek je systém komprimování řádků, který je zodpovědný za to, že databáze zabírá na disku mnohem menší místo, než kdyby stejná databáze používala například systém InnoDB nebo MyISAM. Systém používá ztrátovou kompresi k níž využívá knihovnu zlib. Dokumentaci a informace o této knihovně najdete na http://www.zlib.net/. Velkou nevýhodou Archive systému je jeho nevalný výkon při vyhledávání. Důvodem je komprese a absence cache řádků, která by urychlovala vyhledávání často hledaných položek. Při vykonávání příkazu SELECT je vždy bez výjimky procházena celá tabulka řádek po řádku. Vkládání řádků do tabulky probíhá mírně odlišným způsobem než u ostatních systémů. Vkládaný řádek je vložen do kompresního bufferu, po jeho úplném naplnění jsou všechny záznamy, jež obsahuje, zapsány na disk. Vkládání do kompresního bufferu je chráněno zámky.

4.6.2

Porovnání velikosti datových souborů

Nyní si uveďme malé srovnání velikostí datových souborů tabulek. Pro demonstraci velikosti souborů jsem si vytvořil 3 tabulky lišící se pouze používaným úložným systémem. Pro srovnání jsem vybral komprimovanou a nekomprimovanou tabulku MyISAM a tabulku InnoDB. V každé tabulce jsou uložena identická data a v každé z nich je 112050 řádků. V tabulce 4.4 je uvedeno základní srovnání velikostí souborů. I při stejných datech je velikost každého souboru značně odlišná. Na velikosti tabulky Archiv se viditelně podepisuje výkonný systém komprimace. Z těchto tří systémů je nejvíce náročný na úložný prostor systém InnoDB. Je to tím, že InnoDB podporuje různé operace zotavení databáze, které vyžadují ukládání metadat o provedených transakcích. Použitý úložný systém ARCHIVE MyISAM nekomprimovaná InnoDB

Velikost tabulky v MB 1.64 6.46 9.52

Počet řádků 112050 112050 112050

Tabulka 4.4: Porovnání velikosti datových souborů Archive s nekomprimovanou MyISAM tabulkou a Innodb tabulkou Druhá tabulka 4.5 ukazuje stejné tabulky, jen s tím rozdílem, že MyISAM tabulka byla zkomprimována. I po komprimaci je její datový soubor větší než soubor Archive tabulky. To dokazuje, že Archive úložný systém používá vysoce efektivní systém komprimace dat v tabulkách.

4.7 Federated

29

Použitý úložný systém ARCHIVE MyISAM komprimovaná InnoDB

Velikost tabulky v MB 1.64 2.08 9.52

Počet řádků 112050 112050 112050

Tabulka 4.5: Porovnání velikosti datových souborů Archive s komprimovanou MyISAM tabulkou a Innodb tabulkou

4.6.3


Tabulka je opět na disku reprezentována dvěma soubory. Soubor .FRM obsahuje definici tabulky a soubor .ARZ obsahuje data. Během některých operací se může ještě objevit soubor .ARN obsahující metadata tabulky. Maximální kost

veli-

Neomezeno

Transakce

MVCC

ne


B-tree indexy

ne

Hash indexy

Cluster indexy

ne

Datová cache

Komprese dat

ano

Šifrovaní dat

Podpora kace

ano

Podpora klíčů

repli-

ano

Cache dotazů

Úroveň zamykání Indexování geoano grafických dat Full-textové ne indexy ne Cache indexů Podpora clusano teru Zálohování ne (point-in-time recovery) Historie změn ne

cizích

Řádek ne ne ne ne ano ano

Tabulka 4.6: Shrnutí vlastností tabulek typu Archive

4.7

Federated

4.7.1

Vlastnosti

Tabulka tohoto typu se velice odlišuje od ostatních tabulek tím, že neobsahuje žádná lokální data, ale připojuje se k jinému MySQL serveru, ze kterého data získává. Veškeré SQL požadavky, posílané na tabulku typu Federated, jsou přesměrovávány prostřednictvím MySQL API na jiný server. Klient pak s touto tabulkou pracuje, jako kdyby byla uložena na lokálním serveru. Spojení lze zatím navázat pouze mezi MySQL servery, v některé z nových verzí MySQL by se měla objevit i podpora dalších systémů, zejména ORACLE a MS SQL serveru. Tabulky typu Federated nepodporují transakce, i když je cílová tabulka podporuje. Dále není možné měnit strukturu tabulky, ta totiž musí mít naprosto shodnou strukturu jako tabulka vzdálená. Tabulka typu Federated také nepoužívá žádnou lokální cache pro indexy ani dotazy, protože nemůže vědět, zda se něco v tabulce na druhém serveru změnilo či ne.

30


Obrázek 4.2: Schéma komunikace serverů při použití tabulky systému Federated

4.7.2


Na lokálním serveru je uchováván pouze soubor .FRM obsahující definici struktury tabulky. Datový soubor je uložen na vzdáleném serveru a nikdy se na lokální nereplikuje.

4.8 4.8.1

CSV Vlastnosti

Data z tabulek typu CSV jsou ukládána do textového souboru. Jednotlivé sloupce jsou odděleny uvozovkami nebo jinými speciálními znaky. CSV úložný systém použijeme v případě, kdy chceme jednoduše vyměňovat data mezi dalším software, který dokáže importovat a exportovat soubory CSV, nebo pokud chceme uložená data přenášet v jednoduché srozumitelné podobě.

4.8.2


Po vytvoření tabulky CSV najdeme na disku v patřičném adresáři tři soubory. Soubor .FRM opět obsahuje definici struktury tabulky. Do souboru .CSV se ukládají data v textové podobě. Tyto data je možno modifikovat v externím editoru i ručně. Musíme ale zachovat danou strukturu tabulky. Třetím souborem je soubor .CSM obsahující množinu metadat o tabulce.

4.8.3

Ukázka struktury CSV tabulky

Nyní ukáži jak může vypadat struktura datového souboru tabulky využívající úložný systém CVS. Nejprve vytvoříme tabulku typu CSV a vložíme do ní testovací data. To můžeme provést například následujícím způsobem:

4.9 Blackhole

31

CREATE TABLE test (i INT NOT NULL, c CHAR(10) NOT NULL ) ENGINE = CSV; INSERT INTO test VALUES(1,’record one’),(2,’record two’); Pokud v konzoli zadáme dotaz na vypsání všech položek v tabulce ukáže se nám takovýto výpis: SELECT * FROM test; +------+------------+ | i | c | +------+------------+ | 1 | record one | | 2 | record two | +------+------------+ Otevřeme-li datový soubor této tabulky v nějakém textovém editoru, zobrazí se nám následující text: "1","record one" "2","record two" Jednotlivé sloupce jsou zde odděleny čárkou. Každému záznamu přísluší právě jeden řádek.

4.9

Blackhole

4.9.1

Vlastnosti

Blackhole je velice zvláštní úložný systém, data která přijme neukládá. Pokud do databáze vložíte libovolný záznam, pouze vás upozorní, že tabulka byla aktualizována, ale pokud se pokusíte data zpět vybrat, neuspějete. Blackhole je transakční systém podporující celou množinu indexů definovatelných nad oficiálně podporovanými tabulkami. Následující řádky ukazují, jak se definuje Blackhole tabulka a její chování při vkládání záznamů a jejich vyhledávání. Při vložení je oznámeno, že byly vloženy dva záznamy, ale při zpětném vyhledání oněch záznamů, dostaneme pouze zprávu o tom, že je daná tabulka prázdná. mysql> CREATE TABLE test(i INT, c CHAR(10)) ENGINE = BLACKHOLE; Query OK, 0 rows affected (0.03 sec) mysql> INSERT INTO test VALUES(1,’record one’),(2,’record two’); Query OK, 2 rows affected (0.00 sec) Records: 2 Duplicates: 0 Warnings: 0 mysql> SELECT * FROM test; Empty set (0.00 sec)

32


4.9.2

Použití

Obrázek 4.3: Schéma použití úložného systému Blackhole

Obrázek 4.3 naznačuje nejčastější použití systému Blackhole. Vložíme-li záznam do Blackhole tabulky, žádná data nebudou fyzicky uložena na disk. Pokud má server aktivní binární protokolování1 , SQL požadavek je zaznamenán a reprodukován podřízeným serverům. Takovéto schéma se využívá ve vysoce vytěžovaných systémech, kde je zapotřebí redukovat zátěž Master serveru, spojenou s interpretací dotazů. Komunikace probíhá podle následujícího zjednodušeného principu: • Na Master server přijde požadavek na data, ten vyhodnotí přístupová práva k dané tabulce a přepošle požadavek podřízenému Blackhole serveru, kde je spuštěno binární protokolování. • Blackhole server vyhodnotí dotaz a zapíše ho do binárního protokolu. • Pokud Slave server zjistí, že byl změněn binární protokol, prověří jej a dotaz vykoná. Výsledná data jsou přeposlána Master serveru.

4.9.3


Pokud vytvoříte tabulku typu Blackhole na disku se pouze vytvoří soubor .FRM obsahující její definici. Žádný dodatečný soubor s daty či metadaty se nevytvoří. 1

Binární protokol nebo také binární protokol aktualizací obsahuje všechny SQL příkazy, které v minulosti změnily strukturu či data v databázi. Dále obsahuje informace o době vykonávání dotazu a časové značky. Příkazy se zaznamenávají v témže pořadí jako se vykonaly.

Kapitola

5

Optimalizace konfigurace serveru, databáze a dotazů

Tato kapitola popisuje základní optimalizační techniky, které může uživatel použít pokud chce zrychlit vykonávání spuštěných úloh.

5.1

Optimalizace konfigurace serveru

Způsobů, jak nainstalovat MySQL server, je mnoho. Pro začátečníky je nejvhodnější, když použijí nějakou formu automatické instalace. Mohou například využít RPM balíčků pod Linuxem nebo instalačního programu pod Windows. Takto nainstalovaný server je však nakonfigurován tak, aby spotřebovával minimum systémových prostředků. Je zřejmé, že se takováto konfigurace nehodí pro profesionální použití. Je tedy nutné zajistit důkladné nastavení serveru, tak aby byl jeho výkon optimalizován jak pro pro hardware, na kterém je server spuštěn, tak i pro pro databázi, která na něm bude umístěna.

5.1.1

Linkování a kompilace

Jedním ze způsobů optimalizace serveru, je kompilace zdrojových souborů přímo na počítači, na kterém bude spuštěn. Tímto způsobem lze dosáhnou nezanedbatelného zvýšení výkonu serveru. Společnost SUN tvrdí, že při použití správného a dobře nastaveného kompilátoru, lze výkon MySQL zvýšit o 10 - 30%. Dalšího zvýšení výkonu lze dosáhnout pokud pracujete pod systémem Linux a používáte procesory Intel. V takovéto situaci lze použít speciální kompilátor pgcc, který optimalizuje překlad kódu právě pro tyto procesory. Takto zkompilovaný software však není kompatibilní s procesory společnosti AMD. Pokud pro ně chceme server zkompilovat musíme využít standardní unixový kompilátor gcc. Binární soubory, které jsou volně k dispozici ke stažení, v sobě mají zakompilované velké množství znakových sad. Redukcí podporovaných znakových sad při kompilaci lze také dosáhnou menších úspor a optimalizace. Optimalizace lze také provádět s přihlédnutím na konkrétní hostitelský operační systém.

34


Problematika kompilace uživatelsky kompilovaného serveru je velice rozsáhlá. Nebudu jí proto dále rozvádět a odkazuji na manuál MySQL, který obsahuje mnoho doporučení, jak uživatelsky kompilovat tento software a detailně popisuje případné problémy spojené s touto činností.

5.1.2

Modifikace nejdůležitějších parametrů serveru

V rámci snahy o optimalizaci konfigurace můžeme také ladit parametry serveru. Všechny důležité parametry MySQL serveru lze nastavit pomocí příkazového řádku nebo pomocí konfiguračních souborů. V praxi jsou více používány konfigurační soubory, proto stručně popíšu jejich vlastnosti a použití. 5.1.2.1

Konfigurační soubory

Velkou výhodou konfiguračních souborů je umístění všech standardních voleb daného serveru na jednom místě. To se například hodí při správě více serverů. Editace konfiguračních souborů nevyžaduje žádné speciální nástroje, bohatě si vystačíte s běžným textovým editorem. Při psaní je jen nutné dodržet syntaktické konvence. Pro nastavení jednotlivých voleb existují tři tvary syntaxe: • Můžeme přímo uvést volbu, kterou má server aktivovat např.: log-bin Tento zápis má stejný účinek jako mysqld –log-bin a aktivuje binární protokolování. • Další způsobem je uvedení volby a hodnoty, například: innodb buffer pool size=70M. Tato volba nastaví velikost vyrovnávací paměti. • Třetí způsob je uvedení volby a hodnoty s využitím syntaxe set-variable, například: set-variable = innodb buffer pool size=70M Využívání třetího způsobu zápisu se nedoporučuje, uvádím ho jen pro úplnost, protože se často objevuje ve vzorových konfiguračních souborech a je tedy dobré vědět co znamená. Následující kód ukazuje, jak může vypadat konfigurační soubor pro MySQL. [mysqld] port = 3306 socket = /var/lib/mysql/mysql.sock skip-locking key_buffer_size = 16K max_allowed_packet = 1M table_open_cache = 4 sort_buffer_size = 64K read_buffer_size = 256K read_rnd_buffer_size = 256K net_buffer_length = 2K

5.1 Optimalizace konfigurace serveru

35

thread_stack = 128K [client] #password = your_password port = 3306 socket = /var/lib/mysql/mysql.sock Na prvním řádku souboru je uvedeno [mysql]. To určuje, že volby uvedené pod tímto řádkem jsou určeny pro mysqld. Návěští [client] nám udává, že následné volby budou určeny pro všechny klientské programy přistupující k serveru. Chceme-li definovat volby pro jednu specifickou aplikaci, musíme její jméno stanovit na počátku voleb. Stačí pouze uvést název programu v hranatých závorkách. Daná konfigurace se použije při pokusu aplikace o připojení. 5.1.2.2

Umístění konfiguračních souborů

Umístění konfiguračních souborů je v každém systému jiné. Ve Windows je možno konfigurační soubor umístit do adresáře Windows a nazvat jej my.ini, nebo do kořenového adresáře diskové jednotky, na které je server umístěn (např C:/ ). Takovýto soubor pak bude považován za globální, tzn. všechny jeho změny se projeví na všech běžících instancích serveru. Třetí možností je umístění konfiguračního souboru přímo do složky, kde je server nainstalován. V unixových systémech máme o něco více možností. Podporují konfigurační soubory jak pro samotný server, tak i pro jednotlivé uživatele. Globální konfigurační soubor je obvykle umístěn v souboru /etc/my.cnf. Serverové konfigurační soubory jsou umístěny v datovém adresáři každého serveru a uživatelské soubory v adresářích jednotlivých uživatelů. Uživatelské konfigurační soubory se liší tím, že jejich název začíná tečkou, např. .my.cnf. 5.1.2.3

Vzorové konfigurační soubory

V konfiguračních souborech se obvykle vyskytuje velké množství parametrů, což může být zpočátku trochu matoucí. Z tohoto důvodu jsou ve složce support-files nebo v /usr/share/mysql umístěny vzorové konfigurační soubory, které nám pomohou z počáteční konfigurací systému. V uvedených adresářích se nachází čtyři soubory myhuge.cnf,my-large.cnf,my-medium.cnf a my-small.cnf. • Huge je určen pro velké systémy s operační pamětí 1 - 2 GB, kde je výhradně obsluhováno MySQL. • Large je pro systémy výhradně určené pro běh MySQL, pro použití large konfiguračního souboru je nutné, aby byl počítač vybaven pamětí velikosti okolo 512MB. • Medium použijeme tam, kde máme k dispozici 32 - 64 MB operační paměti a kde běží hlavně MySQL nebo tam, kde máme k dispozici alespoň 128MB paměti a chceme aby MySQL běželo společně s dalšími programy např. web server, atd.

36


• Small používáme pro systémy s malou operační pamětí (<=64MB), kde je MySQL využíváno jen občas a kde je nutné aby mysql démon spotřebovával co nejméně systémových prostředků. Přesunutím nebo zkopírováním některého z uvedených souborů do patřičného adresáře lze poměrně snadno docílit jednoduché před-konfigurace daného systému. 5.1.2.4

Důležité konfigurační parametry MySQL serveru

Mezi důležité parametry, které můžeme serveru nastavit jak při spuštění, tak pomocí konfiguračních souborů, zařazuji následující volby: • ansi - Spustí server v režimu kompatibilním s ANSI standardem. Při použití této volby bude MySQL využívat ANSI-99 SQL. • basedir - Nastaví kořenový adresář serveru, pokud nechcete používat standardní umístění souborů. • datadir - Nastaví datový adresář, jestliže nechceme využívat výchozí umístění. • log-bin - Aktivuje binární protokolování, můžeme stanovit jméno a umístění výsledného souboru. • log-error - Zapne protokolování chyb. I v tomto případě můžeme stanovit umístění výsledného souboru. • log-slow-queries - Aktivuje protokolování pomalých dotazů. • port - Určí port, na kterém bude MySQL komunikovat. • user - Určuje uživatele, pod kterým by se měl server spustit.

5.1.3

Parametry důležité pro optimalizaci výkonu databáze.

Většina parametrů důležitých pro optimalizaci výkonu databáze do jisté míry souvisí s tím jak MySQL používá paměť. Systém je nutné nakonfigurovat tak, aby byla paměť efektivně přidělována jednotlivým úlohám. MySQL obsahuje interní vyrovnávací paměti (buffery) a cache paměti. Oběma typům lze nastavit, kolik operační paměti se každé z nich přidělí. Dva nejdůležitější parametry týkající se přidělovaní paměti jsou key buffer size a table cache. Tyto proměnné sdílí všechna vlákna běžící na serveru a mají na výkon serveru velký vliv. Key buffer představuje místo v operační paměti, kam se ukládají indexy tabulek MyISAM. Jakmile dojde k použití indexu, dojde i k jeho uložení do vyrovnávací paměti. Pokud je příslušný blok indexu ve vyrovnávací paměti, při provádění dotazů se načte přímo z ní. V opačném případě se blok daného indexu musí načíst přímo z disku. Obecně lze tedy říci, že čím větší key buffer tím lépe. Do úvahy nad tím, jakou velikost nastavit pro key buffer, bychom měli zahrnout velikost vaší operační paměti, velikost indexových dat a to, zda je systém vyhrazen

5.1 Optimalizace konfigurace serveru

37

pouze pro MySQL nebo na něm běží ještě další aplikace. Experti doporučují v případě dedikovaného serveru nastavit velikost key bufferu na 20 - 50 % celkové operační paměti. Pokud MySQL běží na serveru paralelně s dalšími aplikacemi, rozhodujeme se podle dalších kritérií. Máme-li například pouze 20MB indexových dat je evidentně zbytečné přidělovat 128MB paměti key bufferu. Key buffer má však vliv jen na tabulky typu MyISAM, nemá tedy smysl zvyšovat jeho hodnotu, pokud používáme tabulky InnoDB. V tomto případě potřebujeme upravovat parametr innodb buffer pool size. Ten definuje velikost společné vyrovnávací paměti (buffer pool ) tabulek InnoDB, kde se ukládají indexy a data tabulek. Dalším velice důležitým parametrem je table cache. Omezuje maximální počet současně otevřených tabulek. U MyISAM tabulek je každá tabulka a index samostatným souborem. otevírání a zavírání souborů je pomalé, proto soubory zůstávají otevřené. Uzavřou se až tehdy, pokud je to explicitně vyžádáno nebo pokud celkový počet otevřených tabulek překročí hodnotu table cache. Zvětšení table cache bude užitečné, pokud server obsahuje velké množství tabulek. Velikost je omezena maximálním počtem souborů, které může v daném systému otevřít jeden uživatel. Kromě výše zmíněných třech globálních parametrů existují v MySQL oblasti paměti dynamicky přidělované jednotlivým vláknům. Jejich velikost je stejná pro všechna vlákna, ale každému se přiděluje dané maximální množství paměti na konkrétní účel. Zástupci těchto pamětí jsou například vyrovnávací paměť pro čtení a řazení. Velikost vyrovnávací paměti pro čtení nastavíme pomocí parametru read buffer size. Tato paměť se použije pro ukládání dat při úplném prohledávání tabulky. Čím je vyrovnávací paměť větší, tím více se omezí čtení dat tabulky z disku. Pokud je tento parametr nastaven na příliš velkou hodnotu, mohou čtecí vyrovnávací paměti každého spuštěného vlákna spotřebovat obrovské množství paměti. Jak již název napovídá, vyrovnávací paměť pro řazení, nastavitelná parametrem sort buffer je určena pro provádění dotazů s ORDER BY klauzulí. Pokud často třídíte velké množství dat, je nutné nastavit tento parametr na větší hodnotu, nicméně i zde hrozí stejná rizika jako v předcházejícím případě.

5.1.4

Ostatní faktory ovlivňující výkon

Pokud nasazujeme MySQL na víceprocesorovém systému, jeho výkon nemalou měrou ovlivňuje i hostitelský operační systém. V tomto případě SUN doporučuje svůj systém Solaris. Ačkoliv MySQL je používáno na velkém množství operačních systémů, právě na tomto systému je prováděn vývoj a počáteční testování. Solaris je tedy nejoptimalizovanější platformou s minimem chyb. Zvýšení výkonu lze také dosáhnout uložením jednotlivých databází na různé disky. V rámci zlepšení výkonu čtení a zápisu lze využít diskové pole RAID 0, případně, potřebujeme-li velký výkon při čtení, můžeme použít RAID 1 nebo 5.

38


5.2

Optimalizace databáze

V předchozí části jsem popsal parametry ovlivňující výkon serveru. Nyní se budu krátce věnovat tomu, jak optimalizovat databázi a samotné tabulky.

5.2.1

Faktory ovlivňující výkon databáze

• Nedostatečné využívání indexů - častou příčinou slabého výkonu databáze je používání tabulek bez indexů nebo tabulek, které mají definovány indexy na sloupcích, které nejsou při vyhledávání často používány. • Nadbytečné využívání indexů - opačným případem je nadměrné používání indexů. Aktualizace indexů při vkládání nebo editaci dat vyžaduje určitý čas, který není zanedbatelný. Čím větší jsou indexová data, tím větší je režie na jejich zpracování. Indexy jsou přínosné při vyhledávání, ale ne při manipulaci s daty • Neefektivní nastavení práv - používáme-li z nějakého důvodu diferencování uživatelů na úrovni tabulek nebo sloupců, může se při častém dotazování databáze stát toto nastavení úzkým hrdlem systému. Při provádění každého dotazu jsou totiž kontrolována přístupová práva k dané tabulce a sloupci, to následně zpomaluje interpretaci dotazu. • Špatný návrh databáze - velmi častým důvodem malého výkonu je nesprávný návrh databáze. Často je to způsobeno špatným návrhem schématu databáze nebo výběrem nevhodných datových typů a jejich délky.

5.2.2

Doporučení pro návrh výkonné databáze

Při návrhu databáze můžeme udělat spoustu opatření, která pozitivně ovlivňují její výkon. Ty nejdůležitější z nich jsou: • Používáme nejmenší datové typy, do kterých se data bez problému vejdou. Takovéto opatření zmenšuje velikost řádků. Což usnadňuje prohledávání tabulek a ukládání jednotlivých záznamů do cache. • Tam, kde je to možné, používáme záznamy s pevnou délkou. Pokud tabulka obsahuje pouze datové typy pevné délky vyhledávaní a ukládání dat, je opět rychlejší, protože nedochází k tak velké vnitřní fragmentaci jako v případě použití dynamických datových typů. • Co nejvíce sloupců deklarujeme jako NOT NULL. Používáním prázdných hodnot se snižuje rychlost a zvětšují se nároky na diskový prostor. Pokud naše data logicky vyžadují prázdné hodnoty, pak je samozřejmě můžeme použít. Jejich výskyt by však měl být pokud možno minimální. • Nad často prohledávanými sloupci v tabulkách vytváříme indexy urychlující prohledávání v položkách tabulek.

5.2 Optimalizace databáze

39

• V některých specifických případech můžeme zvážit denormalizaci tabulek pro snížení počtu spojení, která vytváříme při jejich prohledávání. To se ovšem nedoporučuje, protože by to mohlo vést k nekonzistenci databáze.

5.2.3

Optimalizace výkonu pomocí indexů

Pokud se snažíme optimalizovat výkon databáze, měli bychom ověřit, zda jsou nad tabulkami v dostatečné míře používány indexy. To můžeme provést například příkazem DESCRIBE, který zjistí, jaké indexy jsou nad tabulkou definovány. Index je v podstatě vyhledávací tabulka, která nám umožňuje rychleji nalézt určité řádky v tabulce. Udává, kde v tabulce lze najít konkrétní řádek obsahující danou hodnotu. Takže lze rovnou vyhledat řádek s hledanou hodnotou bez nutnosti procházení celé tabulky. V MySQL jsou indexy uloženy ve formě B-stromů (binárních stromů). Indexovat lze jeden nebo více sloupců. Index se použije v případě spuštění dotazu, pokud je hledání prováděno: • V jednom sloupci s jednosloupcovým indexem, tzn. pokud například máme index nad sloupcem jmeno a prohledáváme tabulku příkazem SELECT ... FROM zamestnanci WHERE jmeno = ’Adam’. • V množině sloupců, která dohromady tvoří vícesloupcový index. Máme například tabulku zamestnanci.zakazky ve které jsme definovali indexy nad sloupci IDzakaznika,IDzamestnance a datumRealizece a provedli jsme například dotaz SELECT ... FROM zamestnanci.zakaznici WHERE Idzakaznika = z AND IDzamestnance = y AND datumRealizece= d. • Ve sloupci nebo množině sloupců, které tvoří podmnožinu vícesloupcového indexu, pokud jsou v něm zahrnuty všechny zleva uvedené sloupce. Máme-li například tabulku zamestnanci.zakazky se shodnou strukturou a indexy jako v předchozím případě, použijí se indexy v následujících případech: SELECT ... zamestnanci.zakazky WHERE IDzakaznika = z SELECT ... zamestnanci.zakazky WHERE IDzakaznika = z AND IDzamestnance = y Naopak se indexy nepoužijí v dotazu: SELECT ... zamestnanci.zakazky WHERE IDzamestnance = y AND datumRealizace=d

5.2.4

Interní nástroje pro optimalizaci

5.2.4.1

ANALYZE TABLE

Příkazem ANALYZE TABLE lze v tabulkách prozkoumávat a ukládat rozložení hodnot klíčů v tabulkách. Tyto informace jsou uchovávány uvnitř MySQL a na jejich základě se rozhodne, jak se budou provádět spojení.

40


5.2.4.2

OPTIMIZE TABLE

Dalším šikovným nástrojem je OPTIMIZE TABLE. Tento příkaz v podstatě dělá totéž co program na defragmentaci pevných disků, s tím rozdílem že defragmentuje data uložená v datových souborech tabulek. Použití tohoto nástroje se doporučuje při odstraňování nebo vkládání velkého množství dat do tabulky nebo při aktualizaci mnoha řádků z dynamickou délkou.

5.3

Optimalizace dotazů

MySQL nám umožňuje analyzovat jednotlivé dotazy a zjistit, jak dlouho se provádějí a jakým způsobem se přesně interpretují. Zjištěním těchto informací a následnou optimalizací provádění lze vylepšit výkon celé databáze.

5.3.1

Interní optimalizace dotazů

MySQL aplikuje na všechny spuštěné dotazy velkou řadu optimalizačních pravidel. K nalezení nejlepšího pořadí pro spojení tabulek využívá MySQL odhadovaný počet řádků v tabulce. Ten můžeme zobrazit pomocí příkazu EXPLAIN. Pokud se nám zdá navržený odhad nesprávným, můžeme si pořadí tabulek ručně vynutit příkazem STRAIGHT JOIN. Pro výběr indexu vyhledává MySQL záznam, který zahrnuje méně než 30% řádků v tabulce. Pokud takovýto záznam není nalezen, prochází se tabulka tak, jako kdyby nad ní indexy nebyly definovány. Výrazy v klauzulích WHERE se optimalizují tak, jako celá řada kompilátorů optimalizuje výrazy. Odstraňují se například nepotřebné závorky. Některé dotazy se provedou bez toho, aby se nějaká data načítala z tabulek, to se například stane pokud jsou všechna data uložena v indexovém souboru.

5.3.2

Testování dotazů

Testováním je zejména myšleno měření času vykonávání jednotlivých dotazů. Nejpřesnějších výsledků lze dosáhnout mnohonásobným prováděním testu a následným zprůměrováním dosažených výsledků. Pokud bychom test provedli pouze jednou, může výsledek ovlivňovat načítání a výsledky by mohly být značně zkreslené. Otestování rychlosti provedení libovolného výrazu či dotazu lze provést pomocí příkazu BENCHMARK(). Tato funkce přijímá dva parametry: kolikrát se má příkaz spustit a výraz, který chceme otestovat. Použití funkce benchmark může vypadat následovně: • SELECT BENCHMARK(9999999,999*0.1); - Takto můžeme testovat délku provádění výrazů, uvedený dotaz 9999999 krát vyhodnotí výraz 999*0.1.

5.3 Optimalizace dotazů

41

• SELECT BENCHMARK(9999999,’SELECT * FROM TEST’); - Tímto způsobem testujeme délku prováděná dotazů. Ukázka možného výstupu funkce BENCHMARK: +-----------------------------------------+ | benchmark(9999999,’SELECT * FROM TEST’) | +-----------------------------------------+ | 0 | +-----------------------------------------+ 1 row in set (0.16 sec) Funkce BENCHMARK vrací vždy hodnotu nula, jejím výstupem je (0.16 sec) udávající celkovou délku provádění všech dotazů.

5.3.3

Analýza provádění dotazů

Za účelem optimalizace je také dobré vědět, jakým způsobem je dotaz interpretován. K tomu slouží příkaz EXPLAIN. Výsledek dotazu EXPLAIN SELECT * FROM test; +----+-------------+-------+--------+---------------+------+---------+------+------+---------------------+ | id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra | +----+-------------+-------+--------+---------------+------+---------+------+------+---------------------+ | 1 | SIMPLE | test | system | NULL | NULL | NULL | NULL | 0 | const row not found | +----+-------------+-------+--------+---------------+------+---------+------+------+---------------------+ 1 row in set (0.05 sec)

Nyní vysvětlím význam jednotlivých položek v tabulce: • id - pořadové číslo, obsahuje-li dotaz poddotazy očísluje se každý zvlášť. • select type - udává typ příkazu. Pro nejjednodušší příkazy se použije hodnota SIMPLE. Pokud použijeme poddotazy, vnější bude označen jako PRIMARY a vnitřní dotazy se označí jako SUBSELECT nebo DEPENDENT. • table - udává zdrojovou tabulku dotazu • type - jeden z důležitých parametrů pro optimalizaci udává, jakým způsobem se tabulka bude spojovat s jinými tabulkami v dotazu • key - určuje jakých indexů bude během dotazu použito. Pokud tabulka nemá relevantní indexy bude hodnota sloupce NULL. • key len - udává délku indexu, který se během dotazu použije. • ref - hodnota porovnávaná s klíčem, na základě ní se provede rozhodnutí o výběru řádku. • rows - udává počet řádků tabulky, které budou načteny pro generování výsledku. • Extra - udává další doplňující informace, například o tom, zda výsledek byl celý generován z indexu bez načtení tabulky.

42

5.3.4


Protokolování pomalých dotazů

Protokolování pomalých dotazů je užitečné v případě, že chceme zjistit, jaké dotazy mají nadprůměrnou délku vykonávání oproti ostatním. Protokolování lze aktivovat pomocí volby –log-slow-queries = nazev protokolového souboru. Pokud současně zapneme volbu –log-long-format, budou se zapisovat i dotazy, které při své interpretaci nevyužijí indexů. Definici pomalého dotazu vytvoříte nastavením proměnné long query time. Ta udává spodní hranici doby provádění pomalých dotazů. Protokol pomalých dotazů lze číst v jakémkoliv textovém editoru, jedná se totiž o běžný textový soubor

Kapitola

6

Zálohování a obnovení dat po havárii

Čas od času se stává, že nějaká část počítače selže. U velmi vytěžovaných serverů to jsou převážně disková zařízení. Jestliže disk selže, s velkou pravděpodobností nebude možné číst data, která obsahuje. Takovéto situaci se snažíme předcházet zálohováním.

6.1

Zálohování a obnova

Pokud provozujeme databázový server, je v podstatě nutností zálohování všech dat uložených v databázi. Po poruše je možné pomocí interních nástrojů MySQL vyvolat obnovu dat ze zálohy. Jednotlivé nástroje MySQL pro zálohování a obnovu databáze jsou popsány níže.

6.1.1

Mysqldump

Velmi často se zálohování provádí pomocí skriptu mysqldump. Tento konzolový program se připojí k MySQL serveru a vytvoří textový soubor obsahující SQL příkazy potřebné k obnově celé databáze. Velkou výhodou skriptu mysqldump je jeho jednoduché použití řešící za nás uzamykání tabulek. Nevýhodu je, že při spuštění tohoto skriptu se na serveru uzamknou tabulky, které skript právě používá. Znemožní se tak na několik vteřin až minut přístup ostatním uživatelům. Pokud tedy pracujeme na serveru bez replikace, je lepší provádět zálohy v pozdních nočních hodinách, tím eliminujeme možné problémy s přihlášenými uživateli. Další velkou nevýhodou mysqldump je skutečnost, že skript během své práce využívá služby MySQL serveru. Provedení zálohy je tedy pomalejší než při využití mysqlhotcopy. Použití mysqldump může vypadat například takto: mysqldump -u username -p password nazev databaze >backup.sql Mysqldump nabízí celou řadu doplňujících řídících parametrů. Ty například určují umístění částí souboru ve vyrovnávací paměti, optimalizují vytváření souboru tak,

44


aby byla obnova ze zálohy co nejrychlejší nebo nařídí skriptu, aby zálohoval pouze strukturu databáze bez dat.

6.1.2

Mysqlhotcopy

Mysqlhotcopy se liší od mysqldump tím, že nepoužívá při práci připojení k MySQL serveru, ale kopíruje přímo obsah datových souborů databáze. Připojení k serveru je používáno pouze pro uzamknutí tabulek a jejich aktualizaci. Většina operací se provádí na úrovni souborového systému namísto použití dotazů na databázi, měl by tedy být rychlejší než mysqldump. Skript mysqlhotcopy se používá obdobně jako mysqldump: mysqlhotcopy -u username -p password nazev databaze umisteni zalohy Soubory vytvořené skriptem mysqlhotcopy, jsou kopie datových souborů databáze. Chceme-li obnovit data z těchto záloh, musíme zastavit server a nahradit datové soubory v datovém adresáři MySQL zálohovanými soubory.

6.1.3

Ruční záloha a obnova

Zálohování databáze můžeme také provést ručně. Proces ruční zálohy obnáší aktualizaci a zamknutí tabulek a následné zkopírování datových souborů na místo zálohy. Po celou dobu provádění této zálohy jsou uzamčeny používané tabulky, což není vhodné, pokud vytváříme zálohu na serveru s velkým počtem přístupů uživatelů k databázi. Tabulky můžeme zamknout například příkazem LOCK TABLES, za ním následují parametry v podobě jmen tabulek, které se mají uzamknout. Obecně stačí tabulky uzamknout pouze pro zápis. Jejich čtení během zálohy nám nevadí. Během ruční zálohy potřebuje mít otevřené spojení s MySQL serverem. Při přerušení nebo ukončení se zámky opět automaticky otevřou. Po uzamčení tabulek použijeme příkaz flush tables, který dodatečně uloží všechny nové nebo upravené záznamy nacházející se v table cache. Následně již můžeme libovolně překopírovat datové soubory a vytvořit tak zálohu databáze.

6.1.4

Zálohování pomocí BACKUP a RESTORE TABLE

Alternativou k předchozímu ručnímu postupu je využití SQL příkazů BACKUP TABLE a RESTORE TABLE, které lze použít pokud pracujeme s tabulkami typu MyISAM. Syntaxe příkazů je následující: BACKUP TABLE tabulka to ’adresar/se/zalohou’ RESTORE TABLE tabulka from ’adresar/se/zalohou’ Příkazy opět kopírují datové soubory jednotlivých databází do určitého adresáře. Před zálohováním se dané tabulky zamknou pro čtení. Příkaz RESTORE bude fungovat pouze pokud máme zálohované soubory odlišné od nahrazovaných. V opačném případě je nutné použít příkaz DROP TABLE a následně použít RESTORE.

6.2 Kontrola a oprava tabulek

6.1.5

45

Obnova z binárního protokolu

Při obnově dat ze zálohy se často stává, že jsou zálohovaná data neaktuální. Lze to napravit pomocí vyvolání změn z binárního protokolu, proto je tak důležitý. Seznam provedených operací můžeme z binárního protokolu extrahovat například pomocí příkazu: mysqlbinlog logfile >updates.sql Před zpětným vyvoláním dotazů z binárního protokolu je rozumné projít jednotlivé záznamy protokolu a ujistit se, zda v něm jsou jen dotazy, které potřebujeme. Zbytek můžeme odstranit.

6.2

Kontrola a oprava tabulek

Při havárii nebo výpadku proudu je dobré zkontrolovat stav jednotlivých tabulek a případně opravit jejich poškození. K tomu nám v MySQL poslouží hned několik nástrojů.

6.2.1

Příkazy CHECK a REPAIR

V případě, že v databázi používáme MyISAM, Archive nebo InnoDB tabulky můžeme kontrolu provést příkazem CHECK TABLE. Sytaxe příkazu: CHECK TABLE test; Výstup příkazu: +-----------+-------+----------+----------+ | Table | Op | Msg_type | Msg_text | +-----------+-------+----------+----------+ | test.test | check | status | OK | +-----------+-------+----------+----------+ Pokud vygenerovaná zpráva obsahuje Msg text OK nebo Table is already up to date, je vše v pořádku a není třeba tabulku opravovat. V případě, že se vygeneruje jakákoliv jiná zpráva, tabulky jsou poškozeny a je třeba provést opravu. Nejjednodušší opravu provedeme příkazem REPAIR TABLE. Sytaxe příkazu: REPAIR TABLE test; Výstup příkazu: +-----------+--------+----------+----------+ | Table | Op | Msg_type | Msg_text | +-----------+--------+----------+----------+ | test.test | repair | status | OK | +-----------+--------+----------+----------+ Pokud oprava proběhla úspěšně, opět dostaneme zprávu OK. Jestliže dostaneme jakoukoliv jinou zprávu, REPAIR TABLE si s opravou nedokáže poradit a je nutné nasadit robustnější skript myisamchk.

46

6.2.2


Myisamchk

Dalším nástrojem pro opravu tabulek je myisamchk, který je mnohem robustnější než předcházející příkazy a je určen pro tabulky typu MyISAM. Ke svému běhu nepotřebuje aktivní MySQL server, je to samostatný konzolový program. Spouštění myisamchk při zapnutém serveru se z bezpečnostních důvodů nedoporučuje. Pomocí tohoto nástroje lze opravit drtivou většinu chyb. Dokáže opravit jak řádky v tabulkách, tak i indexové soubory.

6.2.3

Mysqlcheck

Obdobou předcházejícího příkazu je mysqlcheck. Je určen pro tabulky MyISAM a InnoDB. Hlavním rozdílem od myisamchk je, že mysqlcheck můžeme bez obav spouštět i při zapnutém MySQL serveru.

Kapitola

7

JDBC, aplikační rozhraní pro přístup k relačním databázím v JAVĚ

JDBC (Java Database Connectivity) je základní rozhraní Javy pro přístup k relačním databázím. Základem JDBC jsou ovladače databází, které poskytují služby nadřazené aplikaci a překládají její volání na nativní funkce databáze. Díky tomu stačí znát jednotné rozhraní JDBC, které odstiňuje programátora od specifického API konkrétní databáze. Výrobci jednotlivých databázových systémů sami začali ovladače pro JDBC vyvíjet a optimalizovat. Díky tomu je v dnešní době pro Javu k dispozici celá řada ovladačů. Z historického pohledu byl JDBC inspirováno ODBC standardem navrženým firmou Microsoft. To bylo založené na X/Open CLI a bylo především určeno pro C/C++ aplikace. ODBC je čistě C API, které nemá žádný objektový základ a je tedy poměrně nepřehledné a nestrukturované. I z těchto důvodů bylo postupem času od této technologie upuštěno a v technologii .NET je již komunikace s databázemi vyřešena jiným, efektivnějším způsobem.

7.1

Architektura JDBC

Architektura JDBC se skládá ze dvou hlavních vrstev: 1. Aplikační vrstva - zprostředkovávající interakci mezi vlastní aplikací a JDBC driver managerem. Využívá služeb driver manageru a specifických ovladačů databází za účelem poskytnutí přímého připojení k různorodým databázím v Java aplikacích. 2. Vrstva ovladačů - obsluhuje komunikaci mezi JDBC driver managerem a vlastním ovladačem databáze. Driver manager spravuje dostupné ovladače databází a zajišťuje, že je pro přístup k datům použit správný ovladač. Díky němu je možné se připojit v jedné aplikaci k mnoha různorodým databázím zároveň. Interakci jednotlivých vrstev a strukturu JDBC ukazuje obrázek 7.1

48


Obrázek 7.1: Architektura JDBC

7.1.1

Hlavní komponenty JDBC

V JDBC je několik hlavních komponent obsluhujících komunikaci mezi jednotlivými vrstvami v aplikaci a mezi databází: • DriverManager - spravuje dostupné ovladače databází, reaguje na požadavky aplikace o připojení a komunikaci s databází. • Connection - obsluhuje komunikaci s databází. Všechna komunikace s databází vyžadovaná Java aplikací je prováděna pouze přes toto rozhraní. • Driver - je struktura obsluhující fyzickou komunikaci s databází, překládá požadavky aplikace na volání API dané databáze. • Statement - zapouzdřuje SQL dotazy, které jsou pomocí této struktury odesílány databázi. • ResultSet - reprezentuje množinu řádků získaných jako výsledek nějakého dotazu. Hierarchii jednotlivých komponent v aplikaci můžeme vidět na obrázku 7.2.

7.1.2

Interakce komponent při navazovaní spojení s databází

Komunikace s databází probíhá následujícím způsobem: • Aplikace požádá Driver manager o připojení. • Driver manager vyhodnotí, zda má k dané databázi potřebný ovladač, pokud ano předá mu přeložené volání z aplikace • Ovladač naváže fyzické spojení s databází a předá Driver manageru objekt typu Connection.

7.2 Ovladače databáze

49

• Aplikace využije tohoto objektu k vytvoření struktury zapouzdřující reprezentaci SQL dotazů a jejich výsledků. • Přes tento objekt je možné komunikovat s databází na úrovni SQL dotazů tak dlouho, dokud není spojení ovladačem přerušeno a celý postup se nezopakuje.

Obrázek 7.2: Vnitřní struktura aplikace využívající JDBC

7.2

Ovladače databáze

Jednou z nejdůležitějších částí JDBC jsou tzv. JDBC ovladače. Jsou to specializované balíky tříd, ve většině dodávané výrobcem databáze, určené pro efektivní spojení s databázemi. JDBC specifikace rozpoznává čtyři typy JDBC ovladačů označované čísly od jedné do čtyř. Obrázek 7.3 ukazuje největší rozdíly jednotlivých ovladačů lišících se hlavně strukturou jednotlivých interních vrstev.

7.2.1

Ovladač typu 1

Ovladač prvního typu, známý také jako JDBC-ODBC Bridge, překládá všechna volání JDBC na volání ODBC a odesílá je ODBC driveru. ODBC ovladače jsou specifické pro každou databázi, proto je při jejich používání nutná instalace speciálních knihoven. Díky své náročnosti na konfiguraci se nehodí pro použití v klientských aplikacích. Nasazují se hlavně v serverově orientovaných aplikacích. Ovladač prvního typu je většinou používán tam, kde není možno použít ovladače typu tři. 7.2.1.1

Výhody

• Ovladač umožňuje připojení k většině existujících databází, protože celá řada z nich v sobě má zabudovánu podporu ODBC. • Snadná instalace ovladače

50


Obrázek 7.3: Srovnání typů ovladačů v JDBC

7.2.1.2

Nevýhody

• Jen část tohoto ovladače je napsaná v Javě, kvůli tomu není tento ovladač plně platformně nezávislý. • Ovladač typu jedna se nehodí pro internetové aplikace. • Z důvodu překladu volání JDBC na ODBC, neposkytuje tento ovladač takový výkon jako ostatní typy.

7.2.2

Ovladač typu 2

Ovladač typu dva překládá požadavky z JDBC na volání určitého specifického ovladače, který z pravidla musí být na daném počítači nainstalován a který je určen právě pro jednu databázi. Dalo by se říci, že ovladač typu jedna je podmnožinou typu dva. 7.2.2.1

Výhody

• Oproti JDBC-ODBC ovladači nepotřebuje žádné dodatečné ovladače pro ODBC. 7.2.2.2

Nevýhody

• Ovladač druhého typu (Native-API Driver) není vhodný pro nasazení v internetových aplikacích.

7.2 Ovladače databáze

51

• Pro správnou funkci je třeba mít nainstalovány speciální klientské API, které je rozdílné pro každou databázi. • Některé databáze neposkytují výše zmíněné klientské API.

7.2.3

Ovladač typu 3

JDBC ovladač typu 3 (Pure Java Driver) nepoužívá žádný platformě závislý kód a je celý implementován v Javě. Při své práci konvertuje svá volání přes JDBC na síťový komunikační protokol, kterým se spojuje se serverem. Server konvertuje síťový protokol na komunikační protokol databáze, která podle něj vykonává požadované akce. 7.2.3.1

Výhody

• Nejsou potřeba žádné dostatečné klientské knihovny • Podpora ve většině databázích • Ovladač může poskytovat další dodatečné služby. 7.2.3.2

Nevýhody

• Upravená middleware vrstva může být úzkým hrdlem aplikace.

7.2.4

Ovladač typu 4

Ovladač typu 4 (Direct to Database Pure Java Driver) převádí volání JDBC přímo na volání specifická pro danou databázi, tzn. klient může přímo komunikovat se systémem řízení databáze. 7.2.4.1

Výhody

• Platformně nezávislý, to umožňuje vývoj aplikací určených pro různorodé systémy • Výkon tohoto ovladače je nesrovnatelně vyšší než u ostatních typů. Což je způsobeno využitím přímých volání funkcí databáze bez nutnosti mezi-převodů. 7.2.4.2

Nevýhody

• Ovladač je určený pouze pro jednu specifickou databázi, každá databáze používá jiný ovladač.

52


7.3

Práce s JDBC

Předešlá část byla věnována popisu architektury JDBC. Nyní se bude krátce věnovat způsobu, jakým je možné Java aplikaci připojit k databázi.

7.3.1

Registrace ovladače

Jak již bylo řečeno hlavní částí JDBC je JDBC ovladač. Tento ovladač je ve své podstatě balík specializovaných tříd, ve většině případů dodávaný přímo výrobcem databáze. Než můžeme provádět jakékoliv operace nad nějakou databází, je nutné tento ovladač registrovat. K tomuto účelu nám v Javě slouží příkaz: Class.forName("nazev-ovladače"); Pokud registrace nebude úspěšná, systém vyvolá výjimku ClassNotFoundException informující o tom, že daný ovladač nebyl nalezen. Vlastní registraci ovladače provádí DriverManager, to je speciální vrstva mezi aplikační logikou a ovladačem. Registrace je provedena ve chvíli, kdy je zavolána výše popsaná metoda forName();. Ovladač při pokusu o registraci volá metodu registerDriver() z DriverManageru. Následně je ovladač evidován a je ho možno použít pro připojení. Všechny tyto kroky jsou prováděny zcela automaticky bez zásahu programátora.

7.3.2

Připojení k databázi

Po nahrání a registraci ovladače DriverManagerem můžeme navázat spojení s databází. Spojení je identifikováno speciálním databázovým (JDBC) URL, které je složeno ze tří částí: • První část je podle specifikace URL uvozené písmeny jdbc. • V druhé části můžeme uvést komunikační podprotokol, ten je většinou závislý na dané databázi a určuje ho výrobce databáze. • Třetí částí je DNS (Data Source Name), které určuje název databáze. Pokud máme URL ve správné formátu, můžeme DriverManager požádat o připojení. Učiníme tak zavoláním metody getConnetion(). DriverManager následně provede testování ovladače a předává URL jednotlivým registrovaným ovladačům, přičemž u prvního, který uspěje s připojením na dané URL, získá Connection objekt. Ten je pak následně předán volajícímu kódu. Následující příklad ukazuje, jakým způsobem se požadavek na spojení vytváří: String url = "jdbc:mysql://server.cz/databaze"; Connection con = DriverManager.getConnection(url, username, password ); V případě, že vše je nastaveno správně, metoda getConnection() vrátí požadované spojení, které je základem pro další práci s databází a přes které se provádí všechny operace nad databází.

7.3 Práce s JDBC

7.3.3

53

Provádění dotazů

Jakmile máme spojení s databází, můžeme nad ní začít provádět datové operace. K tomu je určena další třída Statement, kterou nám poskytne vytvořený objekt Connection. Instance této třídy pak slouží pro posílání SQL příkazů databázi, kde jsou zpracovány, a vrací odpovídající hodnoty. Statement nabízí velké množství metod. Nejdůležitější jsou metody: • executeQuery() - jak již její název napovídá, slouží k odesílání dotazů typu SELECT do databáze, výsledkem jsou objekty třídy ResultSet. Výsledný ResultSet již obsahuje skutečná data s nimiž můžeme dále pracovat. • executeUpdate() - slouží k aktualizaci databáze, tedy je používána pro příkazy jako UPDATE, INSERT, DELETE.

7.3.4

Ukázka práce s JDBC

Nyní si ukažme velice jednoduchý příklad programu využívající databázi: try { Class.forName("com.mysql.jdbc.Driver").newInstance(); String url = "jdbc:mysql://server.cz/databaze"; Connection con = DriverManager.getConnection(url, username, password ); Statement stmt = con.createStatement(); String sql = "SELECT * FROM TABULKA"; ResultSet set = stmt.executeQuery(sql); } catch(Exception e) {} Tento příklad demonstruje v zásadě všechny kroky nutné k tomu, aby se programátor dostal až k samotným datům a mohl s nimi pracovat.

54


Kapitola

8

Dostupné aplikace a jejich porovnání

V této kapitole porovnám nejvíce používané aplikace pro administraci MySQL databází a shrnu jejich hlavní výhody a nevýhody. Za zástupce tlustých klientů jsem vybral aplikace MySQL Administrátor a ORACLE SQL Developer . Z tenkých klientů jsem vybral aplikace phpMyAdmin a Adminer.

8.1

Tlustí klienti

Tlustý klient provádí maximum zpracování dat na vlastním počítači a server používá jen pro archivaci a komunikaci. Poskytuje uživatelům širokou paletu funkcionalit, ke kterým ve většině případů nepotřebuje interakci se serverem.

8.1.1

MySQL Administrator

MySQL Administrator je jednoduchá, přitom velice použitelná aplikace pro správu MySQL. Běžnému uživateli nabízí velikou škálu funkcionalit. Nemá smysl popisovat do detailu celou aplikaci proto popíši ty nejvýznamnější z nich. Aplikace poskytuje informace o právě připojených uživatelích, verzi serveru a hostitelském operačním systému. Pokud je používána pro správu serveru na lokálním počítači, je díky ní možno vypínat či zapínat MySQL démona nebo prohlížet a editovat proměnné serveru. MySQL administrátor nabízí velice intuitivní rozhraní pro správu uživatelů a jejich práv. Pouhým kliknutím lze nastavit práva daného uživatele jak k databázi, tak i k serveru samotnému. Výpis aktuálně běžících procesů a aktivních připojení ukazuje jednotlivé procesy, jejich vlastníky a dobu jejich provádění. Grafické zobrazení využití systémových prostředků serveru umožňuje nastavení tzv. watcherů na jednotlivé systémové proměnné nebo prostředky. V základním nastavení nabízí pohled na využívanou paměť, vytížení procesoru a na počet aktivních připojení. Dále aplikace nabízí správu protokolů, replikace a jednotlivých katalogů.

56

8.1.2


ORACLE SQL Developer

ORACLE SQL Developer je free grafický nástroj pro správu a vývoj databází. S jeho pomocí můžeme prohlížet, upravovat databázové objekty a spouštět SQL a PL/SQL skripty. Dále můžeme tímto nástrojem generovat množství různých statistik, jejich vytváření je možno přizpůsobit individuálním potřebám. Díky implementaci v Javě je ORACLE SQL Developer plně multiplatformní nástroj. Hlavními podporovanými systémy jsou Windows, Linux, Solaris a Mac OSX.

8.1.3

Shrnutí vlastností tlustých klientů

MySQL Administrátor a ORACLE SQL Developer jsou dvě velice odlišné aplikace. MySQL Administrátor byl původně vyvíjen společností MySQL AB, která dříve vlastnila autorská práva na zdrojové kódy MySQL. Nenabízí takovou širokou paletu funkcionalit jako ORACLE SQL Developer, ale i tak je v praxi velice užitečným nástrojem. Jedinou výrazně chybějící vlastností je možnost psaní a přímého spouštění dotazů nad databázemi. Bohužel společnost ORACLE v nedávné době pozastavila jeho vývoj. ORACLE SQL Developer je velice robustní nástroj použitelný i pro jiné databáze než je ORACLE a MySQL. Zapouzdřuje v sobě snad všechny funkcionality, které může databázový specialista v praxi potřebovat. Jeho velkou výhodou je platformní nezávislost a jeho cena.

Velikost aplikace Licence Implementováno v Podporované systémy Vytváření, editace DB objektů Administrace uživatelů Prohlížení dat Psaní a provádění SQL Správa verzí Generování statistik

MySQL Administrátor 20 MB GNU/GPL C++ Windows/Linux

ORACLE SQL Developer 100 MB OTN Java Multiplatformní

ano

ano

ano ne ne ne ne

ano ano ano ano ano

Tabulka 8.1: Shrnutí vlastností tlustých klientů

8.2

Tencí klienti

Pravým opakem k tlustému klientu je klient tenký. Ten ke své práci potřebuje přímou interakci se serverem. Většinou totiž v sobě neobsahuje velké množství implementovaných funkcionalit a všechny data jsou přeposílána na server, který je zpracuje a výsledek vrátí klientu. Tenký klient tedy slouží uživateli pouze jako rozhraní, přes které komunikuje se serverem.

8.2 Tencí klienti

8.2.1

57

phpMyAdmin

phpMyAdmin je populární open-source nástroj pro správu MySQL databází šířený pod GPL licencí. phpMyAdmin je považován za nepsaný standard pro správu databáze MySQL z prostředí webového prohlížeče. Mnoho uživatelů pro správu této databáze ani žádný jiný nástroj nepoužívá. phpMyAdmin ale není jediný nástroj svého druhu a jiné aplikace se mu snaží konkurovat. Nejčastěji tento software najdete nasazený u poskytovatelů webových služeb. Aplikaci lze stáhnout ve dvou jazykových verzích: • Verze se všemi jazyky zabírá po rozbalení 11,377 kB v 667 souborech a její zkopírování na běžný webhosting trvá několik minut. • Jednojazyčná anglická verze zabírá 4,937 kB, jiné jednojazyčné verze se ke stažení nenabízí. Co se požadavků na server týče, phpMyAdmin od verze 3 vyžaduje PHP 5.2+ a MySQL 5, pro práci se staršími verzemi je nutné použít stále udržovanou řadu 2. phpMyAdmin dovoluje nastavit celkem 143 konfiguračních direktiv, z tohoto důvodu obsahuje instalační skript, který dovoluje nastavit některé konfigurační direktivy (jiné je potřeba přímo zadat do PHP kódu). Tento skript je obvykle nezbytné spustit, protože ve výchozí konfiguraci nedovoluje phpMyAdmin zadat název serveru nebo se přihlásit pod uživatelem bez hesla.

8.2.2

Adminer

Jednou z aplikací, která se snaží konkurovat phpMyAdminu, je minimalistická webová aplikace českých autorů Adminer. Stejně jako phpMyAdmin je napsaný v PHP, ale některými vlastnostmi se snaží odlišit. Adminer je vydáván pod licencí Apache 2, podporuje PHP od verze 4.3 a MySQL od verze 4.1. Zvláštností této aplikace je její uložení v jednom 174 kB souboru umožňující její velice rychlou instalaci a následné nasazení. Jednojazyčná anglická verze má 119 kB, ke stažení je i jednojazyčná česká a slovenská verze. Adminer je k dispozici ve 12 jazycích, phpMyAdmin v 57. Oproti phpMyAdmin nevyžaduje Adminer zapnutí cookies, obejde se i bez nich. Vzhledem k tomu, že nenabízí žádné možnosti konfigurace, nemusí být zvláštním způsobem instalován. Stačí pouze překopírovat soubor obsahující PHP kód aplikace. Tím pádem se všechny instalace chovají naprosto identicky. Tato aplikace umí velmi dobře pracovat procedurami, triggery a pohledy. V tomto směru phpMyAdmin zatím stále pokulhává.

58

8.2.3


Shrnutí vlastností tenkých klientů

Přestože je phpMyAdmin zavedený standard pro správu databáze MySQL z webového prohlížeče, řadu funkcí kupodivu nenabízí, nebo je nutné je zvlášť konfigurovat. Kromě toho má překvapivé mezery v použitelnosti. Často prováděné operace nejsou intuitivní nebo k nim vede zdlouhavá cesta. Padesátkrát menší Adminer nabízí v mnoha oblastech použitelnější uživatelské rozhraní a na řadě míst také více funkcí. Shrnutí jednotlivých vlastností tenkých klientů ukazuje tabulka 8.2. Velikost aplikace Licence Multiplatformnost Podporované jazyky Možnost konfigurace Podporované verze MySQL Podporované verze PHP Export dat Správa uživatelů Triggery, procedury, pohledy Výpis proměnných serveru Rychlost Bezpečnost Funkční výbava

phpMyAdmin 11(4) MB GNU/GPL ano 57 ano 5+ 5.2 + ano ano

Adminer 174kB Apache 2 ano 12 ne 4.1 + 4.3 + ano ano

částečně

ano

ano pomalejší Dobrá Dobrá

ano o 29 % rychlejší Velmi dobrá Velmi dobrá

Tabulka 8.2: Shrnutí vlastností tenkých klientů

Kapitola

9

Analýza funkcionalit vytvářené aplikace

Moje aplikace bude navržena pro začátečníky, kteří se teprve začínají seznamovat s problematikou databází. Není tedy potřeba implementovat širokou paletu funkcionalit. Začátečníci si vystačí s omezenou množinou nástrojů. Hlavní komponentou aplikace bude textový editor pro editaci SQL. Pro začátečníka bude jistě přínosem zvýrazňování klíčových slov a spouštění dotazů přímo z editoru. Zkušenější uživatelé jistě ocení možnosti využívat mnoha připojení k různým serverů zároveň. Uživatel vytvoří libovolnou množinu připojení, mezi kterými bude pohodlně přepínat v hlavním okně aplikace. Mohlo by se stát, že při mnoha aktivních připojeních by uživatele obtěžovalo velké množství otevřených oken. Tento problém bude vyřešen tím, že aplikace bude z části navržena jako tzv. MDI aplikace. To znamená, že v sobě bude obsahovat virtuální plochu, ve které se budou zobrazovat okna jednotlivých nástrojů. To bude mít za následek, že uživatele nebude na hlavním panelu operačního systému obtěžovat velké množství otevřených formulářů. Implementovány budou i jednoduché manipulační operace s otevřenými nástroji jako např. zavřít všechny okna, minimalizovat všechny okna atd. Zrychlí se tak práce a orientace v aplikaci. Aplikace bude dále obsahovat textovou konzoli, která bude do jisté míry suplovat konzoli MySQL. Uživateli bude nabízet rozhraní pro spouštění SQL dotazů a následné textové zobrazení výsledků s možností listování v historii provedených dotazů. Tato funkcionalita bude užitečná nejen pro zkušené uživatele, kteří se rychle chtějí připojit na vzdálený server a provádět nad ním různé operace, ale i pro začátečníky, kteří zatím nepřišli do styku s žádným konzolovým nástrojem. Další důležitou komponentou bude rozhraní pro správu dat a struktury databází. Bude uživatelům nabízet kompletní informace o struktuře databáze. Zobrazí stromovou strukturu, ve které bude moci označovat jednotlivé databázové objekty, o kterých následně dostane podrobné informace. Například u tabulek bude možno zobrazit jaká data obsahuje, podrobné informace o primárních a cizích klíčích či indexech nebo náhled skriptu, který danou tabulku vygeneroval. Samozřejmostí bude možnost vytváření a mazání databází a tabulek či zálohování

60

Analýza funkcionalit vytvářené aplikace

struktury dané databáze. Vše bude možno provádět pomocí nástrojů, které nepředpokládají uživatelovu znalost SQL jazyka. Aplikace bude dále obsahovat různé podpůrné nástroje zobrazující například konfigurační proměnné serveru či testující síťovou odezvu daného serveru. Jelikož je aplikace určena především začátečníkům, nepovažoval jsem za nutné implementovat editaci a správu uživatelů. Je nepravděpodobné, že by tito lidé měli práva k měnění uživatelských kont. Funkcionalitu by tedy stejně nemohli používat.

Kapitola

10

Popis implementace

V této kapitole se budu věnovat popisu struktury vyvíjené aplikace, popíši jaké algoritmy, knihovny a frameworky jsou v ní použity.

10.1

Výběr programovacího jazyka

Jak již název práce napovídá, rozhodl jsem se, že danou aplikaci implementuji v programovacím jazyce Java. K tomuto rozhodnutí mě dovedlo hned několik důvodů. • Platformní nezávislost - jedna z největších výhod Javy, bez nutnosti rekompilace je aplikace funkční na všech běžných operačních systémech(Windows, Linux, MAC OS, Solaris, atd.), kde je nainstalováno JRE nebo JDK. • Dokumentace - k Javě existuje velmi dobře propracovaná dokumentace, mnoho užitečných návodů a hotových řešení. • Programátorská přívětivost - Java byla navržena tak, aby se v ní pracovalo příjemněji než v jiných programovacích jazycích. Jeden z důvodů, proč je Java jednodušší než C++, je implementace automatické alokace paměti a automatizovaného sběru již nepoužívaných paměťových struktur. • Bezpečnost - Java je jedním z prvních programovacích jazyků, kde bezpečnost hraje velmi významnou roli. Jazyk Java, kompilátor, interpret a běhové prostředí byly vytvářeny s velkým důrazem na bezpečnost. Z toho důvodu je velmi oblíbená v oblasti různých rozsáhlých podnikových aplikacích. • Přímá podpora MySQL - společnost SUN je nyní vlastníkem autorských práv na MySQL, to přináší komfort v tom, že pokud je vypuštěna nová verze MySQL, je zároveň uvolněn i aktualizovaný ovladač JDBC pro tuto dababázi. • Podpora databází obecně - JDBC API je velice šikovným nástrojem při portování aplikace z jedná databáze na druhou. Není nutné kompletně přepisovat celou logiku aplikace, stačí pouze zaměnit ovladač databáze a upravit minimum kódu.

62

Popis implementace

• Výhody vs. nevýhody Javy - Výhody převažují nad nevýhodami, ale i přesto, že nevýhod Javy je minimum, stojí za zmínku a některé bych rád uvedl. Největší nevýhodou je, dle mého názoru, rychlost. Java je interpretovaný jazyk. To přináší daň v podobě zpomalení běhu aplikace a větší paměťové náročnosti oproti programům vytvořeným v C++. Automatizovaný sběr nepoužívané paměti spotřebovává nemalý procesorový čas a také zpomaluje běh větších aplikací. Poslední velkou nevýhodou je nutnost instalace virtuálního stroje, který je nezbytný pro spuštění Java aplikací.

10.2

Vývojové prostředí

Při vývoji aplikace jsem používal open-source nástroj NetBeans IDE. Toto sofistikované prostředí nabízí programátorovi veliké množství funkcionalit. Velice užitečná je například podpora různých verzovacích nástrojů jako je GIT, SVN či Mercurial. V mém případě jsem využil podporu SVN, protože můj projekt používá integrovaný systém pro hlášení chyb TRACK, který je nadstavbou právě nad tímto verzovacím systémem. Dalšími užitečnými vlastnostmi jsou například podpora refaktorizace kódu či jeho propracované formátování a doplňování. NetBeans IDE používám již několik let a jsem s ním naprosto spokojen. Dle mého názoru v některých oblastech kvalitou značně převyšuje konkurenční komerční nástroje.

10.3

Vývoj grafického prostředí aplikace

Při programování v Javě máme na výběr z několika frameworků pro vývoj grafického prostředí aplikací.

10.3.1

AWT

Nejstarším frameworkem pro vývoj GUI je AWT. Programy využívající AWT jsou v duchu jazyka Java plně přenositelné, ale zároveň je ovládání a vzhled jednotlivých prvků GUI, komponent, přizpůsobeno zvyklostem konkrétního systému. Jeho velkou nevýhodou je omezená paleta standardních komponent, které můžeme používat. Výhodou může být možnost jednoduchého převodu desktopové aplikace na java applet.

10.3.2

Swing

Další možností je využití novějšího a propracovanějšího frameworku Swing. Ten programátorovi nabízí mnohem větší množinu základních grafických komponent a přívětivější vzhled výsledné aplikace. Mimo jiné nabízí alternativy k AWT komponentám, oproti nim jsou komponenty Swingu mnohem pomalejší a i obsahují více chyb.

10.4 Hibernate framework vs. JDBC

63

Swing nabízí celou řadu propracovaných, textově orientovaných komponent. Jelikož moje aplikace bude obsahovat jednoduchý textový editor, rozhodl jsem se, že pro vývoj GUI použiji právě tento framework. Dalším důvodem, proč jsem si zvolil Swing, byl fakt, že s ním pracuji už dlouhou dobu. Nebyl jsem tedy nucen studovat jeho fungování a strukturu a mohl jsem rovnou začít pracovat na daném zadání.

10.4

Hibernate framework vs. JDBC

Při vývoji aplikace jsem nepoužil žádný databázový framework. Vzhledem k jejímu charakteru mi nasazení například Hibernate frameworku nepřipadalo šikovné. Často se totiž databáze dotazuji na data jejichž strukturu předem neznám. Hibernate mapuje data pomocí předem vytvořených schémat na javovské objekty. Je tedy nutné alespoň minimálně znát strukturu dat, které budu používat. Hibernate by se dal například použít při práci se systémovými tabulkami. Jejich struktura je neměnná, tudíž můžeme předem namapovat jejich strukturu a následně s nimi pracovat jako s objekty.

10.5

Charakter aplikace

10.5.1

Charakter klienta

Jak již bylo v předcházejících kapitolách zmíněno (kapitola 8) aplikace zabývající se správou databází můžeme rozdělit na dva hlavní typy: tlustí a tencí. Tlustí klienti do jisté míry duplikují metadata ze serveru do své paměti. Naproti tomu tencí klienti nemají žádnou paměť vymezenou metadatům a každý požadavek odesílají na zpracování serveru. Po úvahách nad tím, jaký typ klienta je pro moji práci výhodnější, jsem se rozhodl, že moje aplikace bude určité minimum metadat uchovávat ve své paměti. Bude tedy spadat do kategorie tlustých klientů.

10.5.2

MDI

Aplikace je zčásti navržena jako tzv. MDI (Multiple Document Interface). To znamená, že v aplikaci je umístěna virtuální plocha, ve které se budou zobrazovat jednotlivé nástroje. Tuto strukturu jsem zvolil kvůli snadnější orientaci v případě, že má uživatel otevřeno mnoho aktivních spojení zároveň. Pokud by aplikace nebyla navržena jako MDI, mohlo by se snadno stát, že by uživatele zatěžovalo velké množství otevřených formulářů, u kterých by neměl jistotu, ke kterému aktivnímu připojení patří.

64

10.6

Popis implementace

Konzole

Zadáním bylo určeno, že vytvářená aplikace bude obsahovat jednoduchou textovou konzoli. Tuto úlohu jsem vyřešil zděděním standardní SWING komponenty JTextPane. Následně jsem přepsal některé ze zděděných metod tak, abych docílil požadovaného chování jako běžné konzole. Provádění a následné zobrazení výsledků dotazů je prováděno v samostatném vlákně. To urychluje zpracování úlohy a také je uživatel méně obtěžován pomalou odezvou aplikace, pokud je zpracováván dotaz s velkým množstvím výsledných řádků. Samozřejmostí je, že konzole podporuje zobrazení historie provedených SQL příkazů. Pohybem kláves up a down můžeme v těchto příkazech jednoduše listovat a případně je znovu spouštět. Konzole byla navržena jako univerzální komponenta. Během programování ji přiřadíme pouze odpovídající EventListener a do příslušné metody umístíme kód, který se má provést po potvrzení příkazu, tedy po stisku enteru. Nemusí tedy případně sloužit jen jako interpret SQL příkazů. Pro detailnější popis jednotlivých tříd zajišťujících funkci konzole odkazuji na dodatek C.

10.7

DB Manager

Část aplikace umožňující spravovat strukturu databází a tabulek jsem pracovně nazval DB Manager. Je navržen tak, aby práce s ním byla maximálně intuitivní. V levé části DB Manageru je umístěna komponenta JTree. V ní je zobrazována stromová struktura jednotlivých databázových objektů. Pokud uživatel označí nějakou položku ve stromě, v pravé části formuláře se zobrazí odpovídající informace o vybraném objektu. Dynamické zobrazování informací je implementováno pomocí komponenty JSplitPane. Podle typu vybraného objektu v Jtree se vyhodnotí jaký prvek se má vložit do její dominantní části. Vkládanými objekty jsou potomci třídy JPanel. Manager zobrazuje čtyři typy panelů: ServerPanel, DatabasePanel, TablePanel, EmptyPanel. Význam jednotlivých panelů napovídají jejích názvy, např. TablePanel zobrazuje strukturu a data v tabulkách. Zvláštností je EmptyPanel, který je zobrazován pokud uživatel nemá dostatečná oprávnění k zobrazení daných informací.

10.8

Editor SQL

Další důležitou komponentou aplikace je SQL editor. Tento nástroj podporuje všechny standardní funkcionality jako jsou copy & paste, redo & undo, či ukládání a otevírání souborů. Další podporovanou funkcí je možnost spuštění dotazu, nad kterým je aktuálně umístěn kursor nebo spuštění všech dotazů v souboru najednou. Implementováno bylo i zvýrazňování klíčových slov. Algoritmus obstarávající tuto činnost je popsán níže.

10.9 Algoritmus zvýrazňování klíčových slov

65

Textová komponenta zobrazující upravovaný text je opět speciálně upravená komponenta JTextPane. Její vlastnosti byly upraveny tak, aby na ní bylo možno připojit mnou vytvořenou specializovanou třídu DocumentIndexer, která řídí indexaci metadat a obstarává vlastní zvýraznění textu. Zvýrazňování klíčových slov je opět nezávislé na analyzovaném jazyce. Pokud bychom například chtěli zvýrazňovat klíčová slova HTML, upravili bychom pouze soubor s klíčovými slovy a 2 podmínky ve třídě, která obstarává sběr metadat o textu. Tím by byla celá úprava kompletní a docílili bychom toho, že jakákoliv textová komponenta využívající moji třídu by byla schopna zvýrazňovat HTML tagy.

10.9

Algoritmus zvýrazňování klíčových slov

Editor SQL skriptů, který je součástí mé aplikace podporuje zvýrazňování klíčových slov. Za tímto účelem jsem navrhl a zkonstruoval několik inteligentních datových struktur a algoritmů, které se nyní chystám popsat. Diagram vztahů jednotlivých tříd ukazuje obrázek 10.4.

10.9.1

Popis algoritmu

Pro účely zvýrazňování si aplikace v paměti udržuje metadata o právě editovaném textu. Tato metadata v sobě zahrnují informaci o typu, pozici a délce určité skupiny znaků. Při každé změně textu musí být metadata aktualizována, určité položky upraveny nebo úplně smazány. Aktualizace dat a udržování jejich konzistence s textem není úplně triviální úloha, ale po úspěšném prvotním indexování textu je algoritmus velice efektivní.

Obrázek 10.1: Prvotní indexování textu Jak již bylo řečeno nejslabším článkem algoritmu je prvotní analýza textu. Lexikální analyzátor musí projít celý vkládaný text a musí vyhodnotit jaké typy řetězců či speciálních znaků se nachází na určitých pozicích. U nově nalezeného lexikálního symbolu lexikální analyzátor zjistí jeho pozici v textu, typ symbolu a délku. Pozice v textu slouží jako klíč do stromu s metadaty. Typ symbolu využívá zvýrazňovací vlákno pro informaci, jakým způsobem má být daný lexikální symbol vykreslen. Délka symbolu je potřebná pro zvýrazňování a pro udržování konzistence metadat.

66

Popis implementace

Indexy (relativní pozice v textu) jednotlivých lexikálních symbolů se zvětšují od jedničky až do hodnoty počtu znaků v textu. Během prvotní indexace není nutné provádět další podpůrné operace, jako jsou posuvy nebo mazání. Nově nalezený lexikální symbol má vždy minimálně o jedničku větší klíč než symbol předcházející. Stačí tedy nový prvek vložit na relativní konec záznamu o metadatech. Obrázek 10.1 naznačuje schématicky právě popsaný cyklus prvotní indexace textu.

Obrázek 10.2: Stav metadat po vložení textu

Další situací, které se budu věnovat, je vložení textu do již indexovaných metadat. Situaci graficky znázorňuje obrázek 10.2. Pro ukázku jsem si zvolil jeden z nejjednodušších případů, kdy není novým textem přepisován stávající lexikální symbol. Tato operace již není tak triviální jako předcházející případ. Pokud vložíme text mezi nějaké lexikální symboly, je nutné určitou část z nich posunout o délku vkládaného symbolu doprava. Takováto operace je velice časově náročná, protože musíme projít všechny položky z klíčem větším než klíč vkládané položky a aktualizovat jejich hodnoty. Vše je však prováděno s lineární časovou složitostí, takže i při relativně dlouhém textu není odezva aplikace výrazně zpožděna. Obrázek 10.3 ukazuje poslední z triviálních případů, kdy je smazán jeden znak určitého dlouhého lexikálního symbolu. Časová složitost je shodná jako v předchozím případě. Pokud je smazán určitý znak, je nutné aktualizovat délku lexikálního symbolu v tabulce metadat a aktualizovat pozice všech prvků majících větší klíč než editovaný prvek. Tři případy, které jsem právě popsal, jsou jedny z nejjednodušších, které mohou při správě metadat nastat. Uvedl jsem je proto, aby bylo zřejmé, na jakém principu algoritmus pracuje. Ve skutečnosti jsou dané operace prováděny sofistikovanějším způsobem. Na řadu situací jsem implementoval menší optimalizační postupy, které algoritmus zesložiťují, ale přináší odměnu v podobě efektivnějšího využívání paměti a rychlejší indexace. Pro detailnější pohled na práci algoritmu odkazuji na zdrojový kód aplikace.

10.9 Algoritmus zvýrazňování klíčových slov

67

Obrázek 10.3: Stav metadat při odebrání znaku

10.9.2

Popis tříd obstarávající zvýrazňování

První třídou, které se budu věnovat, je třída Lexer. Ta obstarává zpracování daného řetězce a určuje, jaké typy znaků se v něm nacházejí (provádí lexikální analýzu textu). Druhy řetězců, jaké lexer může rozpoznat, popisuje výčtový typ Token. Ten dělí znaky do několika skupin: • RESERVEDWORD - reprezentuje skupinu řetězců, které dohromady tvoří klíčové slovo jazyka SQL. K rozpoznání klíčových slov využívá lexer služeb třídy ReservedWordFinder, která ve stromové struktuře uchovává seřazené klíčová slova z výčtového typu ReservedWords. • WHITESPACE - určuje, že daný znak je bílý znak. • TEXT - množina znaků tvořících slovo, které však není klíčovým slovem. Text může být i jeden znak. • Speciální znaky - znaky reprezentující závorky, plus, mínus atd. Asi nejvýznamnější strukturou, která je algoritmem používána, je třída TokenCache. Ta v sobě uchovává metadata o načteném textu a provádí s nimi různé operace, jako jsou rotace, posuny, mazání vkládání atd. V rámci optimalizace výkonu jsou metadata v této třídě uchovávána v černo-červeném stromě. Jednotlivá metadata (indexy) jsou instancemi třídy TokenCacheElement. Uchovávají v sobě informaci o počáteční pozici tokenu, jeho délce a jeho typu. Nadstavbou nad třídou TokenCache je TokenCacheDriver, ta obstarává provádění komplikovanějších operací nad metadaty a řídí vkládání a odebírání jednotlivých položek. Další významnou třídou je HighlightDocument, ta obstarává definici písem a jejich vlastností, které jsou následně použity při zvýrazňování.

68

Popis implementace

Poslední třídou, o které nebyla řeč, je DokumentIndexer, zastřešující výše popsané třídy. DokumentIndexer obsluhuje volání od DocumentListeneru a předává je v upravené podobě TokenCacheDriveru. Jeho hlavní činností je však vlastní zvýrazňování položek v textu. Obsluha volání DocumentListeneru a zvýraznění se provádí paralelně, což zrychluje provádění algoritmu a generuje tak menší zpoždění odezvy aplikace, které by mohlo uživatele obtěžovat.

Obrázek 10.4: Diagram tříd obstarávajících zvýrazňování textu

Kapitola

11

Testování

Tato kapitola uvádí způsoby, jakými byla vytvářená aplikace otestována. Popisuje jednotlivé dílčí výsledky testů a reakce a náměty uživatelů na výsledný vzhled a chování programu.

11.1

Nezávislí uživatelé

Aplikace byla předvedena dvěma uživatelům, kteří mají minimální znalosti databázových systémů. Byli seznámeni se strukturou aplikace a jejími jednotlivými nástroji. Následně byli vyzváni, aby pomocí mého programu splnili jednoduché zadání, které spočívalo ve vytvoření nové databáze, několika nových tabulek, editaci již vytvořeného souboru se SQL skriptem a manipulací s konzolí. Poté bylo sledováno, jak rychle se uživatelé zorientují v dané aplikaci a jakou dobu jim bude daný úkol trvat. V obou případech se uživatelé v aplikaci zorientovali velice rychle a během několika minut měli úkol vyřešen. Uživatelé nejvíce aplikaci vytýkali to, že neposkytuje rozhraní pro vizuální editaci a přidávání dat do tabulek. Pravda je, že začátečníkům by toto rozhraní jistě ulehčilo jejich práci. Na druhou stranu je nutno uvést, že jak v konzoli tak v editoru je možné ručně spouštět uvedené aktualizační dotazy. Dalo by se tedy říci, že dané rozhraní by bylo víceméně redundantní a uživatele by nepřimělo k tomu, aby začal při práci s databází používat SQL jazyka. Dále testeři nepovažovali za vhodné, že při vytvoření tabulky nebo databáze se strom databázových objektů automaticky neobnoví a jeho aktualizace musí být vyvolána ručně tlačítkem refresh. Tato výtka je opět diskutabilní. Pokud je databáze, se kterou pracujeme, umístěna na vzdáleném serveru, každá aktualizace metadat vyžaduje přenos nemalého objemu dat. Tento přenos vyžaduje určitý čas, během něhož je běh aplikace mírně zpomalen. Záleží pak na uživateli, zda preferuje rychlost aplikace či stále aktuální informace o struktuře databáze.

70

11.2

Testování

Dumb monkey testing

GUI aplikace bylo otestováno programem GUITester, který provádí tzv. dumb monkey test. Ten probíhá tak, že program náhodně kliká do určené aplikace, nebo do textových prvků doplňuje určité nestandardní textové řetězce a pokouší se tímto způsobem aplikaci donutit, aby zhavarovala. GUITester nenašel v aplikaci žádné chyby.

Obrázek 11.1: Testování aplikace pomocí GUI testeru

Několik minut náhodně klikal na jednotlivé prvky aplikace a poté ji zavřel. Výsledný přínos testu není tedy velký. Byla pouze důkladněji otestována odolnost editoru a hlavního okna aplikace na zadání nestandardních znaků.

11.3

JMeter

JMeter je balík mnoha speciálních pluginů a nástrojů do vývojového prostředí Netbeans umožňující detailní analýzu spuštěné aplikace. Z těchto modulů jsem hlavně použil nástroje pro monitorování běhu vláken, analýzu alokované paměti a monitorování spotřeby procesorového času.

11.3.1

Monitor běhu vláken

Prvním významným nástrojem je monitor běhu jednotlivých vláken. Pomocí něho lze jednoduchým a přehledným způsobem analyzovat stav spouštěných vláken a otestovat tak, že námi vytvářené procesy korektně vykonávají svoji funkci a správně se v daný čas ukončují. Možný výstup testu ukazuje obrázek 11.2. Je na něm zachycen průběh života jednotlivých vláken při přihlašování na server a následné zpracování a provedení jednoduchého příkazu v konzoli.

11.3 JMeter

71

Pomocí tohoto nástroje byla ověřena správná funkčnost a správné ukončení všech vláken, které aplikace explicitně vytváří. Tímto způsobem bylo odhaleno nekorektní ukončování procesu, který obstarává testování síťové komunikace. Občas se totiž mohlo stát, že dané vlákno běželo i mimo svůj vyhrazený životní cyklus. Problém nebyl dosud zcela objasněn a je pravděpodobně způsoben vytvářením a spouštěním procesu ve statické třídě, což by teoreticky v normálních případech nemělo nikterak vadit.

Obrázek 11.2: Analýza vláken

11.3.2

Test spotřeby času procesoru

Další nástroj, který jsem při analýze použil, byl test spotřeby procesorového času. Ověřena jím byla hlavně rychlost výpočtů při indexování a zvýrazňování textu. V editoru jsem otevřel velmi rozsáhlý soubor (odhadem 5000 řádků) se SQL skriptem a následně jsem sledoval, kolik procesorového času spotřebovaly jednotlivé výpočty a kolikrát byly volány jednotlivé metody. Výsledek testu ukazuje obrázek 11.3. Celkový procesorový čas potřebný pro analýzu daného textu byl 3258 ms a nejdéle trvající operací bylo samotné zvýraznění daného řetězce. S výsledkem tohoto testu jsem byl víceméně spokojen a již jsem neprováděl žádné dodatečné úpravy kódu. Pro zajímavost jsem dále provedl menší rozbor, zkoumající jak velká část výkonu procesoru je skutečně spotřebována mnou vytvořeným kódem a jaká část připadá systémovým knihovnám a třídám. Ukázkový výsledek je vidět na obrázku 11.4. Uvedený graf zachycuje situaci, kdy byl v konzoli spuštěn nějaký příkaz. Během provádění bylo 21.5% času využito pro vykonání mého kódu a zbytek byl spotřebován systémovými procesy. Tento graf není ovšem příliš vypovídající. Při provádění různorodých operací se spotřeba dynamicky mění. Graf uvádím jen pro zajímavé srovnání.

72

Testování

Obrázek 11.3: Analýza spotřeby procesorového času

Obrázek 11.4: Graf využití procesoru jednotlivými částmi aplikace

11.3.3

Analýza alokované paměti

Posledním, velice užitečným nástrojem z balíku JMeter, který jsem při testování použil, byl nástroj pro analýzu alokované paměti. Ten sleduje počet a velikost jednotlivých alokovaných objektů a celkovou paměť, která je daným typem objektu obsazena. Testováním pomocí tohoto nástroje jsem objevil jeden velice závažný problém. Pokud uživatel otevřel například konzoli a v ní provedl příkaz, jehož výsledek obsahoval velké množství řádků (řádově desetitisíce) a následně formulář zavřel, nedošlo k dealokaci již nepotřebné paměti. Původce problému jsem nalezl relativně rychle. Většina formulářů aplikace je zobrazována v komponentě JDesktopPane. Pokud okno zavřu, provede se sice volání dispose();, ale reference na dané okno je stále uchovávána v JDesktopPane. Garbage collector tedy tento objekt prohlásí za používaný a nesmaže ho. Řešení problému bylo velice jednoduché. Každý formulář při zavírání odstraňuje sám

11.4 JConsole

73

sebe z daného kontejneru. Tím je reference na něj ztracena a garbage collector ho může smazat. Obrázek 11.5 ukazuje, jak jednoduše lze lokalizovat výskyt memory leaku. Pokud se proklikáme stromovou strukturou jednotlivých volání, snadno zjistíme, jaká metoda nehospodárně pracuje s pamětí. Na obrázku je zachycen výše popsaný případ, kdy byl v konzoli zobrazen příkaz s velkým počtem výsledných řádku.

Obrázek 11.5: Analýza neuvolněné paměti

11.4

JConsole

JConsole je monitorující nástroj funkcemi velice podobný balíku JMeter. Jejich hlavní odlišností je, že JConsole je samostatná aplikace, zatímco JMeter je balík utilit pro NetBeans IDE. Pomocí tohoto nástroje byly pouze kontrolovány některé dílčí výsledky testů využívání paměti a byl použit při kontrole běhu vláken.

11.5

JUnit testy

Pro otestování hlavních částí aplikace bylo vytvořeno celkem 41 JUnit testů. Ty odhalily drobné nedostatky v ošetření některých výjimek a nedostatečné ošetření některých mezních hodnot. Vzhledem k charakteru aplikace, kdy je většinou s daty manipulováno na úrovni databáze a následně je výsledek pouze zpracován do grafické podoby, nebylo nutné pokrýt všechny třídy testy. V mnoha případech bych pouze testoval gettery nebo settery tříd nebo porovnával, zda databáze odeslala správná data. Velká část aplikace je tvořena grafickými třídami, které nejdou pomocí JUnit testů příliš efektivně testovat. To se odráží i na celkové statistice code coverage, kterou uvádí tabulka 11.1. Pokryté třídy Pokryté řádky kódu Pokryté balíky

16% 18% 19%

(14 / 86) (1083 / 5988) (3 / 16)

Tabulka 11.1: Code coverage statistika projektu

74

11.6

Testování

Track

Pro účely testování byl zdrojový kód aplikace zveřejněn na serveru assembla.com. Nabízí opensource projektů zdarma SVN či GIT repositář a wiki s integrovanou podporou systému pro hlášení chyb. Kdokoliv si z těchto stránek může aplikaci stáhnout otestovat a případně navrhnout úpravy nebo vylepšení. Což přináší výhodu rychlé odezvy uživatelů na právě vydané nové verze a rychlejší nalezení a odladění chyb. Výsledkem je rychlejší rozvoj a vylepšování funkcionalit aplikace.

Kapitola

12

Závěr

12.1

Náměty na další úpravy aplikace

Jelikož byla aplikace vyvíjena jako bakalářský projekt, pracoval jsem na ní sám bez pomoci dalších programátorů. Pro další úspěšný rozvoj bych doporučoval vytvořit tým programátorů, z nichž by se každý specializoval na vylepšení jednotlivých nástrojů. Proto byly zdrojové kódy zveřejněny na internetu. Kdokoli tedy může do projektu přispívat. Také by bylo dobré doplnit nástroje, které uživatelé v aplikaci nejvíce postrádají, tzn. rozhraní pro editaci dat v tabulkách. Velice užitečná by jistě byla i podpora různých databází, ne jen MySQL. Naprostí začátečníci by jistě ocenili možnost vizuálního návrhu SQL dotazů. Rozšíření by se měl dočkat i editor. Aby mohl bez problémů konkurovat ostatním nástrojům, bylo by zapotřebí zdokonalit zvýrazňování syntaxe tak, aby podporovalo zvýraznění komentářů. Užitečné by jistě bylo i doplňování rozepsaného kódu. Z mého pohledu aplikaci chybí možnost zálohování dat z tabulek ze vzdáleného serveru na lokální počítač.

12.2

Shrnutí práce

Díky této práci jsem zdokonalil své znalosti z oblasti databází. Podrobně jsem nastudoval strukturu a chování MySQL serveru. Toho jsem následně využil při vytváření jednotlivých funkcionalit aplikace. V práci jsem shrnul problematiku transakcí, popsal jsem typy tabulek a základní optimalizační techniky. Stručně byla popsána i obnova a zálohování dat. Dále jsem se také seznámil s fungováním a vlastnostmi jednotlivých SWING komponent. Některé z nich jsem si sám vytvořil nebo upravil tak, abych docílil potřebného vzhledu a chování. V neposlední řadě jsem si osvojil práci s množstvím monitorovacích, analytických a testovacích nástrojů jako je JUnit nebo JMeter. Díky nim jsem mohl ověřit a otestovat správnou funkčnost jednotlivých částí aplikace.

76

Závěr

Podařilo se mi implementovat užitečnou aplikaci pro správu databází schopnou připojit se k více serverům zároveň. Poskytuje nezkušeným uživatelům nástroje užitečné v začátcích práce s MySQL. I pokročilí uživatelé v ní určitě najdou nástroje usnadňující jejich práci. Výhodou programu je, že při instalaci v porovnání s některými komerčními i opensource projekty nezabírá velký prostor na disku. Celá aplikace má velikost přibližně 5 MB. Další nespornou výhodou je její platformní nezávislost a přenositelnost. Bez problémů ji lze spustit např. na Windows, Linuxu či Solarisu bez toho, aniž by se musely instalovat nějaké dodatečné knihovny. Aplikaci není potřeba nijak speciálně instalovat. Může tedy být umístěna např. na USB flash disk a libovolně přenášena mezi počítači.

Dodatek

A

Uživatelská příručka

A.1

Instalace

Instalace programu je velice jednoduchá. Dodaný archiv stačí rozbalit do libovolné složky. Aplikaci spustíme jedním z předpřipravených skriptů run.sh (pro Unix like systémy) nebo run.bat (pro Windows). Můžeme také přímo spustit zavaděč aplikace pomocí příkazu java -jar JMySQLAdminLancher.jar.

A.2

HW a SW požadavky

Aplikace je spustitelná všude, kde je nainstalováno JDK / JRE verze 6 a vyšší. Program je kompatibilní s MySQL verze 5.1 a vyšší. Pro plynulý běh aplikace doporučuji minimálně 64 MB volné operační paměti. Žádné další HW nebo SW omezení nejsou známy.

A.3

Popis nejdůležitějších částí aplikace

V této části stručně popíši vzhled a chování nejdůležitějších nástrojů aplikace. Obrázek A.1 ukazuje vzhled celé aplikace s otevřenými nástroji. Za povšimnutí stojí hlavně vrchní část obrázku, kde jsou vidět tlačítka pro rychlé spouštění jednotlivých nástrojů. Pod těmito tlačítky je modře zvýrazněn panel aktivních připojení. Ten umožňuje vybrat z aktivních připojení právě jedno, které bude následně asociováno s nástroji aplikace.

Obrázek A.1: Hlavní okno aplikace s otevřenými nástroji

Obrázek A.2: Panel aktivních připojení

Na obrázku A.2 je vidět právě popsaný panel. Jednotlivá připojení lze snadno identifikovat podle názvu serveru, ke kterému jsme připojeni, portu, používané databáze a aktuálního uživatele. Změna hlavního připojení se provede jednoduchým rozevřením rozbalovacího menu a následným vybráním určitého spojení v seznamu. Odpojení hlavního spojení provedeme stiskem tlačítka 6. Pokud bychom potřebovali detailnější

informace o aktivním spojení stačí stisknout tlačítko 7. Zobrazí se nám detailnější informace o vzdáleném serveru např. IP, typ a jméno hostitelského operačního systému, seznam aktuálních procesů, atd.

Obrázek A.3: Hlavní nástroje aplikace

Aplikace disponuje poměrně velkým množstvím nástrojů, ty o serveru zjišťují různorodé druhy informací. Popis jednotlivých nástrojů uvádí obrázek A.3. Můžeme je spouštět stisknutím tlačítka na hlavním panelu nebo vybráním v menu View ->jméno nástroje.

Obrázek A.4: Vykonaný dotaz v konzoli

Další z obrázků A.4 ukazuje konzoli, ve které byl vykonán nějaký dotaz. Jak je vidět vzhledem se moc neliší od plnohodnotné konzole. Výsledná data jsou přehledně formátována do sloupců. Konzole disponuje historií provádění dotazů. Stiskem kláves nahoru či dolu v ní můžeme snadno listovat a znovu tak spouštět již provedené dotazy. Pokud bychom prováděli dotaz s velkým počtem výsledných řádků, budeme na to před zobrazením výsledku automaticky upozorněni. Následně si můžeme vybrat, zda výsledek opravdu zobrazíme či ne. Důležitou komponentou aplikace je SQL editor.

Obrázek A.5: Editor SQL skriptů Jeho části popisuje obrázek A.5. Editor podporuje zvýrazňování syntaxe, spouštění dotazu na aktuální pozici kursoru nebo spuštění celého editovaného souboru. Dále disponuje standardními funkcemi jako copy & paste, atd.

Obrázek A.6: Manager databází

Poslední obrázek A.6 popisuje nástroj DB manager. Pomocí něho si můžeme zobrazit stromovou strukturu jednotlivých databázových objektů. Pokud nějaký objekt označíme, zobrazí se nám o něm detailní informace. Dále v něm můžeme mazat nebo vytvářet nové databáze. Pomocí návrháře můžeme vytvořit novou tabulku nebo ji smazat. Manager také umožňuje zálohovat strukturu všech objektů v zadané databázi.

Dodatek

B

Seznam zkratek

ACID - Atomicity, consistency, isolation, durability ADO - ActiveX Data Objects AMD - Advanced Micro Devices ANSI - American National Standards Institute API - Application programming interface AWT - Abstract Window ToolKit BSD - Berkeley Software Distribution CSV - Comma-separated values DESC - DESCRIBE, jedna z klauzulí SQL dotazů DNS - Data Source Name GCC - The GNU Compiler Collection GPL - General Public License GUI - Graphical user interface HTTP - Hypertext Transfer Protocol I/O - Input/output IBM - International Business Machines Corporation IDPL - Initial Developer’s Public License IPL - InterBase Public License IT - Information technology JDBC - Java Database Connectivity JDK - Java Development Kit JRE - Java Runtime Environment MDI - Multiple-Document Interface mSQL - Mini SQL NASA - National Aeronautics and Space Administration ODBC - Open Database Connectivity ORDBMS - Object-relational database management system OS - Operating system PD - Public domain PGCC - GNU C Compiler with Pentium optimizations PHP - PHP: Hypertext Preprocessor PL/pgSQL - Procedural Language/PostgreSQL Structured Query Language

RAID - Redundant Array of Independent Disks RDBMS - Relational database management system SQL - Structured Query Language SSL - Secure Sockets Layer SUN - Stanford University Network SVN - Subversion URL - Uniform Resource Locator XML - Extensible Markup Language

Dodatek

C

UML Diagramy

Obrázek C.1: Hrubá struktura celé aplikace

Obrázek C.2: Struktura tříd obstarávající funkci editoru

Obrázek C.3: Struktura tříd obstarávající funkci konzole

Obrázek C.4: Struktura tříd sloužících pro administraci databází

Dodatek

D

Obsah CD

Následující schéma ukazuje obsah přílohy bakalářské práce. Jsou na ní popsány jen důležité složky a soubory.

Seznam tabulek

2.1 2.2 2.3 2.4 2.5

Základní informace o konkurenčních databázích Srovnání podpory operačních systémů . . . . . . Porovnání základních vlastností . . . . . . . . . Srovnání limitů databází . . . . . . . . . . . . . Porovnání funkcionalit . . . . . . . . . . . . . .

. . . . .

14 15 15 16 16

4.1 4.2 4.3 4.4

23 24 26

4.6

Shrnutí vlastností tabulek typu MyISAM . . . . . . . . . . . . . . . . Shrnutí vlastností tabulek typu InnoDB . . . . . . . . . . . . . . . . . Shrnutí vlastností tabulek typu Memory(Heap) . . . . . . . . . . . . Porovnání velikosti datových souborů Archive s nekomprimovanou MyISAM tabulkou a Innodb tabulkou . . . . . . . . . . . . . . . . . . . Porovnání velikosti datových souborů Archive s komprimovanou MyISAM tabulkou a Innodb tabulkou . . . . . . . . . . . . . . . . . . . . Shrnutí vlastností tabulek typu Archive . . . . . . . . . . . . . . . . .

8.1 8.2

Shrnutí vlastností tlustých klientů . . . . . . . . . . . . . . . . . . . . Shrnutí vlastností tenkých klientů . . . . . . . . . . . . . . . . . . . .

56 58

11.1 Code coverage statistika projektu . . . . . . . . . . . . . . . . . . . .

73

4.5

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

28 29 29

Seznam obrázků

2.1

Schéma interakce jednotlivých modulů MySQL . . . . . . . . . . . . .

9

4.1 4.2 4.3

Modulární systém uložišť v MySQL . . . . . . . . . . . . . . . . . . . Schéma komunikace serverů při použití tabulky systému Federated . . Schéma použití úložného systému Blackhole . . . . . . . . . . . . . .

22 30 32

7.1 7.2 7.3

Architektura JDBC . . . . . . . . . . . . . . . . . . . . . . . . . . . . Vnitřní struktura aplikace využívající JDBC . . . . . . . . . . . . . . Srovnání typů ovladačů v JDBC . . . . . . . . . . . . . . . . . . . . .

48 49 50

10.1 10.2 10.3 10.4

Prvotní indexování textu . . . . . . . . . . . . . Stav metadat po vložení textu . . . . . . . . . . Stav metadat při odebrání znaku . . . . . . . . Diagram tříd obstarávajících zvýrazňování textu

11.1 11.2 11.3 11.4 11.5 A.1 A.2 A.3 A.4 A.5 A.6

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

65 66 67 68

Testování aplikace pomocí GUI testeru . . Analýza vláken . . . . . . . . . . . . . . . Analýza spotřeby procesorového času . . . Graf využití procesoru jednotlivými částmi Analýza neuvolněné paměti . . . . . . . .

. . . . . . . . . . . . . . . aplikace . . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

70 71 72 72 73

Hlavní okno aplikace s otevřenými Panel aktivních připojení . . . . . Hlavní nástroje aplikace . . . . . Vykonaný dotaz v konzoli . . . . Editor SQL skriptů . . . . . . . . Manager databází . . . . . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

78 78 79 80 80 81

nástroji . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . .

. . . . . .

. . . .

. . . . . .

. . . . . .

C.1 C.2 C.3 C.4

Hrubá struktura celé aplikace . . . . . . . . . . . . Struktura tříd obstarávající funkci editoru . . . . . Struktura tříd obstarávající funkci konzole . . . . . Struktura tříd sloužících pro administraci databází

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

85 86 86 87

Literatura a zdroje

1. SUMATHI, S. ; ESAKKIRAJAN, S.; Fundamentals of Relational Database Management Systems . Berlin : Springer, 2007. 793 s. ISBN 1860-9503. 2. HAERDER, THEO ; REUTER, ANDREAS . Principles of Transaction-Oriented Database Recovery. Computing Surveys. 1983, 4, s. 287-317. 3. BELL, Charles A. Expert MySQL. New York : Apress, 2007. 598 s. ISBN 159059-741-9 4. JSR 221. JDBC 4.0 Specification. 4150 Network Circle, Santa Clara, California 95054, U.S.A : Lance Andersen, 7.11.2006. 226 s. 5. SUEHRING, Steve MySQL Bible New York : Wiley Publishing, Inc. , 2002. 725 s. ISBN 0-7645-4932-4. 6. MARINILLI, Mauro . Professional Java User Interfaces. West Sussex, England: John Wiley & Sons Ltd, 2006. 673 s. ISBN 0-471-48696-5. 7. WELLING, Luke, LAURA, Thomson MySQL : Průvodce základy databázového systému, Jan Gregor. Brno CP Book a.s 2005. 255 s. 80-251-0671-3 8. MATTHEWS, Mark , COLE, Jim , GRADECKI, Joseph D MySQL and Java Developer’s Guide, Robert M. Elliott. Wiley Publishing, Inc. , 2003. 433 s. ISBN 0-471-26923-9. 9. FIŠAR, Ondřej Správa MySQL serveru, Praha, 2009. 50 s. Vedoucí bakalářské práce Ing. Michal Šoch, Ph.D. 10. MUNZAR, Zbyněk Klient pro správu databází MySQL, Praha, 2008. 61 s. Vedoucí diplomové práce Ing. Michal Valenta, Ph.D. 11. SCARPINO, MATTHEW ; HOLDER, STEPHEN ; MIHALKOVIC, LAURENT . SWT/JFace in Action. Greenwich : Manning Publications Co., 2005. 495 s. ISBN 1-932394-27-3.

12. REESE, George. JDBC and Java . Second Edition. Sebastopol, CA : O’Reilly, 2000. 253 s. 13. MySQL Reference Manual, 2001th edition. 2001. 798 s. Dostupný z WWW: http://www.mysql.com 14. SCHWARTZ, Baron ; ZAITSEV, Peter ; TKACHENKO, Vadim . High Performance MySQL. Second Edition. 5 Gravenstein Highway North, Sebastopol, CA: O’Reilly Media, Inc., 2008. 710 s. ISBN 978-0-596-10171-8. 15. ECKEL, Bruce. Thinking in Java. Third Edition. New York : Prentice Hall, 2002. 1119 s. ISBN 0131002872, Dostupný z WWW: http://www-db.deis. unibo.it/~gmonti/docs/tij.pdf. 16. O’DONAHUE, John Java Database Programming Bible. West Sussex, England: John Wiley & Sons , 2002. 702 s. ISBN 0764549243. 17. DUBOIS, Paul . MySQL Cookbook. Second Edition. Sebastopol, CA : O’Reilly Media, 2006. 1005 s. ISBN 0-596-52708-X. 18. KOFLER, Michael . The Definitive Guide to MySQL 5. Third Edition. New York : Apress, 2005. 785 s. ISBN 1-59059-535-1. 19. PARSIAN, Mahmoud. JDBC Metadata, MySQL, and Oracle Recipes: A ProblemSolution Approach. New York : Apress, 2006. 504 s. ISBN 1-59059-637-4. 20. VRÁNA, Jakub. Co nefunguje v MySQL a jak to obejít [online]. ROOT.CZ, c2010 [cit. 2010-2-16]. Dostupný z WWW: http://www.root.cz/clanky/co-nefunguje-v-mysql-jak-to-obejit. 21. Comparison of relational database management systems [online]. Wikipedia, c2010 [cit. 2010-02-01]. Dostupný z WWW: http://en.wikipedia.org/wiki/ Comparison_of_relational_database_management_systems. 22. February 2002 eWeek Benchmarks [online]. c2010 [cit. 2002-03-12]. Dostupný z WWW: http://mysql.com/why-mysql/benchmarks/eweek.html. 23. MUNAF. Web-dot-dev [online]. , 8. 10. 2008 [cit. 2007-04-22]. Java Advantages and Disadvantages. Dostupný z WWW: http://www.webdotdev.com/ nvd/content/view/1042/204/ 24. STĚHULE, Pavel. Letmý pohled na Alfu MySQL 5.0 z pohledu postgresisty [online]. ROOT.CZ, c2010 [cit. 2004-01-29]. Dostupný z WWW: http://www.root. cz/clanky/letmy-pohled-alfa-mysql-5-0-pohled-postgres. 25. MySQL Helps Set New World Records for Speed & Price/Performance in Independent Benchmarks [online]. MySQL AB, c2010 [cit. 2004-02-16]. Dostupný z WWW: http://mysql.com/news-and-events/generate-article.php?id= 2004_27.

26. MySQL [online]. 2005-09-16 [cit. 2010-04-06]. The MySQL 5.0 Archive Storage Engine. Dostupné z WWW: http://dev.mysql.com/tech-resources/ articles/storage-engine.html. 27. Bhaveshvala [online]. 2008 [cit. 2010-04-06]. MySQL’s BLACKHOLE Storage Engine. Dostupné z WWW: http://bhaveshvala.wordpress.com/2009/09/ 15/mysqls-blackhole-storage-engine/. 28. ŠEDA, Jan. Interval.cz [online]. 04. 03. 2003 [cit. 2010-04-06]. Úvod do JDBC. Dostupné z WWW: http://interval.cz/clanky/uvod-do-jdbc/. 29. Developersbook.com [online]. 2009-02-08 [cit. 2010-04-06].JDBC Interview Questions. Dostupné z WWW: http://www.developersbook.com/jdbc/interview-questions/ jdbc-interview-questions-faqs.php. 30. Jdbc-tutorial.com [online]. 2007 [cit. 2010-04-07]. JDBC Driver Types. Dostupné z WWW: http://www.jdbc-tutorial.com/jdbc-driver-types.htm. 31. Javadesign.info [online]. 2008 [cit. 2010-04-07]. JDBC - JDBC Architecture. Dostupné z WWW: http://www.javadesign.info/JSE/JDBC/jdbc_architecture. 32. VRÁNA, Jakub . Root.cz [online]. 12. 1. 2010 [cit. 2010-04-07]. PhpMyAdmin VS Adminer. Dostupné z WWW: http://zdrojak.root.cz/clanky/phpmyadmin-vs-adminer/. 33. Databasejournal.com : Featured Database Articles [online]. 2004 [cit. 2010-0407]. MySQL Administrator. Dostupné z WWW: http://www.databasejournal. com/features/mysql/article.php/3449511/MySQL-Administrator.htm. 34. What is SQL Developer? [online]. 2010 [cit. 2010-04-07]. Oracle Technology Network. Dostupné z WWW: http://www.oracle.com/technology/products/ database/sql_developer/files/what_is_sqldev.html

Aplikace pro správu MySQL databází implementovaná v JAVĚ Lubor Petr

Recommend Documents