DB2 Flashcards
PL/SQL
• PL/SQL - Procedural Language/SQL
• PL/SQL rozšiřuje SQL o konstrukce s procedurálního programování.
• Doplňuje SQL, nikoliv nahrazuje.
– PL/SQL kombinuje možnosti deklarativního a imperativního programování.
Kurzory
- Privátní pracovní oblasti, které jsou databázovým serverem vytvořeny pro každý příkaz SQL.
- Kurzory jsou v podstatě ukazatele do paměti, ne přímo do dat. Výsledné záznamy dotazu jsou do paměti vloženy ve chvíli otevření kurzoru.
- V podstatě se jedná o mechanismus, kdy SELECT příkazu přiřadíme jméno, přes které pak můžeme manipulovat s daty získanými příkazem.
- Implicitní kurzory jsou vytvářeny automaticky databázovým serverem, není nutné je otevírat, zavírat, deklarovat nebo z něj načítat data,
- Explicitní – deklarované programátorem
Základní kroky pro práci s explicitními kurzory:
- Deklarace kurzoru
- Otevření kurzoru
- Výběr dat prostřednictvím kurzoru
- Uzavření kurzoru
Explicitní kurzory - syntaxe, testování stavu, + podívat se na příklad
- Deklarace kurzoru CURSOR IS <p>; - Otevření kurzoru OPEN ; - Výběr dat prostřednictvím kurzoru (opakovat v cyklu) FETCH INTO ; - Uzavření kurzoru CLOSE ;
Pro testování stavu kurzoru jsou k dispozici atributy %ROWCOUNT Zjištění pořadového čísla aktuálního záznamu (pokud nebyl vybrán žádný, je hodnota 0) %FOUND Pokud poslední příkaz FETCH načetl nějaký záznam, má atribut hodnotu TRUE Používá se pro zjišťování konce cyklu %NOTFOUND Používá se pro zjišťování konce cyklu %ISOPEN Pokud je kurzor otevřen, má hodnotu TRUE Použití: %ROWCOUNT</p>
Práce s implicitními kurzory
a) Příkaz SELECT … INTO … FROM … musí vrátit alespoň jeden a nejvýše jeden řádek, počet sloupců musí odpovídat počtu proměnných uvedených za klauzulí INTO včetně použitelnosti datových typů.
b) Následující příklad ukazuje využití implicitního kurzoru pro sady výsledků s omezeným počtem řádků (řekněme méně než 100)
BEGIN
FOR x IN (SELECT jmeno, Id FROM trpaslici)
loop
DBMS_OUTPUT.PUT_LINE(‘Jméno ‘ || x.jmeno || ‘, Id ‘ || x.Id);
END LOOP;
END;
Explicitní vs. implicitní kurzory
- Implicitní kurzory jsou obecně výkonnější.
- Implicitní kurzory jsou z pohledu kódu úspornější a automatizují operace OPEN, CLOSE, FETCH a EXIT WHEN .. %NOTFOUND explicitního kurzoru.
- Nehrozí opomenutí EXIT WHEN, což má za následek uváznutí v nekonečné smyčce.
- Explicitní kurzory lze předávat parametrem mezi jednotlivými procedurami/funkcemi.
- Využívá se při tom datový typ SYS_REFCURSOR.
- Větší flexibilita než implicitní kurzory.
Záznamy
Struktura typu záznam zapouzdřuje více položek i rozdílných datových typů. Deklarace záznamu DECLARE TYPE IS RECORD ( [, …] ); Příklad DECLARE TYPE rec_ucitel IS RECORD ( jmeno ucitel.jmeno%TYPE, Id ucitel.Id%TYPE ); Nebo po zjednodušení jen DECLARE rec_ucitel ucitel%ROWTYPE;
Práce s kurzory a záznamy
DECLARE
rec_trpaslik a_snehurka.trpaslici%ROWTYPE;
CURSOR k1 IS SELECT jmeno, Id FROM a_snehurka.trpaslici;
BEGIN
OPEN k1;
LOOP
FETCH k1 INTO rec_trpaslik.jmeno, rec_trpaslik.id;
EXIT WHEN k1%NOTFOUND;
DBMS_OUTPUT.PUT_LINE(‘Jméno ‘ || rec_trpaslik.jmeno || ‘, Id ‘ || rec_trpaslik.Id);
END LOOP;
CLOSE k1;
END;
S využitím záznamů můžeme s kurzory pracovat mnohem efektivněji
Cyklus FOR s explicitním kurzorem
(kurzor v tomto případě nemusíme ani otevírat ani zavírat, dokonce ani cyklicky vybírat data pomocí příkazu FETCH, všechny tyto úkony za nás provede server standardně)
Příklad
DECLARE
rec_ucitel ucitel%ROWTYPE;
CURSOR k1 IS
SELECT jmeno, Id FROM ucitel;
BEGIN
FOR rec_ucitel IN k1
LOOP
DBMS_OUTPUT.PUT_LINE('Jméno ' || rec_ucitel .jmeno || ', Id ' || rec_ucitel.Id);
END LOOP;
END;
Kurzory s parametry
Kurzor můžeme rozšířit o parametry, které budou dosazeny do dotazu až během otevření kurzoru
Deklarace explicitního kurzoru s parametrem
CURSOR [( , … )] IS <p>;
Příklad
DECLARE
rec_ucitel ucitel%ROWTYPE;
CURSOR k1 (v_jmeno VARCHAR2) IS
SELECT jmeno, Id FROM ucitel WHERE jmeno LIKE (v_jmeno || '%');
BEGIN
FOR rec_ucitel IN k1 (‘Za’)
LOOP
DBMS_OUTPUT.PUT_LINE('Jméno ' || rec_ucitel .jmeno || ', Id ' || rec_ucitel.Id);
END LOOP;
FOR rec_ucitel IN k1 (‘Sm’)
LOOP
DBMS_OUTPUT.PUT_LINE('Jméno ' || rec_ucitel .jmeno || ', Id ' || rec_ucitel.Id);
END LOOP;
END;
</p>
Ošetření chyb PL/SQL
V zásadě se mohou v PL/SQL vyskytnout 2 druhy chyb:
Syntaktické – projeví se ještě v procesu kompilace (upozorní nás na ně překladač)
Run-time – projeví se až za běhu programu
Nejčastěji se vyskytují následující výjimky:
DUP_VAL_ON_INDEX výskyt duplicitní hodnoty ve sloupci, který připouští jen jedinečné hodnoty
INVALID_NUMBER neplatné číslo nebo data nemohou být převedena na číslo
NO_DATA_FOUND nebyly nalezeny žádné záznamy
TOO_MANY_ROWS dotaz vrátil více než jeden záznam
VALUE_ERROR problém s matematickou funkcí
ZERO_DIVIDE dělení nulou
+ všeobecná syntaxe (a RAISE (ten může i vlastní výjimky))
+ obsluha výjimky
+ chyba má SQLCODE a SQLERRM
+ nezachycené výjimky jsou propagovány výš a výš až do hostitelského prostředí
Procedury a funkce
Bloky příkazů jazyka PL/SQL lze pojmenovat a uložit ve spustitelné formě do databáze. Těmto blokům říkáme procedury, resp. funkce.
Vlastnosti procedur a funkcí:
Jsou uloženy ve zkompilovaném tvaru v databázi.
Mohou volat další procedury či funkce, či samy sebe.
Lze je volat ze všech prostředí klienta.
Funkce, na rozdíl od procedury, vrací jedinou hodnotu (procedura může vracet hodnot více, resp. žádnou).
+ syntaxe
+ parametry, vstupní, výstupní, vstupně-výstupní
Aktivní pravidla
aktivní pravidla (active rules)
◦ pro vyhodnocení složitých podmínek kladených na data (tzv. business rules)
◦ kontrola na databázové úrovni
◦ usnadnění práce – auditovatelnost, bezpečnost
triggery (triggers) ◦ v překladu „spoušť“ , „kohoutek“ ◦ jiný název pro aktivní pravidla ◦ v praxi je dávána přednost názvu trigger AKTIVNÍ PRAVIDLA = TRIGGERY
• Trigger („spoušť“) je “procedura”, která se spustí při
výskytu nějaké sledované události.
• V relačních databázích trigger = aktivní pravidlo
• Od SQL 1999
Vs. integritní omezení (ty jsou jednodušší, rychlejší, ale ne vždy postačující, nejsou auditovatelné)
Starburst
• IBM, Almaden Research Center -> Starburst Active Rule System • Získalo popularitu -> Jednoduchá syntaxe a sémantika -> Množinově orientovaná • Pravidla založena na ECA-paradigmatu (Event-Condition-Action)
• Událost (Event)
-> SQL-příkazy pro manipulaci s daty (INSERT, DELETE,
UPDATE)
• Podmínka (Condition)
-> booleovský predikát nad stavem databáze, vyjádřen pomocí SQL
• Akce (Action)
-> provádí libovolné SQL dotazy (například SELECT, INSERT, DELETE, UPDATE)
-> navíc mohou obsahovat příkazy pro manipulaci s aktivními pravidly a transakční instrukci ROLLBACK WORK
Sémantika aktivních pravidel
• Když nastane Událost, pokud je splněna Podmínka, proveď Akci.
Říkáme, že pravidlo je:
• spuštěno (triggered) – pokud nastane příslušná Událost
• vyhodnoceno (considered) – po vyhodnocení dané
Podmínky
• vykonáno (executed) – po provedení jeho Akce
Vlastnosti aktivních pravidel
• Jsou přidané do schématu databáze a jsou sdílené všemi aplikacemi.
• Mohou být dynamicky aktivovány a deaktivovány každou transakcí.
• Mohou tvořit skupiny.
• Každé pravidlo ve Starburstu má jedinečné jméno a je spojeno s jednou určitou tabulkou, zvanou rule’s target.
• Každé aktivní pravidlo může sledovat více Událostí, tzv. rule’s triggering operations.
• Jeden SQL příkaz může být sledován více pravidly.
-> Pořadí pravidel je určeno na základě jejich částečného uspořádání.
Problémy s triggery
• standardizace
- > není
- > snaha by byla od 80. let v normě SQL-92 nejsou standardně uvedeny
- SQL 1999 – základní podmínky realizace, ale …
- proprietární řešení výrobců DB systémů
- > rozdíly v syntaxi i sémantice
- > vazba aplikace na konkrétního výrobce
• technické problémy
- > nekonečné vzájemné volání triggerů (retriggering)
- > několik možných řešení
- > používají se všechna
Triggery v PL/SQL
- Jedná se o PL/SQL objekty spouštěné vyvoláním příslušné události v DB
- Vyvolání může způsobit DML událost, DDL operace nebo speciální DB událost
- Vyvolat trigger můžeme před nebo po provedení operace
- Existuje také možnost vyvolání místo příslušné operace
- Je možné omezit vyvolání podmínkou
+ DML triggery (delete, insert, update)
+ DML triggery vyvolání pro celou operaci / for each row / sloučením OR
Syntaxe DML triggeru:
CREATE OR REPLACE TRIGGER jméno BEFORE | AFTER | INSTEAD OF DELETE | INSERT | UPDATE OF cols ON tabulka [ způsob odkazování ] [ FOR EACH ROW ] [ WHEN ( podmínka ) ] AS pl/sql kód
Způsob odkazování • Definuje, jak budou přístupné původní a nové záznamy (vstupující do DML operací) • Implicitně :new, :old, :parent • Existuje klauzule: REFERENCING [ OLD AS jméno ] [ NEW AS jméno ] [ PARENT AS jméno ]
- Pro BEFORE a AFTER je trigger chápán jako tzv. statement trigger a vyvolán je pouze jedenkrát (není-li klauzulí FOR EACH ROW explicitně stanoveno jinak)
- V případě INSTEAD OF triggeru je trigger implicitně chápán jako řádkový trigger, protože zde statement trigger nemá prakticky žádný význam
DDL triggery
• Jsou vyvolány po provedení DDL příkazu • Mohou být BEFORE, AFTER • Mohou být omezeny podmínkou (WHEN) • Definují se dvěma způsoby: ->jméno události ON DATABASE -> jméno události ON jméno schématu • Existuje řada definovaných událostí, např. CREATE, ALTER, DROP, RENAME, GRANT, COMMENT, AUDIT, DDL
Triggery databázových událostí
- Pracují stejně jako DDL triggery, pouze je jiná množina povolených událostí
- Typicky se jedná o události zásadních událostí v celé databázové instanci, např. STARTUP, SHUTDOWN, LOGON, LOGOFF, SERVERERROR, SUSPEND apod.
- Uvnitř DDL a databázových triggerů nelze provádět jiné DDL operace
- Velmi specifické použití
Omezení triggerů
- BEFORE a AFTER triggery nelze specifikovat nad pohledy
- V BEFORE triggerech není možné zapisovat do :old záznamů
- V AFTER triggerech nelze zapisovat ani do :old, ani do :new záznamů
- INSTEAD OF triggery pracují jen s pohledy, mohou číst :old i :new, ale nemohou zapisovat ani do jednoho
- Nelze kombinovat INSTEAD OF a UPDATE
- Nelze definovat trigger nad LOB atributem
- Nelze použít transakce, pokud je zpracovávána jiná transakce (tedy prakticky nelze použít transakce vůbec)
- Není možné sledovat (ani modifikovat) data v tabulce, která způsobila vyvolání DML triggeru – toto omezení je často velice nepříjemné
- Jediné známé řešení: zrcadlení tabulek
Emulace AUTOINCREMENT
- Některé SQL databázové systémy používají modifikátor typu AUTOINCREMENT pro definici číslování primárních klíčů
- Je možné toto chování emulovat umístěním BEFORE INSERT triggeru, který vyčte novou hodnotu ze sekvence a modifikuje :new.id na tuto hodnotu
Základní možnosti uložení XML dat
- Uložení v systému souborů
- Uložení v relační databázi
- Uložení v objektově orientovaném systému
- Uložení v objektově-relačním databázovém systému
- Nativní XML úložiště
Uložení xml v systému souborů
1) konstrukce celých DOM stromů
- > nutnost držet celý dokument v paměti
- > nutnost analyzovat celý text
2) možnost značkování, abychom se vyhnuli nevýhodám
- > zbytečně složité, nemožná aktualizace
Uložení xml v relační databázi
1) buď xml jako LOB
- snadná implementace
- s xml se musí pracovat jako s celkem
2) xml dokument se rozloží do několika tabulek
- dekompozice xml dokumentu do relačního modelu
- relační model špatně hierarchickou strukturu => je to pomalé
- některé dotazy rychlé převedením na SQL dotaz
a) Uložení hran stromu
b) Odvození schématu z DTD
Uložení hran stromu xml do relačních tabulek
• Id uzlu získané preorder průchodem
• Hrana: pětice
(výchozí ID, cílové ID, značka, pořadí, vložený obsah)
• Elementy se smíšeným obsahem jsou modelovány jako stromy s více textovými elementy
• Nula ve sloupci cílového ID značí, že uzel je atribut
• Doporučuje se index: (značka, data),
(výchozí ID, ordinál), (ID cíle)
• Uložení pomocí hran je poměrně neúporné
• Možnost zrušení sloupce se značkou a rozdělení do více relačních tabulek
• Zbavíme se tím ale možnosti ukládat libovolná XML data
• Se stovkami relačních tabulek se RDBMS hůře vypořádá
Odvození schématu z DTD pro uložení xml do relačních tabulek
• DTD (Document Type Definition, česky Definice typu dokumentu) je jazyk pro popis struktury XML případně SGML dokumentu.
Omezuje množinu přípustných
• Tabulky se generují od kořene DTD
• Každé n-tici je přiřazen unikátní identifikátor a vyplněn sloupec identifikující rodičovský element
• Elementy bez vícenásobného výskytu jsou vloženy přímo jako další sloupce do tabulky rodičovského elementu
• Problém: zkoumání vztah předek-potomek
-> Mnoho operací join
-> Problém s dokumenty s cyklickým DTD – hluboké hnízdění SQL dotazů, případně potřeba nějakého (např. procedurálního) rozšíření dotazovacího jazyka
• Netriviální převod XQuery -> SQL
Uložení xml v objektově-relační databázi
- Využívá ADT, abstraktní datové typy
- Obvykle je vyžadováno DTD
- Podobné strukturálnímu uložení do RDBMS
- Problém s rekurzivními strukturami, smíšenými elementy, problematické složitější modelové skupiny DTD
Nativní uložení xml
• Zcela přizpůsobeno stromové struktuře XML dat
• Výhody
+ Rychlost, flexibilita
+ Snadné a efektivní XML dotazování
• Nevýhody
- Nutnost vybudování zcela nových datových struktur a metod pro vyhodnocení dotazů
Oracle + XML
SŘBD Oracle podporuje XML formát od verze 10g.
• Zavádí datový typ XMLType, kterým lze buď:
-> definovat strukturu tabulky (OF XMLType),
-> nebo určit datový typ jednoho daného atributu tabulky
Oracle SQL Developer a XMLType
• Oracle SQL Developer komunikuje s databází Oracle prostřednictvím JDBC ovladače, který je součástí distribuce produktu. Obecně platí, že společnost Oracle distribuuje v jediném archivu (např. ojdbc6.jar) dva JDBC ovladače.
Thin
• tenký ovladač, vystačí si jen s metodami implementovaným v daném archivu, obvykle postačuje pro základní komunikaci s Oracle databází.
OCI/Thick
• tlustý ovladač, který vyžaduje další instalované knihovny
• knihovny jsou dostupné přes systémovou proměnnou OracleHome (uchovává cestu k instalované produktu, kterým může být Oracle Client (může být i instantní), případně celý Oracle Database Server).
Vložení XML dokumentu do databáze
Existuje několik způsobů:
A) S dodatečnými oprávněními
- Nejobvyklejší způsob předpokládá, že na serveru (stejný stroj, kde běží databázový stroj) vytvoříme/vyhradíme adresář, který musíme v databázi zaregistrovat příkazem CREATE DIRECTORY.
- Tento způsob vyžaduje dodatečná oprávnění, která běžný uživatel nemá přidělena a mít nebude.
- Do zmíněného adresáře je nutno umístit XML soubory, které chceme do databáze uložit.
- Jejich uložení provést příkazem INSERT
B) bez potřeby výše zmiňovaných oprávnění.
- Formulace příkazu INSERT, který do připravené tabulky vloží nový záznam (tj. XML soubor) jako objekt vytvořený implicitním konstruktorem typu XMLType - v případě použití Oracle SQL Developeru využívajícího tlustého JDBC ovladače to lze provést nahráním obsahu zvoleného souboru při vyplňování pole obsahující XML soubor.
- Do databáze se neukládá příslušný název ukládaného XML souboru, to je nutno v případě potřeby vytvořit explicitně.
Klasický x Temporální databázový systém
Čas je potřeba uchovat a pracovat s ním:
Klasický databázový systém
- > Zachycuje stav systému v daném okamžiku
- > Jak pracovat se starými daty?
Temporální databázový systém
- > Podporuje práci s časem – zohledňuje časové vlastnosti vkládaných dat
- > Jednodušší dotazy přes časová období
Případová studie temporální databáze
1) Databáze zaměstnanců
=> Zamestnanec(Jmeno, Plat, Titul)
2) Přidáme do záznamu datum narození
=>Zamestnanec(Jmeno, Plat, Titul, DatumNarozeni DATE)
3) Nyní chceme přidat záznam o vývoji v zaměstnání
=> Zamestnanec(Jmeno, Plat, Titul, DatumNarozeni,
Start DATE, Stop DATE)
a) Potřebujeme zjistit hisotrii platů zaměstnanců
b) Potřebujeme zjistit maximální dobu, kdy měli stejný plat
=> V SQL obtížné
=> Koalescence
Temporální databáze - důvod
- Data závislá na čase jsou běžně využívána
- Práce s časově závislými daty je běžná, potřebná.
- Velmi malá podpora klasických databází ==> temporální databáze a databázové systémy.
- Netemporální databáze nemají dostatečnou podporu pro práci s těmito údaji
- Temporální databáze umožňuje jednodušší dotazy
Časová doména
- Modelování a reprezentace času
- Čas v temporální logice = libovolná množina okamžiků s částečným uspořádáním
•Další axiomy model upřesňují
- > Lineární – uspořádání celé množiny
- > Větvení – lineární do teď, pak možné budoucnosti
- > Cyklický – rekurentní proces (týden)
• Axiomy mohou charakterizovat hustotu
• Diskrétní modely – isomorfní přirozeným číslům
-> každý bod v čase má jednoho předchůdce
• Husté modely – isomorfní racionálním nebo reálným
číslům
-> mezi každými dvěma momenty existuje další
• Průběžné modely – isomorfní reálným číslům
- V průběžném modelu každé reálné číslo odpovídá bodu v čase
- V diskrétním modelu každé přirozené číslo odpovídá nedělitelné jednotce času s libovolným trváním – chronon
- Chronon není bod, ale úsečka
Obvykle se používá diskrétní model
• nepřesnost měření
• přirozenost v jazyce
• přirozená modelace událostí, které trvají
Další axiomy:
• Omezení
• Koncept vzdálenosti
• Relativní a Absolutní čas
Datové typy času
• okamžik – specifický chronon
• událost – něco, co se stalo v daném okamžiku
• doba události – okamžik, kdy se událost stala ve
skutečnosti
• SQL92 – DATE, TIME, TIMESTAMP
• časová perioda – čas mezi dvěma okamžiky
-> neplést s typem INTERVAL
- časový interval – známý časový úsek, ale nemá specifické hraniční okamžiky
- množina okamžiků
- temporální elementy – konečné sjednocení period
Vztah události a času
2 ortogonální dimenze:
1) Čas platnosti (valid time)
- Doba, kdy byla událost v realitě pravdivá – kdy se stala
- I v budoucnosti
2) Transakční čas (transaction time)
- Doba, kdy byla událost reprezentovaná v DB
- Pouze minulost a současnost
Událost a čas – datové modely
1) Snapshot
2) Transaction-time model
3) Valid-time model
4) Bitemporální model
Snapshot (temporální databáze)
- Nepodporuje ani čas platnosti ani transakční čas
- Klasický relační model
- Při změně reality se mění stav relace (vložení, odebrání, změna prvků)
- snímek – nepodporuje ani jeden model, okamžik v databázi
Transaction-time model
Podporuje pouze transakční čas Posloupnost snapshotů indexovaných transakčním časem Nemění existující data Append-only (snapshot) Hledání v minulosti
Transaction time – období, po které je fakt uložený v databázi
Transaction-time relace
• Snímek se neupravuje
• Dojde ke změně aktuálního snímku, který se poté přidá do relace
•Využitelné pro dotazy na stav databáze v minulosti
Valid-time model
Podporuje pouze čas platnosti
Dotazy i na fakta platná v budoucnosti
Možná úprava čehokoli
Valid time – čas, po který fakt byl/je/bude pravdivý.
- Uchovává platnost dat
- Kterákoliv část se dá upravit
- Nedá se určit předchozí stav databáze
Bitemporální model
Podporuje čas platnosti i transakční čas
4D: n-tice, hodnoty atributů, čas platnosti, transakční čas
append-only
• bitemporální čas – podporuje oba modely (valid a transcation)
- „append only“ jako transaction-time
- Platnost dat jako valid-time
- S rozvojem databáze transaction-time roste monotónně, ale valid-time může mít velký rozptyl
Flashback v Oracle
- Technologie flashback používá své flashback logy, undo segmentů a odpadkového koše.
- Jednoduše ji lze přirovnat k tlačítku Undo v textovém editoru, nastalý problém řešíte použitím akce „krok zpět“.
- Veškeré akce a změny provedené v databázi jsou označeny svým číslem SCN (system change number). V případě, že budete chtít změnu vrátit, udělat tzv. rollback, musíte stanovit, ke kterému SCN číslu se chcete vrátit.
- Flashback můžete použit na veškeré tabulkové prostory vyjma systémového.
- Flashback je rozdělen do různých oblastí podle akce, kterou chcete provádět.
Dotazovací jazyk – TSQL2
- TSQL2 byl navržen skupinou asi 18 badatelů, kteří už dříve samostatně navrhli mnoho různých temporálních dotazovacích jazyků.
- Cílem TSQL2 bylo sjednotit přístupy k temporálním datovým modelům a dotazovacím jazykům založeným na kalkulu a získat sjednocené rozšíření SQL-92 a datový model, nad kterým by mohl být založen další výzkum.
- TSQL2 bylo začleněno do vyvíjejícího se standardu SQL3.
Pojetí času
• Časová osa TSQL2 je na obou koncích omezena, ale dostatečně daleko (18 miliard let)
• U časových údajů jsou možné různé granularity
• Časové typy
• DATE, TIME, TIMESTAMP, INTERVAL, PERIOD
Datový model
• Je použit BCDM (Bitemporal Conceptual Data Model)
• Řádek relace je orazítkován množinou bitemporálních chrononů
• Bitemporální chronon je dvojice (chronon transakčního času, chronon času platnosti)
Časová ontologie TSQL
- Lineární časová struktura, omezená z obou stran (+-18 miliard let)
- diskrétní reprezentace reálného času, která může být považována za diskrétní, hustou nebo průběžnou
- granule – seskupení po sobě jdoucích chrononů – různá granularita
- nevyžaduje výběr mezi diskrétní, hustou nebo průběžnou ontologií
- Dokonce nedovoluje otázky, které by nutili rozhodnout mezi modely
- Nelze se ptát, zda okamžik A předchází okamžik B - pouze v rámci zvolené granularity (vteřiny, dny,…)
- Přidává datový typ PERIOD
Datový model temporálních databází
• jednoduchý
• zachovává obecnost a jednoduchost relačního modelu
• separátní modely pro prezentaci dat, ukládání dat a
vyhodnocování dotazů
• Více koordinovaných datových modelů zvládne co by
jeden nedokázal
Relační databáze v kontextu No SQL
• Data organizována do tabulek, řádek reprezentuje záznam. (koncept matematické relace, řádek prvkem relace nad doménami sloupců tabulky)
• Každý sloupec má přesně daný (jednoduchý) datový typ. (tj. množina/doména odpovídající části relace)
• Záznam v tabulce se může odkazovat na záznam
(jiné) tabulky. (hodnota cizího klíče odpovídá hodnotě primárního klíče odkazovaného záznamu)
- Organizace dat musí splňovat normální formy. (1NF, 2NF, 3NF, EKNF, BCNF, 4NF, 5NF, DKNF, 6NF1; jinak hrozí redundance/chyby)
- Dotazy a úpravy nad daty pomocí SQL. (dotazování pomocí SELECT vychází z relační algebry)
- Databázový systém zaručuje ACID změny uložených dat. (Atomicity, Consistency, Isolation, Durability)
Požadavky na moderní databáze
- cloud, distribuované databáze (decentralizace úložiště dat, úmyslná redundance pro odolnost proti výpadkům a rychlost, velké objemy dat a velké množství operací /big data/, atd.)
- problematické datové typy (údaje klíč-hodnota, objekty, nestrukturované dokumenty, RDF grafy, atd.)
- iterativní vývoj (časté změny schématu databáze nebo dokonce žádné schéma, různé/nejasné způsoby použití databáze, atd.)
- vysoké požadavky na škálovatelnost (mobilní zařízení jako klienti i úložiště/poskytovatelé dat, nerovnoměrné rozložení zátěže prostorově i časově, specifické požadavky na dostupnost, předem neznámé dotazy - nelze optimalizovat indexy, atd.)
Moderní relační databáze? (no sql kapitola)
- Snaha přizpůsobit relační databázi moderním požadavkům. (post-relační relační databáze /objektově-relační, s podporou XML, . . . /, univerzální datové modely, úmyslná denormalizace, zavádění cache, datové sklady, atd.)
- „Relační“ databáze přestává odpovídat relačnímu konceptu. (už ne matematické relace, ale spíše kolekce/množiny/grafy nestrukturovaných dat)
• Dodržování ACID nevhodně omezuje práci s databází.
(úmyslné zanedbání/odpuštění Atomicity, Consistency, Isolation nebo Durability pro zisk rychlosti a dostupnosti dat)
• Vznik specializovaných nerelačních (post-relačních)
databází:
– pro specificky strukturovaná data,
– (čistě objektové či XML databáze, úložiště tagovaných
dokumentů, atd.)
– pro specificky uložená/přistupovaná data.
(in-memory, embedded a real-time databáze či map-reduce zpracování dat)
Vznik NoSQL databází
- Webové aplikace - nová řešení více vyhovující těmto potřebám.
- Pro malá, často používaná data, se začaly využívat paměťové cache s jednoduchou architekturou klíčhodnota (key-value).
- Nejprve jako doplněk k tradičním relačním databázím, později se začalo experimentovat s rozhraním klíč-hodnota i pro perzistentní databáze.
- Úspěch - další experimentování přineslo nová řešení uspokojující požadavky na škálování, distribuovaná data, vysokou propustnost a spolehlivost.
- Výsledek - skupina databází označených jako NoSQL.
Termín NoSQL „Not only SQL“ databáze byl zvolen pro volně specifikovanou třídu nerelačních datových úložišť. …
• Někdy se pro tato datová úložiště používá i termín postrelační.
SQL a NoSQL databáze (terminologie)
Pojem SQL:
• Především relační a objektově-relační databáze používající jazyk SQL.
• Dlouhý vývoj - na velmi vysoké úrovni poskytovaných služeb i spolehlivosti.
• Transakční zpracování - silná konzistence dat.
• Je-li silná konzistence podmínkou zpracování – SQL databáze je správná volba, není důvod hledat jiné řešení.
Pojem NoSQL:
• Systém databází s možností horizontálního i vertikálního škálování.
• NoSQL databázový systém (nevyužívá tabulky, jako je tomu u relačních databází, v tomto případě je cílem jednoduchost vzhledu a možnost horizontálního i vertikálního škálování.
• NoSQL je optimalizovanou databází, kdy jsou využívány klíče i hodnoty.
• Struktura ukládání dat je u NoSQL rovněž odlišná, často se jedná o struktury stromovou nebo grafovou.
• NoSQL databázové systémy získávají na stále větší popularitě, především pokud hovoříme o segmentu real-time web.
• Dosud ale nejsou tolik rozšířené, což je dáno především absencí podpory transakčního modelu ACID či neúplnou standardizací rozhraní. Navíc jsou pro některé firmy NoSQL databáze dosti nákladné.
• Různá algoritmická složitost operací při SQL a NoSQL
Vlastnosti NoSQL
- Nerelační
- Jednoduché rozhraní API
- Distribuovanost
Nerelační vlastnosti NoSQL
- NoSQL databáze se nikdy neřídí relačním modelem
- Nikdy neposkytují tabulky s plochými záznamy v pevných sloupcích
- Práce se samostatnými agregáty nebo BLOB
- Nevyžadují objektově-relační mapování a normalizaci dat
- Žádné složité funkce, jako jsou jazyky dotazů, plánovače dotazů, spojení referenční integrity, ACID
- Databáze NoSQL jsou buď bez schématu nebo mají uvolněná schémata
- Nevyžadují žádnou definici schématu dat
- Nabízejí heterogenní struktury dat ve stejné doméně
Jednoduché rozhraní API NoSQL
- Nabízejí snadno použitelná rozhraní pro ukládání a dotazování poskytnutých dat
- API umožňují metody zpracování a výběru dat na nízké úrovni
- Textové protokoly většinou používané s HTTP REST a s JSON
- Většinou se nepoužívá žádný standardní dotazovací jazyk
- Webové databáze, které fungují jako internetové služby
Distribuovanost NoSQL
• Více distribuovaných databází NoSQL
• Nabízejí automaticky škálovatelnost a schopnost zamezit selhání
• Koncept ACID může být často obětován pro škálovatelnost a propustnost
• Většinou neexistuje žádná synchronní replikace mezi distribuovanými uzly
• Asynchronní Multi-Master replikace, peer-to-peer, replikace HDFS
• Pouze zajištění případné konzistence
• Sdílená architektura “nothing”. To umožňuje
menší koordinaci a vyšší distribuci.
• V NoSQL není “nothing” sdílené.
ACID
- Koncept ACID je základem transakčního zpracování dosud nejvíce rozšířených a používaných relačních databází.
- ACID - skupina vlastností, které zaručují spolehlivé provádění databázových transakcí a konzistenci dat.
Atomicity - série modifikací databáze uskutečňující se během transakce je provedena celá nebo je databáze ponechána v původním stavu. Systém musí garantovat toto chováni v každé situaci včetně nečekaných poruch.
Consistency – každá transakce převede databázi z jednoho konzistentního stavu do druhého. Do databáze budou zapsána pouze data odpovídající integritním omezením.
Isolation – data měněná transakcí jsou ostatním uživatelům až do úspěšného ukončení transakce viditelná v původní podobě, jako byla před začátkem transakce.
Durability – změny v databázi vyvolané úspěšně ukončenou transakcí jsou trvale uloženy na persistentním úložišti.
Partitioning
- Technologie sloužící v relační databázi k fyzickému rozdělení rozsáhlých datových tabulek do menších částí na základě logického členění dat v tabulce.
- Části jsou nazývány partition
- Tato technologie umožňuje rychlejší manipulaci s tabulkami, jejichž velikost se pohybuje na hranici možností použitých systémových prostředků.
- Prakticky (a nejčastěji) bývá realizován rozdělením tabulky na více pevných disků, což představuje rozložení zátěže oproti stavu, kdy všechny požadavky musel obsluhovat pouze jeden disk.
- Důvodem může být kromě velikosti dat také požadavek na větší rychlost.
- Podle jakého klíče k rozdělení dojde, dovoluje většina databázových strojů s podporou partitioning, určit pomocí rozdělení podle určitého sloupce nebo jeho hašovací funkce.
Prtitioning (dělení, vlastnosti)
Horizontální partitioning / Vertikální partitioning
Statický / Dynamický
Vlastnosti:
Užitečnost partitioningu vyplývá z možnosti pracovat
pouze s relevantní částí tabulky:
• Rozdělená tabulka se pak ukládá do více souborů, z nichž každý může být uložen na jiném disku - to je vhodné především u velkých tabulek jako jsou faktové tabulky v datovém skladu.
- Procesy, které hromadně mění data v tabulce, jsou řádově rychlejší - vycházejí ze způsobu členění tabulky do partitions - například u mazání starých dat (příkazem DELETE jazyka SQL) může být tento rozdíl oproti stejnému příkazu spuštěnému nad nerozdělenou velkou tabulkou až tisícinásobný.
- Agregační funkce spouštěné nad dělenou tabulkou může databázový server rozdělit podle rozdělení v definici partitioningu do více procesů, spustit každý takový proces na respektivním místě souborového systému, a nakonec získané mezivýsledky sloučit do celkového výsledku.
- Pokud to SŘBD dovoluje, může mít každá partition trochu jiné nastavení z pohledu její správy – dle příkladu u dynamického partitioningu je logické, aby partitions obsahující objednávky starší tří měsíců byly pouze pro čtení (read-only), což podstatně sníží časové a kapacitní nároky na zálohování celé tabulky.
- Podstatně se zvyšuje počet uživatelů, kteří mohou s tabulkou pracovat paralelně, aniž by se vzájemně omezovali - tato vlastnost se ještě umocňuje, pokud je databáze umístěna na víceprocesorovém serveru.
Horizontální partitioning
Rozděluje se na úrovni celých řádků. Využití: např. u rozsáhlých tabulek, u nichž se část dat (např. archiv článků) používá velmi zřídka a naopak u několika posledních řádků je požadavek na rychlý přístup (ty se pak umístí na nejrychlejší disk).
Vertikální partitioning
Partitioning se rozděluje podle sloupců tabulky, tj. sloupce tabulky mohou být uloženy na jiných discích. Využití: např. u tabulky obsahující pole pro ukládání rozsáhlého textového nebo binárního obsahu (slovníky, tabulky článků, obrázků nebo jiných souborů uložených v databázi).
Statický partitioning
- Příklad: Tabulka titulů v katalogu firmy distribuující hudební nahrávky může být členěna podle počátečního písmena názvu -> vzniká tabulka s předem pevně daným počtem partitions.
- Statický partitioning vzniká též při užití hašovací funkce na aspekt, podle kterého se má určit, do kterého oddílu daný řádek (sloupec) spadne.
Dynamický partitioning
Příklad: Tabulka zákaznických objednávek v databázi téže firmy může být členěna podle data pořízení objednávky a to po kalendářních měsících (jeden měsíc - jedna partition). Vzniká tak tabulka s dynamicky rostoucím počtem partitions -> každý měsíc přibude jedna nová.
CAP teorém
- Consistency
- Availability
- Partition Tolerance
• CAP teorém: pro distribuovaný systém ( konkrétně pro webové služby) je nemožné současně garantovat následující tyto 3 vlastnosti.
CAP teorém - shrnutí: (další slide)
• Všechny tři vlastnosti jsou žádoucí, ale pro jakýkoliv systém sdílení dat je možné dosáhnout maximálně dvou současně.
• Zvláště u webových aplikací založených na horizontálním škálování je nutné se rozhodnout mezi konzistencí a dostupností.
CAP teorém - C
• Consistency
– každý uzel/klient vidí ve stejný čas stejná data, (data konzistentní nezávisle na běžících operacích či jejich umístění)
– distribuovaný systém je považován za konzistentní v případě, že všechny operace čtení vrací verzi dat vloženou poslední operací zápisu do sdíleného úložiště.
CAP teorém - A
• Availability
– každý požadavek obsloužen, úspěšně nebo neúspěšně, (nepřetržitý provoz, vždy možnost zapsat a číst data)
– systém by měl fungovat i když některé jeho servery havarují nebo jsou nedostupné kvůli poruchám sítě.
CAP teorém - P
Partition Tolerance
– funkční navzdory chybám sítě nebo výpadkům uzlů. (možnost výpadku části infrastruktury, např. odstávka pro údržbu)
– systém je navržen tak, aby mohl pokračovat v práci i v případě, že se kvůli přerušení sítě rozdělí (dočasně nebo trvale) na několik samostatných částí.
CAP teorém - C + A
- RDBMSs - Postgres, MySQL, apod. (relational) - pamatovat
- Vertica (column-oriented)
- Aster Data (relational)
- Greenplum (relational)
CAP teorém - C + P
- BigTable (column-oriented/tabular)
- Hypertable (column-oriented/tabular)
- HBase (column-oriented/tabular)
- MongoDB (document-oriented) - pamatovat
- Terrastore (document-oriented)
- Redis (key-value)
- MemcacheDB (key-value)
- Berkeley DB (key-value)
CAP teorém - A + P
- Dynamo (key-value)
- Voldemort (key-value)
- Tokyo Cabinet (key-value)
- KAI (key-value)
- Cassandra (column-oriented/tabular) - pamatovat
- CouchDB (document-oriented)
- SimpleDB (document-oriented)
- Riak (document-oriented)
BASE
Přístup označovaný jako BASE preferuje dostupnost, částečnou degradaci a výkon před konzistencí a izolací.
Basicaly Available – aplikace pracuje bez přerušení
Soft-state – aplikace nemusí být v každém okamžiku konzistentní
Eventual consistency – aplikace bude v blíže neurčené době opět konzistentní
ACID vs BASE
- Internetové aplikace, jako jsou sociální sítě, blogy, znalostní databáze a další, vytvářejí obrovské množství dat, která musí být dále zpracovávána.
- Společnosti provozující takové aplikace si musí stanovit preference týkající se výkonnosti, spolehlivosti, dostupnosti a konzistence. Jak již bylo zmíněno výše, CAP teorém říká, že ze tří žádoucích vlastností
- (konzistence, dostupnost, tolerance k rozdělení) je možné dosáhnout pouze dvou současně.
- Pro narůstající počet aplikací je dostupnost a tolerance k rozdělení důležitější než konzistence.
- Požadavek na internetové aplikace - musí být především výkonné a spolehlivé.
- Vysokého výkonu lze dosáhnout horizontálním škálováním.
- Spolehlivosti vyšší lze dosáhnout vyšší redundancí.
- Velmi obtížné při plném dodržení vlastností ACID.
- Proto je aplikován přístup BASE.
Porovnání ACID a BASE (vlasnosti)
ACID: • silná konzistence • izolovanost • orientace na komit • vnořené transakce • dostupnost? • konzervativní (pesimistické) • složitý vývoj
BASE: • slabá konzistence (stará data) • dostupnost na prvním místě • přibližné odpovědi jsou OK • jednodušší, rychlejší dodávka dat „jak to jen půjde“ • agresivní (optimistické) • jednodušší vývoj
Konzistence databáze BASE
- Strong Consistency – všechny operace čtení musí poskytovat data z poslední operace zápisu nezávisle na replice na které se operace čtení odehrává.
- Eventual Consistency – operace čtení může poskytovat nekonzistentní data v průběhu synchronizace mezi replikami.
- BASE databáze je bez silné konzistence.
- Při aktualizaci není zaručeno, že každý, kdo čte z databáze, dostane aktualizovaná data.
- Vysoká dostupnost v BASE je dosahována povolením dílčích chyb tak, aby nedošlo k poruše celého systému.
- Ošetření případných chyb vzniklých nekonzistencí není prováděno na datové, ale na aplikační vrstvě.
Použití ACID a BASE
- V praxi se ukazuje, že ACID transakce jsou nezbytné jen v některých případech.
- Dokonce jen v některých případech užití v rámci jedné aplikace.
- V internetových aplikacích se používají oba přístupy – ACID i BASE.
- V případech užití, kdy je nezbytná silná konzistence, jako jsou bankovní operace, se používá přístup ACID.
- V případech užití, kdy je upřednostňována dostupnost, se používá přístup BASE.
Problém zpracování velkého objemu dat
- V případě velmi velkého množství dat nebude pravděpodobně možné dosáhnout potřebné kapacity a výkonu škálováním vertikálním - bude nutné použít škálování horizontální.
- Při horizontálním škálování je udržování silné konzistence databáze se vzrůstající zátěží stále náročnější a vede ke snižování výkonu i dostupnosti.
• Pro řadu aplikací nepřípustné:
– Amazon uvádí, že prodloužení odezvy o 0,1s znamená snížení prodeje o 1%.
– Google uvádí, že prodloužení odezvy o 0,5s znamená propad v provozu až 20% a s tím spojené finanční ztráty. Pro mnoho aplikací je přijatelnější nemít vždy databázi zcela konzistentní, ale zato neustále dostupnou s vysokou rychlostí odezvy uživateli.
Řešení
• NoSQL databáze byly vyvinuty podle požadavků odlišných od požadavků na relační (SQL) databáze v době jejich vzniku.
• Jejich použití je také jiné a nemá smysl dělat přímá srovnání.
• Oba přístupy jsou opodstatněné v určitých případech použití .
• Mnoho společností proto používá současně databáze relační (SQL) a NoSQL.
Kategorie NoSQL databází
Rozdělení na základě datového modelu:
1) Klíč-hodnota (Key-value)
=> Datový model: kolekce klíč-hodnota
=> Amazon Dynamo
2) Sloupcové databáze (Column-oriented)
=> Datový model: rodiny sloupců (Column family)¨
=> Google Bigtable
3) Dokumentové databáze (Document databases)
=> Datový model: kolekce semistrukturovaných dokumentů
=> MongoDB
4) Grafové databáze (Graph databases)
=> Datový model: vrcholy, hrany, key-value u obou
=> Neo4j
Big Data - definice
Gartner: „soubory dat, jejichž velikost je mimo schopnosti zachycovat, spravovat a zpracovávat data běžně používanými softwarovými nástroji v rozumném čase.“
+ velká data jsou dostatečně velká, aby zakryla jejich základní význam (data jsou hodně různorodá, z počátku necháme jejich celý význam)
Big Data také znamenají
Zavedení nových technologií, a to jak infrastruktury, tak softwaru:
• Nové pracovní vytížení
• Požadovány nové dovednosti
• Nový přístup (komoditní vs. podniková třída: „sandbox“ vs. integrovaná data)
Big Data Tasks
1) agregace
2) manipulace
3) analýza
4) vizualizace
-> vznik nových technologií
Big Data 3V (4V)
- Objem (volume) – množství dat vznikajících v rámci provozu firem roste exponenciálně každý rok,
- Typ (variety) – různorodost typů dat vzrůstá, například nestrukturované textové soubory, semi-strukturovaná data (XML), data o geografické poloze, data z logů,
- Rychlost (velocity) – rychlost, s jakou data vznikají a potřeba jejich analýzy v reálném čase vzrůstá díky pokračující digitalizaci většiny transakcí, mobilním zařízením a vzrůstajícímu počtu internetových uživatelů,
• Věrohodnost (verosity) - data musí mít určitou kvalitu. Určení s jakou mírou spolehlivosti můžu s daty počítat.
Big Data Technlogie
1) Hadoop distribované systémy souborů
2) MapReduce
3) Cloudové služby
4) Machine Learning
- a další, nepřehledný slide
Real-time database and analytics
These are typically in-memory, scale-out engines that provide low-latency, cross-data center access to data, and enable distributed processing and event-generation capabilities.
- Interactive analytics: Includes distributed MPP (massively parallel processing) data warehouses with embedded analytics, which enable business users to do interactive querying and visualization of big data.
- Batch processing: Hadoop as a distributed processing engine that can analyze very large amounts of data and apply algorithms that range from the simple (e.g. aggregation) to the complex (e.g. machine learning).
Řešení big data
- Hardware – konsolidovaná integrovaná řešení s důrazem na výkonnost (storage, server, …)
- Distribuce dat – např. Hadoop
- Data Management – např. NoSQL
- Analýza a vizualizace – trend: in-memory
Hadoop
- Apache Foundation
- Framework – sada open-source komponent určených pro zpracování velkého množství nestrukturovaných a distribuovaných dat
- potřeba souborový systém => např. HDFS (Hadoop Distributed File System)
- Programový model: map-reduce (map = rozdělení úlohy, reduce = spojení výsledků)
- Podstata spočívá v uložení dat na velkém množství samostatných počítačích
- Alternativa k HW s vysokou dostupností
(asi Machine) Learning v Big Data
1) Batch learning
• Sledujte dávku trénovacích dat
• Naučte se z nich vytvořit model
• Predikujte nové případy (přesně předvídejte nové vzory)
2) On-line learning • Sledujte sekvenci dat • Naučte se postupně tvořit model, podle sekvence dat • Přesně nastavte sled online predikcí Vysoká adaptabilita, paralelizace…
Tlak trhu v Big Data
• Data vykazující odlišné vlastnosti - 3 V
• Internet věcí
– Analýza časových řad
– Analýza souborů protokolu
• Zabezpečení podniku
– Vysoce regulované systémy (zdravotnictví, vláda)
• Streaming
• Nízké provozní náklady
• Vysoká dostupnost
• Rychlost změny v několika dimenzích - technologie, zdroje dat, konkurence, trhy
Hardware Big Data - Scale Up vs. Scale Out
Scale Up • Make a single CPU as fast as possible • Increase clock speed • Add RAM • Make disk I/O go faster
Scale Out
• Make Many CPUs work together
• Learn how to divide your problems into independent threads
Různé typy Big Data + komponenty
- Formát obsahu
- Typ dat (například transakční data, historická data nebo kmenová data)
- Frekvence, ve které budou data zpřístupněna
Záměr:
• Jak mají být data zpracovávána (např. Ad-hoc dotaz na data)
• Zda zpracování musí probíhat v reálném čase, čase blízkém reálnému času nebo v dávkovém režimu.
- data standards
- logical design
- physical plan
- capabilities plan
- people and processes to fit the changes
- technology appropriate for the job
Hype křivka
• Hype křivka ukazuje grafickou reprezentaci stavu zralosti, přijetí technologie a její potenciál řešit konkrétní úlohy.
osa X -> stav zralosti
osa Y -> viditelnost
- Počáteční zájem – média nadšeně popularizují novou technologii a vkládají do ní občas až přehnaně velký potenciál, přitom technologie zatím většinou nemá žádné praktické využití.
- Vrchol očekávání – časná publicita technologie a opěvování očekávaných pozitivních výsledků je doprovázena kritickými ohlasy; naděje a očekávání začínají klesat.
- Deziluze – zájmu ubývá, mnoho experimentů a pokusů o implementaci nové technologie se na první pokus nezdaří.
- Pozitivní sklon osvícení – pochopení technologie více do hloubky vede k nalezení jejích výhod. Objevují se další generace produktů od poskytovatelů technologických služeb.
- Plošina produktivity – technologie je plně přijata a využívána.
- Sledované technologie v různých fázích svého vývoje vykazují určitou míru „viditelnosti“, a to nejen ve smyslu viditelnosti v médiích, ale především ve smyslu vkládaných očekávání a nadějí.
- Tato závislost „viditelnosti“ na „stavu zralosti“ je prakticky nezávislá na tom, o jakou konkrétní technologii jde.
Použití v praxi Acid x Base
- V praxi se ukazuje, že ACID transakce jsou nezbytné jen v některých případech (dokonce v rámci jedné apilkace)
- V internetových aplikacích se používají oba přístupy
- V případě užití, kdy je nezbytná silná konzistence, jako jsou bankovní operace, se používá přístup ACID
- V případě užití, kde je upřednostňována dostupnost, se používá BASE
Partitioning NoSQL
- Virtuální nódy
- Dělení (Sharding)
- Hashing
- Consistent Hashing
- Replikace
- Správa členských serverů (Membership)
- Gossip
Virtuální nódy (partitioning NoSQL)
- Infrastruktura, na které jsou provozovány NoSQL databázové systémy, jako je například Bigtable, MongoDB nebo Cassandra, je tvořena velkým počtem serverů, které se od sebe liší svojí konfigurací.
- Z důvodu zohlednění a využití rozdílného výkon serverů se používají v konfiguracích databázových systémů takzvané virtuální nódy.
- Na jednom fyzickém serveru může běžet několik virtuálních nodů, v závislosti na jeho konfiguraci.
- Virtuální nódy používá MongoDB.
Dělení (Sharding) (partitioning NoSQL)
- Sharding je metoda, která umožňuje velké soubory dat rozdělit na několik serverů.
- Metodu používá například MongoDB nebo Redis.
- Shard v pojetí MongoDB je skupina serverů, které udržují identické kopie určené části dat.
Hashing (partitioning NoSQL)
- Nejjednodušší způsob rozdělení dat spočívá v rozdělení rozsahu primárního klíče
- pomocí hash funkce na stejné části, kdy každá část leží na jednom serveru. Klient pomocí hash funkce určí, na kterém serveru leží požadovaná data.
- Tento přístup využívá například systém Memcached.
Nevýhoda: V případě výpadku jednoho ze serverů nebo při přidání dalšího serveru, musí být rozdělení dat provedeno znovu a data podle nového rozdělení opět rozdistribuována.
Poznámka:
• Systém Memcached, který má relativně malý objem dat uložen pouze v operační paměti a redistribuce je snadno provedena přirozeným během databáze - důvod, proč se nevýhoda neprojeví.
• U databází, které mají data uložena na lokálním disku, je nutno kopírování velkých objemů dat mezi servery.
Consistent Hashing (partitioning NoSQL)
- Některé NoSQL databázové systémy, jako Cassandra nebo MongoDB, používají Consistent hashing.
- V systému Consistent hashing leží celý rozsah primárního klíče na pomyslném kruhu.
- Každá hodnota primárního klíče má svého správce, kterým je první nod na pomyslné kružnici ve směru hodinových ručiček.
• Výhoda řešení:
– přidání, odebrání nebo výpadek nodu se dotkne pouze nodů s ním sousedících.
– Redistribuce dat je nutná pouze mezi těmito sousedícími nody a ostatních nodů se nijak nedotkne.
Replikace (partitioning NoSQL)
- K zajištění odolnosti proti výpadkům serverů (při vysokých počtech v infrastrukturách horizontálně škálovaných databází velmi časté) a k zajištění vysoké dostupnosti jsou data udržována ve více kopiích pomocí replikace.
- Replikace současně umožňuje rozkládání zátěže.
Správa členských serverů (Membership) (partitioning NoSQL)
• Přidávání i odebírání nodů musí probíhat bez dopadu na dostupnost databáze.
• Přidání nového nodu:
– Nod náhodně vybere svoji pozici na pomyslné kružnici hodnot primárního klíče.
– Oba nejbližší sousedi předají části svých rozsahů a provedou změny na replikách.
– Nový nod si zkopíruje data od svých sousedů a informuje o nastalých změnách všechny zbývající nody.
– V případě odebrání nebo havárie nodu nod přestane rozesílat a odpovídat na stavové zprávy z ostatních nodů.
– Data zůstávají dostupná na jeho replikách.
– Sousední nody si opět upraví své rozsahy, včetně všech replik.
Gossip (partitioning NoSQL)
- Pro šíření stavových informací a detekci havarovaných nodů je používán protokol Gossip.
- Gossip nepoužívá broadcasty - každý nod posílá zprávy jen omezenému počtu dalších nodů.
- Zpráva se postupným předáváním dostane ke všem nodům.
Prostředky k zajištění Eventually consistence
1) Časová značka (Timestamps)
2) Verzování (Multiversion)
3) Vektorové hodiny
Časová značka (zajišťujcí Eventually consistence)
Závisí na synchronizovaných hodinách na všech serverech a nezachycuje kauzalitu aktualizací
Verzování (Multiversion) (zajišťujcí Eventually consistence)
- Udržování více verzí dat jednotlivých řádků databáze, u každé verze je uložen časový údaj.
- Časový údaj nemusí odpovídat skutečnému času - může to být jakákoli hodnota umožňující určit pořadí aktualizací.
- Na dotaz klienta vrací databáze nejaktuálnější hodnotu.
- Také může vracet nejaktuálnější hodnotu před zadaným časem.
Vektorové hodiny (zajišťujcí Eventually consistence)
• Použití vektorových hodin je přístup, který zachycuje pořadí aktualizací a umožňuje udělat rozhodnutí v případě konfliktů.
• Vektorové hodiny jsou definovány jako N-tice stavu hodin na každém nodu:
Vx{tnode1, tnode2, … ,tnodeN}
- Aktualizace datmezi nody (například pomocí protokolu Gossip) obsahuje společně s hodnotou dat i časový vektor, který je složen z časových hodnot na všech serverech.
- Hodnota hodin nemusí vycházet ze skutečného času (jakákoli hodnota, která umožní určit pořadí).
- Pořadí aktualizací je určováno porovnáním vektorových hodin.
• Vektorové hodiny jsou používány k zabezpečení konzistence dat mezi více replikami.
• Mohou být použity i v komunikaci klienta s databází:
-> Klient současně s požadavkem na server pošle poslední hodnotu vektorových hodin, kterou zná.
-> Server zaručí, že data, která mu pošle zpět, budou novější.
•Výhoda použití vektorových hodin:
- > oproti předchozím systémům spočívá v nezávislosti na synchronizovaných hodinách.
- > není potřeba mít k dispozici dlouhou historii aktualizací ani není potřeba udržovat několik verzí dat na všech nodech.
Vyhledávání v NoSQL
- Mezi je různými NoSQL databázemi je velký rozdíl v možnostech vyhledávání.
- Databáze skupiny klíč-hodnota (key-value) nabízejí většinou jen možnost vyhledávání podle primárního klíče a veškeré další operace jsou prováděny na straně klientské aplikace.
- Některé dokumentové a grafové databáze mají bohatší dotazovací jazyk pro provádění komplexnějších dotazů.
Možnosti dokumentových a grafových databází pro provádění komplexnějších dotazů:
- Companion SQL databáze
- Scatter-Gather lokální vyhledávání
- Distributed B-tree
- Prefix Hash Table (Distributed Trie)
Companion SQL databáze
a. Databáze, do které se zkopírují atributy podle kterých je potřeba vyhledávat.
b. Schopnosti vyhledávání SQL jsou použity k vyhledání primárních klíčů, podle kterých se potom k datům přistupuje v NoSQL databázi.
Scatter-Gather lokální vyhledávání
- No SQL databáze umožňuje vyhledávání a indexování na jednotlivých nodech.
- Dotaz od klienta je nejdříve připraven dotazovacím zpracovatelem (query processor),
- Dotaz rozešle na všechnynody databáze, kde je provedeno lokální vyhledávání.
- Každý z nodů pošle výsledek lokálního vyhledávání zpět zpracovateli, který výsledky agreguje a pošle klientovi.
Distributed B-tree
- Lze udělat hash atributu, podle kterého se bude vyhledávat a najít kořenový nod distribuovaného B-tree indexu.
- Ten obsahuje hodnotu, která je identifikátorem jeho potomka.
- Klient potom vyhledá nod potomka.
- Opakováním tohoto procesu je dosaženo nodu, kde leží vyhledávaná data.
Prefix Hash Table (Distributed Trie)
- Trie je stromová datová struktura, kde každý uzel obsahuje všechny podřetězce, kterými může pokračovat řetězec v dosud prohledané cestě.
- Všichni následníci mají společný prefix, který je shodný s řetězcem přiřazeným k danému uzlu.
- Kořen je asociovaný s prázdným řetězcem.
- Hodnoty nejsou obvykle asociovány se všemi uzly, ale jen s listy a některými vnitřními uzly, které odpovídají klíčům.
Motivace optimalizace SQL
- SQL je velmi flexibilní jazyk.
- Dvěma či více různými dotazy je možno obdržet stejná data.
- Rychlost různých dotazů ovšem nemusí být stejná i přesto, že vracejí stejná data.
Důvod optimalizace
• Jedním z hlavních důvodů provádění optimalizace v databázových (DB) prostředcích je minimalizace nákladů.
• Jedná se především o minimalizaci nákladů na:
– zdrojový čas,
– kapacitu paměti (prostor),
– programátorskou práci.
(= snažíme dosáhnout maximálního výkonu se stávajícími prostředky)
=> klíčová doba odezvy celého (informačního) systému
Optimalizátor
• Fáze zpracování dotazu – převod do vnitřní formy => SQL -> AR => lineární výraz -> strom Poznámka: kalkul AR v polynomiálním čase v závislosti na délce výrazu – konverze do kanonického tvaru – optimalizace – plán vyhodnocení – generování kódu
Přehled problému optimalizace
• Plán vyhodnocení: strom dotazu + algoritmus pro každou operaci.
• Dvě hlavní myšlenky:
– jaké plány jsou uvažovány pro daný dotaz?
– jak se odhaduje cena plánu?
• Z uvažovaných plánů se vybere ten s nejmenší cenou.
Obecná pravidla pro psaní SQL dotazů
- Vyjmenovat sloupce
- Používat co nejméně klauzuli LIKE
- Používat co nejméně klauzule IN, NOT IN
- Používat klauzule typu LIMIT
- Na začátek dávat obecnější podmínky
- Výběr vhodného pořadí spojení
- Používat hinty
- Nastavit indexy
Definice distribuovaného systému
Distribuovaný systém je takový systém propojení množiny nezávislých uzlů, který poskytuje uživateli dojem jednotného systému
Jednotný obraz systému, virtuální uniprocesor
Hardwarová nezávislost
- uzly jsou tvořeny nezávislými “počítači” s vlastním procesorem a pamětí
- jedinou možností komunikace přes komunikační (síťové) rozhraní
Dojem jednotného systému
- uživatel (člověk i software) komunikuje se systémem jako s celkem
- nemusí se starat o počet uzlů, topologii, komunikaci apod.
distribuovaný systém - celá škála různých řešení
- multiprocesory na jedné základové desce
- celosvětový systém pro miliony uživatelů
Uvažované termíny v dalším výkladu: uzel = (‘běžný’) počítač, softwarový systém
- principy, algoritmy
Distribuované databázové systémy = databázové systémy + počítačové sítě DBS = integrace PS = decentralizace DDBS= integrace dat bez centralizace (je variantou DVS)
Požodavky na ideální DDBS
- uživateli se jeví distribuovaný systém přesně jako nedistribuovaný
- lokální autonomie
- nespoléhání na centrální činnost
- nepřetržitá činnost
…
(jiný slide)
• Transparentnost distribuce (míra viditelnosti distribuce dat pro uživatele
• Autonomie (distribuce řízení)
• Heterogennost
• Výkon (vysoká průchodnost krátká odezva)
Taxonomie DDBS
1) Autonomie: těsná integrace, poloautonomie, úplná izolace
2) Distribuce: jeden uzel, distribuovaný
3) Heterogenita: homogenní, heterogenní
Distribuovaný výpočetní systém
Distribuovaný výpočetní systém má vlastnosti:
• Je rozložen do uzlů sítě spojených komunikačními kanály
• V uzlech je možné autonomně ukládat a zpracovávat data
• Prostředky v uzlech mohou být nehomogenní
• Uživatel nemusí vědět o existenci ostatních uzlů (tzv. transparentnost)
Problémy DDBS
1) přenos v sítí pomalý
2) zotavení po chybách a poruchách
Distribuované databáze - důvody pro a proti
+ lokální autonomie (odpovídají struktuře decentralizovaných organizací. Data uložena v místě nejčastějšího využití a zpracování - zlevnění provozu). V centralizované DB je nutné připojovat se ke vzdálené databázi = přídavná režie, cena komunikace, zatížení sítě
+ zvýšení výkonu (inherentní paralelismus rozdělením zátěže na více počítačů)
+ spolehlivost (replikace dat, degradace služeb při výpadku uzlu, přesunutí výpočtů na jiný uzel)
+ lepší rozšiřitelnost konfigurace (přidání procesorů, uzlů)
+ větší schopnost sdílet informace integrací podnikových zdrojů
+ uzly mohou zachovat autonomní zpracování a současně virtuálně zabezpečovat globální zpracování
+ agregace informací (z více bází dat lze získat informace nového typu)
- složitost (distribuce databáze, distrib. zpracování dotazu a jeho optimalizace, složité globální transakční zpracování, distribuce katalogu, paralelismus a uvíznutí, případná integrace heterogenních dat do odpovídajících schémat, složité zotavování z chyb)
- cena (komunikace je navíc)
- bezpečnost
- obtížný přechod (neexistence spolehlivého automatického konverzního prostředku z centralizovaných DB na DDB)
Požadavky DSŘBD
- lokální autonomie – každé místo má lokální SŘBD
- vše je distribuované – ve všech službách se nespoléhá na žádné centrální místo
- kontinuálnost – akce v jednom místě (např. odstranění tabulky) by neměla příliš narušovat provoz DDBS jako celku
- nezávislost na místě – uživatel nemusí vědět, kde jsou uložena potřebná data
- nezávislost na fragmentaci – nemusí vědět, kde jsou fragmenty
- nezávislost na replikaci
- možnost distribuovaného zpracování dotazu – nemělo by být nutné přesouvat data ke zpracování dotazu do jednoho místa
- možnost distribuovaného zpracování transakcí – může dojít ke konfliktu s 1. Pro zajištění korektnosti se používá 2 fázový potvrzovací protokol
- nezávislost na hardware
- nezávislost na OS
- nezávislost na síti
- nezávislost na DBMS
Dělení DDBS dle autonomie
- těsně integrované (uživatel vidí data centralizovaná v jediné databázi). DDB je vybudována nad lokálními DB. Každé místo má úplnou znalost o datech v celém DDBS a může zpracovávat požadavky používající data z různých míst.
- semiautonomní systémy (lokální DBMS pracují nezávisle a sdílejí svoje lokální data v celé federaci). Jen část jejich dat je sdílena.
- zcela autonomní = izolované. Lokální DBMS pracují nezávisle a neví o ostatních DBMS. Pro vzájemnou komunikaci potřebují softwarovou vrstvu pracující nad jednotlivými DBMS
- kompozitní (logicky centralizované)
- federativní (poloautonomní)
- multidatabázové (autonomní)
Formy transparentnosti DDBS
1) Datová nezávislost = imunita uživatelské aplikace ke změnám v definici a organizaci dat. Je požadavkem i pro centralizované DB
• Logická nezávislost (logická struktura databáze)
• Fyzická nezávislost (konkrétní způsob uložení dat)
2) Síťová transparentnost = ukrytí síťových detailů = uživatel neví o síti
3) Replikační transparentnost = neobtěžovat uživatele skutečností, že pracuje s daty existujícími ve více kopiích = uživatel neví o replikách
4) Fragmentační transparentnost = uživatelův dotaz je specifikován na celou relaci, ale musí být vykonán na jejím fragmentu = uživatel neví o fragmentech
Distribuované zpracování transakcí
Transakce = posloupnost operací, které se provedou buď všechny nebo žádná –zajišťuje je transakční monitor (Atomicity, Consistence, Isolation, Durability)
Transakce v DDBS rozděleny na podtransakce (prováděny na různých místech).
Transakční zpracování v jednotlivých uzlech nestačí.
Dvoufázový potvrzovací protokol
- F1. Koordinátor zašle všem místům (kde se provádí podtransakce dané transakce) zprávu s požadavkem na připravenost (PREPARE to COMMIT). Hlásí-li některé místo nepřipravenost, provede koordinátor ROLLBACK transakce ve svém místě a pošle zprávu všem místům na ABORT podtransakcí.
- F2. Ohlásí-li všechna místa úspěšnost (READY to COMMIT), tak koordinátor potvrdí transakci a její lokální části ve svém místě. Pak odešle zprávy s požadavkem na potvrzení (COMMIT) všem participantům. Tyto zprávy budou dříve nebo později doručeny
Postup návrhu DDBS
1) Top down: • Návrh GCS (globální konceptuální schéma) • Návrh fragmentace • Návrh alokace • Návrh fyzické struktury
2) Bottom up:
• Výběr společného DB modelu pro popis globálního schéma
• Překlad každého lokálního schéma do společného DB modelu
• Integrace lokálních schémat do společného globálního schéma
Druhy fragmentace
1) Horizontální => rozdělíme data po řádkách (splňující dané kritérium) 2) Odvozená horizontální => horizontální s jiným spojením 3) Vertikální => rozdělíme data po sloupcích 4) Smíšená => kombinace
Strategie zpracování přenosu dat
Problém přenosu dat mezi uzly lze redukovat na problém řešení spojení relací umístěných v různých uzlech sítě
•Jednoduché zpracování spojení
-spojení se zpracovává v jednom uzlu sítě
• Paralelní zpracování spojení
-ve více uzlech se současně zpracovávají podvýrazy dotazu obsahující spojení
• Zpracování pomocí polospojení
-mezi uzly se přenáší pouze ty n-tice, které budou operací spojení skutečně spojeny
Distribuce globálních relací
• s replikami => umožním vícenásobné uložení • ve fragmentech => mám data rozdělené • s replikami i ve fragmentech => mám to rozdělené, ale i zálohované
Postup při návrhu fragmentů
Respektovat hlediska:
- rozdělit relace do lokálních serverů tak, aby aplikace zatěžovaly servery stejnoměrně. (Musí být známa informace o předpokládaných přístupech k relacím)
- lokality zpracování (maximalizovat lokální)
- přístupnosti a spolehlivosti (např. replikací zlepšíme spolehlivost a read-only dostupnost),
- maximalizovat stupeň paralelismu zpracování dotazu
- dostupnosti a ceny paměti v jednotlivých uzlech
Pravidlo MC (minimality a úplnosti množiny jednoduchých predikátů)
- Každý fragment tabulky musí být přístupný jedinečným způsobem alespoň jedné aplikaci.
- Vlastnost minimality množiny jednoduchých predikátů znamená, že vypuštěním kteréhokoliv z nich se poruší úplnost množiny jednoduchých predikátů.
- Naopak přidání dalšího predikátu způsobí zavedení dalšího (nenutného) fragmentu se stejnými statistickými vlastnostmi
- Všechny řádky libovolného fragmentu tabulky musí být přístupné se stejnou pravděpodobností každému procesu definovanému pro fragment (Completeness).
- Tzn. chceme, aby všechny řádky fragmentu měly stejné statistické vlastnosti, pak fragment lze zpracovávat při optimalizaci dotazu jako jeden celek.
Replikace dat
- fragment relace je replikovaný, je-li uložen současně na více místech.
- úplná replikace relace: případ, kdy je relace umístěna ve všech místech
- plně redundantní databáze: případ, kdy je databáze umístěna ve všech místech
- výhody
- dostupnost: chyba v místě s relací R nevede k nedostupnosti R,
- paralelismus: dotazy nad R mohou být zpracovávány paralelně na více místech,
- redukce přenosů dat.
- nevýhody
- složitější aktualizace: každá replika R musí být aktualizována,
- zvýšená složitost řízení souběžného zpracování: možnost vzniku nekonzistence dat.
Příklady multimediálních dat
1) obrazové databáze
- biometrické databáze (otisky prstů, oční duhovky, obličejové rysy)
- medicínské snímky (rentgen, tomografie, ultrazvuk, atd.)
- satelitní snímky, meteorologický radar
- snímky materiálových řezů
- heterogenní kolekce (web)
a mnoho dalších…
2) video kolekce
- TV zpravodajství
- filmové kolekce, domácí video
- záznamy z bezpečnostních kamer (letiště, supermarkety, centra měst, atd.)
- „netradiční“ sekvence (medicínské, průmyslové, atd.)
3) geometrické kolekce
- CAD modely
- opět biometrické databáze
- geografická, kartografická a GIS data
4) časové řady, audio, (obecně diskrétní signály)
- vývoj kurzů akcií, měn, atd.
- medicínská data - EEG, EKG, atd.
- řeč (obecně zvuk)
5) biologické databáze
- chemické látky (molekuly, sloučeniny, atd.)
- sekvence DNA, bílkovin
6) melodie
- notové partitury
- MIDI soubory
7) text, hyper-text
- digitální knihovny, archivy, e-mail
- web
atd.
8) „document-centric“ XML data,
semi-strukturovaná data
Typy MDB systémů
1) text-based retrieval systémy
= vyhledávání pouze podle textové anotace (meta-informace)
2) content-based retrieval systémy
= vyhledávání pouze podle obsahu
3) hybridní systémy
Modality vyhledávání
1) dotazování (querying)
- dotaz v kontextu dokumentu
- dotaz v kontextu kolekce
2) prohlížení (browsing)
- navigace v celé kolekci
Framework MDB
•Jednotlivé části SQL/MM jsou na sobě poměrně
nezávislé
• Framework je část společná a závazná „zbytku
světa“
• Poskytuje:
• definici společného konceptu užitého v dalších částech
SQL/MM
• hlavní rysy přístupu k definici těchto částí
Full-Text MDB
Full-Text“ ≈ textová data lišící se od běžných znakových řetězců
• Obvykle delší záznamy
• Specifické operace
• Způsob indexování • Index slov v dokumentu
• Index vzájemných vzdáleností slov a frází
Spatial MDB
- Musí umožnit formulování dotazů následujících typů
- Dotazy výhradně na prostorové vlastnosti (Najdi všechna města rozdělená řekou)
- Dotazy pouze na neprostorové vlastnosti (Kolik lidí žije v Ostravě?)
- Kombinace předchozích typů (Vypiš jména všech sousedů parcely číslo 15 v Soukenické ulici)
- Body:
- pouliční lampa, lavička…
- Křivky:
- koryto řeky, hranice pobřeží…
- Polygony:
- půdorys budov, území států, pozemky…
Operace na prostorových objektech
- Průnik
- Sjednocení
- Relace „sousedí“
- Objekt A sousedí s objektem B
- Relace „obsahovat“
- Objekt A obsahuje objekt B
- Vzdálenost dvou objektů
General Purpose Facilities
- Pokus o množinu tříd pro hlavní matematické operace
- Tato část ze standardu prozatím vypadla
- Vysoké náklady
- Málo uživatelů
Still Image
- SI_StillImage
- Pro obrazová data
- SI_Feature
- Nadtyp pro různé vlastnosti obrázku (dále)
- SI_FeatureList
- Seznam pro (všechny) vlastnosti obrázku
Data Mining -techniky
•RULE MODEL
• Hledá pravidla a vztahy v datech.
• CLUSTERING MODEL
• Slučuje data do skupin s podobnými charakteristikami.
•REGRESSION MODEL
• Předvídá klasifikaci nově pořizovaných dat.
• CLASSIFICATION MODEL
• Předvídá klasifikaci (způsob shlukování), která bude
nejlépe odpovídat novým datům.
Polyglot Persistence
Výběr správného nástroje
- strukturovaná data = dokumentová
- relace mezi entitami a efektivní dotazování = grafová
- pokud strukturu spravuji sám a nepotřebuju komplexní dotazy = key/value
AsterixDB
Jedno prostředí, kde je možné uložit všechny typy dat, které připadají v úvahu
Objektově relační model vs multidimenzionální databáze
Objektově relační databáze podporuje různé typy objektů, ale neumí si poradit s Big Data
Trend vícemodelových databází
Od 2017 skoro všechny databázové systémy
