Image
18.5.2016 0 Comments

Databázy III / 7. časť

Späť na úvod >> Späť na seriál

V tejto časti seriálu sa pozrieme na databázu MySQL zo systémového hľadiska. Povieme si niečo o tom, čo by mala silná databáza mať a čo MySQL má či nemá, ako to riešiť a ako vyladiť server na plný výkon.
Výkonný produkt – áno či nie?
V dnešnej dobe relatívne neobmedzených informácií sa vynára potreba čo najvýkonnejšieho databázového produktu. Výkonnosť každého produktu je daná dvoma aspektmi:

  1. robustnosťou databázového systému
  2. optimalizáciou behu systému

ROBUSTNOSŤ SYSTÉMU. Pod týmto pojmom si môžeme predstaviť počet a efektivitu funkcií systému. Systému, ktorý obsahuje viac (naozaj) potrebných funkcií, hovoríme, že je robustnejší.
Medzi najdôležitejšie funkcie systému zaraďujeme:

  • transakcie – transactions
  • uložené procedúry – stored procedures
  • kurzory – cursors
  • spúšťače – triggers
  • obmedzujúce pravidlá – constrains

Robustnosť je však na úkor rýchlosti systému. Spravidla systém, ktorý obsahuje viac funkcií, a je teda robustnejší, býva aj pomalší.
Naopak, systém, ktorý neobsahuje niektoré funkcie, býva veľmi rýchly.
Nesmieme si však zamieňať pojem rýchly s pojmom výkonný!
Výkonnosť je akýsi kompromis medzi robustnosťou a rýchlosťou systému.
Pozrime sa informatívne na jednotlivé funkcie a porovnajme ich s možnosťami MySQL.
TRANSAKCIE. Transakcia je skupina spracúvaných činností, ktoré sú kompletne celé dokončené, alebo keď nie sú dokončené, sú databázy a systém spracúvania ponechané v rovnakom stave ako pred začatím transakcie. Transakcie sa považujú za atomické operácie.
Pre názornosť si uveďme príklad:
Majme databázu FINANCIE a v nej tabuľku VYPLATY s dvoma stĺpcami ZAMESTNANECPLAT. Teraz nezáleží na type jednotlivých stĺpcov.

Predstavme si, že zrazu nastane fantastický deň, keď sa vedenie podniku rozhodne, že sa všetkým zamestnancom zvyšujú platy o 30 %. My ako programátori či obsluha systému musíme zabezpečiť túto úlohu. Zadáme príkaz, aby sa prepočítali všetky platy. Úloha beží, keď tu zrazu nastane neočakávaný výpadok servera! Po obnove servera dostávame nepravdivé informácie. Časť platov je zvýšená, zvyšok ešte nie. Ale ktoré sú to?
Práve transakcie zabezpečia, že dáta, nad ktorými úloha nie je z rôznych dôvodov úplne dokončená, sa vrátia do pôvodného stavu.
Preto našu úlohu budeme riešiť pomocou transakcie. V prípade podobného výpadku servera sa dáta vrátia do stavu pred spustením úlohy (teda nezmení sa ani jeden plat, pokiaľ nie sú zmenené všetky). V prípade, že nenastanú žiadne komplikácie, úloha sa správa ako bežná činnosť servera.
Transakčná činnosť je vnútorná činnosť databázového stroja, preto sa o ňu veľmi nemusíme starať. Stačí, ak príkazy našej úlohy uzavrieme medzi transakčné príkazy BEGIN TRANS, COMMIT alebo ROLLBACK TRANS.
MySQL už v posledných verziách podporuje transakcie, ale iba na tabuľkách typu InnoDB. V bežne používanom type MyISAM transakcie nefungujú. Treba priznať, že sú iba v začiatkoch a ich kvalita sa bude zlepšovať.
Musíme si uvedomiť, že práve transakcie najviac zdržujú činnosť databázového stroja, teda ho podstatne spomaľujú.
ULOŽENÉ PROCEDÚRY. Uložená procedúra je postupnosť preložených (skompilovaných) príkazov SQL (presnejšie jazyka Transact SQL), uložených v databáze priamo na databázovom serveri.
Uložené procedúry ponúkajú mnoho výhod. Jednou z nich je možnosť odovzdávania parametrov. Zároveň zvyšujú bezpečnosť databázy – používateľ, ktorý nemá explicitné práva používať určitú tabuľku, môže s touto tabuľkou pracovať práve pomocou uložených procedúr.
Jedným z hlavných prínosov uložených procedúr je, že sú vykonávané oveľa rýchlejšie ako bežné príkazy.
Používanie uložených procedúr nemá v podstate nijaké nevýhody (okrem tej, že takéto procedúry musia byť pripravené dopredu a vopred uložené na serveri).
MySQL zatiaľ nemá možnosť uložených procedúr, dá sa však očakávať, že sa v najbližších verziách objavia (presnejšie by mali byť vo verzii 4.1).
MySQL server zatiaľ rieši tento nedostatok metódou tzv. používateľsky definovaných funkcií – user defined function – UDF. Sú to funkcie, ktoré musia byť napísané v jazyku C alebo C++.
KURZORY. Kurzory umožňujú pracovať s jednotlivými riadkami výslednej súpravy. Ich použitie sa veľmi podobá prechádzaniu výslednej súpravy pomocou objektov rozhrania API. Kurzor umožňuje programátorovi alebo správcovi databázy vykonávať na strane servera pomerne zložité operácie. Je to celkom praktická funkcia, ale práca s kurzormi vyžaduje hlbšie znalosti.
Nevýhodou kurzorov je ich slabý výkon, navyše sú značne pomalé. MySQL neobsahuje kurzory – a to je len dobre.
SPÚŠŤAČE. Spúšťač – trigger – je v podstate uložená procedúra, ktorá sa spustí automaticky ako reakcia na určitú akciu a ktorá slúži na zachovanie integrity databázy. Akcie, ktoré môžu spustiť spúšťač, sú príkazy UPDATE, DELETEINSERT.
Majme tabuľky KNIHYARCHIV_KNIH. Predpokladajme, že chceme, aby sa každý záznam odstránený z tabuľky KNIHY uložil do tabuľky ARCHIV_KNIH.
Namiesto toho, aby sme pridávali zložitý kód do aplikácie, ktorá záznam odstráni a presunie do druhej tabuľky, alebo aby sme volali uloženú procedúru ručne, môžeme použiť spúšťač. Ten sa automaticky spustí pri každom odstránení záznamu z tabuľky KNIHY a jeho úlohou je odstraňovaný záznam uložiť do tabuľky ARCHIV_KNIH.
Spúšťače majú celý rad výhod. Uľahčujú zachovávanie referenčnej integrity a využívajú sa na zaistenie platnosti relácií medzi záznamami zviazaných tabuliek. Práve preto, že sú spúšťané automaticky ako dôsledok inej akcie, môžu slúžiť ako nástroj automatickej údržby databázy.
Ďalšou zaujímavou vlastnosťou spúšťačov je kaskádový efekt. K tomu dochádza, keď spúšťač spustený ako dôsledok určitej udalosti v jednej tabuľke vyvolá spustenie iného spúšťača, ktorý zase reaguje na príslušnú udalosť vo svojej tabuľke. To môže byť na jednej strane veľmi užitočné, ale na druhej strane aj veľmi nebezpečné.

Majme tabuľky OBCHODY, kde vedieme obchodnú činnosť, OBJEDNÁVKY, kde evidujeme objednávky jednotlivých zákazníkov, a OPERACIE, kde sú evidované všetky obchodné operácie v súvislosti s objednávkami. Predpokladajme, že chceme odstrániť všetky záznamy v tabuľke OBCHODY, ktoré sa viažu ku konkrétnemu zákazníkovi. Namiesto toho, aby sme tvorili špeciálny program v našej aplikácii, ktorý by po danom zákazníkovi „upratal“, použijeme spúšťač. Vytvoríme taký spúšťač, ktorý odstráni všetky záznamy v tabuľke OBJEDNAVKY viazané na odstraňovaného zákazníka. A k tabuľke OBJEDNAVKY môžeme pripojiť ďalší spúšťač, ktorý odstráni všetky obchodné operácie spojené s odstraňovanými záznamami o objednávkach v tabuľke OPERACIE.
Uvedomme si, že spúšťače sú uložené na strane servera, ich kód je v pamäti systému a spúšťajú sa automaticky!
Preto ich vôbec nemusíme volať v zdrojovom kóde našej aplikácie!
Nevýhodou spúšťačov je fakt, že spomaľujú a zaťažujú systém. Pri každej operácii nad danou tabuľkou sa musí databázový stroj presvedčiť, či sa na danú akciu neviaže niektorý spúšťač. Ak áno, musí ho spustiť a vykonať. Táto činnosť blokuje čas procesora a tým čas celého systému.
MySQL nemá možnosť použiť spúšťače. Môžeme to však obísť dobrým návrhom databázy a následných aplikácií. Najlepšie je zaisťovať integritu databázy priamo v kóde aplikácií. Upratujme po sebe v dátach a nebudeme potrebovať spúšťače!
(No musím priznať, že by som takúto funkciu v MySQL privítal. V prípade, že by som ju nechcel používať, dal by som to serveru pri spustení najavo nejakým prepínačom, aby sa značne zrýchlil. A keď by som ich v inej aplikácii potreboval, tak by som ich zase „zapol“).
Podľa vyjadrenia autorov MySQL triggermi sa budú zaoberať od verzie 4.1 vyššie.

OBMEDZUJÚCE PRAVIDLÁ. Obmedzujúce pravidlo (constraint) je spôsob, ako vynútiť dodržiavanie pravidiel zaistenia platnosti relácií medzi záznamami zviazaných tabuliek. Existuje niekoľko typov obmedzujúcich pravidiel, ale všetky majú spoločný cieľ – zaistenie referenčnej integrity.
Predstavme si pole tabuľky alfanumerického typu, ktoré by malo obsahovať iba písmená. Môžeme nastaviť obmedzujúce pravidlo, ktoré používateľovi zabráni vložiť akékoľvek číslo! A tento kód nemusíme implementovať na strane aplikácie, ale priamo na serveri.
Obmedzujúce pravidlá však veľmi zaťažujú systém, a preto sa v MySQL nenachádzajú. Zaistenie integrity dát je teda úplne v rukách programátorov a správcov databázy.

OPTIMALIZÁCIA BEHU SYSTÉMU. Veľmi často (teda skoro vždy!) sa stáva, že po určitej dobe funkčnosti nášho dobrého projektu opadne počiatočné nadšenie a programátori a používatelia sa začnú sťažovať na pomalosť celého systému. Preto bude potrebné pristúpiť k optimalizácii systému, čím dosiahneme určité zrýchlenie.
Faktorov spomaľujúcich samotnú rýchlosť systému je niekoľko a spravidla vždy sa v zmysle Murphyho zákonov spájajú do tej najhoršej kombinácie.

Činnosti eliminujúce tieto faktory si môžeme rozdeliť do týchto skupín:

  • dolaďovanie výkonu databázy
  • zostavovanie lepších dopytov SQL
  • uvoľňovanie nevyužitého priestoru
  • úprava a kompilácia zdrojových kódov servera

DOLAĎOVANIE VÝKONU DATABÁZY. Jedným z prvých faktorov, na ktorý by sme sa mali zamerať, je samotný systém. Na akom type počítača je spustený náš databázový server? Koľko pamäte má k dispozícii? Aký rýchly je procesor? A disk?
Samozrejme, že najlepšie by bolo, keby bol databázový server spustený na samostatnom stroji najmodernejšej konštrukcie s čo najlepšími parametrami. Ale sami vieme, že to nie je vždy možné, a preto treba pristúpiť k rozumným kompromisom.
Našťastie MySQL (na rozdiel od iných databázových strojov) nemá veľmi vysoké nároky na hardvér. Asi najviac ho bude „tlačiť“ veľkosť operačnej pamäte. To preto, lebo MySQL je viacvláknový systém. Pri nadviazaní spojenia s klientom je vytvorené nové vlákno – podproces, ktorého úlohou je plniť požiadavky klienta. Každé vlákno požaduje určitú časť operačnej pamäte. Takže čím viac pamäte, tým lepšie! Systém s väčšou operačnou pamäťou býva výkonnejší.
Ak teda musíte voliť medzi rýchlejším procesorom alebo väčšou pamäťou, siahnite po pamäti!
Ďalšia oblasť, ktorá ovplyvňuje výkon databázového servera, je pevný disk. Rýchlejší disk zaručuje rýchlejšie výsledky. Optimálne by bolo uložiť tabuľky na samostatný disk.
Asi najpodstatnejším faktorom v tejto téme je použitý operačný systém. Databáza MySQL je vypracovaná a priori pre systém Linux, a tak na tomto systéme dosahuje podstatne lepšie výsledky, ako keby sme ju používali v systéme MS Windows. Vyplýva to z koncepcie prideľovania pamäte jednotlivým procesom operačným systémom.

SYSTÉMOVÉ PREMENNÉ. Ak máme najlepší hardvér alebo už lepší nezískame, mali by sme sa trochu pohrať s databázovým systémom. Výkon systému riadi mnoho systémových premenných.
Ak zadáme príkaz:
mysqladmin -p variables

po zadaní rootovského hesla získame výpis systémových premenných, ktoré sú prednastavené pri behu démona (služby) mysqld.
Jednotlivé premenné môžeme zmeniť a tým značne vyladiť beh servera.
Takisto zadaním parametrov pri spustení mysqld dosiahneme zlepšený behu systému.

ZOSTAVOVANIE LEPŠÍCH DOPYTOV SQL. Ďalším boľavým miestom pomalosti systému sú príkazy SQL, ktoré pristupujú k dátam. Preto pri návrhu databázy budeme dodržiavať tieto najzákladnejšie pokyny:

  • Používajme čo najmenšie dátové typy. Čím menší dátový typ, tým menej miesta potrebuje na disku, ale aj v pamäti.
  • Stĺpce by nemali obsahovať prázdne hodnoty.
  • Vyhýbajme sa poliam premennej dĺžky.
  • Nepoužívajme priveľa indexov. (Preštudujme si kapitoly o indexoch!)
  • Typ tabuľky určujme vzhľadom na jej budúci výkon. Táto schopnosť sa dá dosiahnuť iba praxou.
  • Používajme implicitné hodnoty.
  • Zostavujme dopyty tak, aby v maximálnej miere používali indexy.
  • Používajme vo výpisoch výsledkov kľúčové slovo LIMIT.
  • Venujme pozornosť klauzule WHERE.

Na tému WHERE by sa dala napísať celá kniha (aj sú naozaj napísané!). Verte, dobre vytvoriť správny dopyt je naozaj umenie!
UVOĽŇOVANIE NEVYUŽITÉHO PRIESTORU. Po zmazaní niektorého záznamu v tabuľke zostáva tzv. hluché miesto. Toto sa v súbore tabuliek kumuluje a tým zaberá zbytočne miesto na disku. Aby sme odstránili tieto hluché miesta, použijeme príkaz myisamch, ktorého použitie sme si už vysvetľovali nedávno.
PREKLAD A KOMPILÁCIA ZDROJOVÝCH KÓDOV SERVERA. Väčšina z nás na začiatku svojej práce s týmto produktom využila pri inštalácii predkompilované súbory, či už vo verzii tgz, rpm, alebo exe. Tieto predkompilované súbory sú nastavené tak, aby fungovali pre čo najširší záber úloh.
Ak však chceme podstatne zlepšiť činnosť MySQL, odporúčam preložiť server zo zdrojových kódov vrátane nastavenia príslušných parametrov ešte pred kompiláciou.
V prípade Linuxu to nie je až taký problém, zatiaľ čo neviem o nikom, čo by kompiloval verziu pre MS Windows.

ZÁVER. ZÁVER? Toto je skoro posledná časť seriálu Malé veľké databázy. Posledná preto, lebo seriál v tejto podobe sa naozaj končí. A skoro preto, lebo sa predsa len občas stretneme – na základe vašich mailov a otázok občas pripravím malú „prednášku“ o rôznych fintách a novinkách tejto vynikajúcej databázy.
POHĽAD SPÄŤ. Pamätáte sa na to, keď sme začínali?
Nemali sme o databázach žiadne vedomosti. Prešli sme úplnými základmi (1. séria), vytvorili sme prvé funkčné aplikácie, ktoré boli „oknoidné“, či už sme použili MS Excel, WWW server Apache a PHP, alebo sme ich naprogramovali v Borland Delphi a povedali sme si zásady správneho návrhu aplikácií (2. séria).
V 3. sérii sme si povedali niečo o indexoch, kľúčoch a zámkoch. Venovali sme sa bezpečnosti, archivácii dát a ich obnove, o opravách poškodených tabuliek a o replikácii a teraz o vyladení systému.

PROMÓCIE. Prešli sme školou databáz – od základnej cez strednú až po vysokú. A preto tí, ktorí prešli a zvládli celý tento seriál, získavajú titul DBDr. – DataBase Doctor, teda doktor databázológie. Otvorme šampanské, vypusťme svetlice, vystískajme kamošky!
Ale nezaspime na vavrínoch!

A nakoniec len pre zaujímavosť: Tento seriál obsahuje:

  • 165 knižných strán
  • 8546 riadkov
  • 56 088 slov
  • 372 276 znakov
  • 194 obrázkov, výpisov alebo grafov
  • v  26 kapitolách

A to je, myslím, pomerne dosť.
Nech sa nám darí vo svete databáz!

P. S.: Mám rád databázy všeobecne, mám rád túto báječnú databázu a mal som rád aj tento seriál. Asi mi bude za ním smutno...
Ale vraj sa hovorí, že kde sa jedno končí, tam sa iné začína. Takže hádam predsa len – niekedy dovidenia!


Nechajte si posielať prehľad najdôležitejších správ emailom

Mohlo by Vás zaujímať

Ako na to

Ako zbaviť fotky hmly

08.12.2016 11:59

Hmla alebo dym sú často veľmi kreatívne nástroje. No všetkého veľa škodí. Fotka potom stráca kontrast a v podstate na nej nič nevidieť. Hmlu môžete neraz následnými úpravami odstrániť alebo zredukovať ...

Ako na to

Užitočné SW nástroje

08.12.2016 11:53

AllDup v4.0.3 Určenie: program na vyhľadávanie a odstraňovanie duplicitných súborov Vlastnosti: duplicitné súbory sa vyhľadávajú len na zvolených diskových jednotkách alebo len v rámci vybraných ...

Ako na to

Fotografovanie s bleskom

08.12.2016 11:47

Ak máte moderný fotoaparát so vstavaným alebo externým bleskom, zdá sa vám téma článku triviálna. Jednoducho nastavíte vhodný režim, vyberiete najlepšiu kompozíciu záberu, exponujete a o zvyšok sa už ...

Žiadne komentáre

Vyhľadávanie

Kyocera - prve-zariadenia-formatu-a4-s-vykonom-a3

Najnovšie videá