Management

Synchronizace ovšem nefunguje na všech typech datových uložišť stejně. Jak již bylo zmíněno výše, například u HTML stránek nebo webových služeb se změny ze zdroje detekují obtížněji než u klasických SQL databází, je tedy potřeba dávat pozor i na tento fakt.

3.3 Management

Server datové virtualizace musí být spravován stejně jako jiné databázové servery. I zde by měl být určený administrátor (ať už jedna osoba či oddělení), který by ručil za škálovatelnost, dostupnost, výkonnost, celkový management dat, a určil by nastavení pravidel pro přístupy, dotazování a vkládání dat na server.

Je pro to ale vyžadované od platformy datové virtualizace, aby dodávala administrátorovi všechny potřebné informace o tom, co se na serveru děje. Současný stav serveru, využití CPU, rychlost dotazů, počet vykonaných dotazů a rychlost odpovědí ze strany zdrojových uložišť jsou jenom jedny z mála potřebných informací pro každého administrátora, a platforma datové virtualizace by je měla spolehlivě dodávat.

Při administraci serveru datové virtualizace hodně záleží na počtu strojů, na kterých běží datová virtualizace. Při jednom stroji je údržba jednoduchá, protože máme na starosti jenom ten jeden stroj. Při vyšší diverzifikaci datových uložišť, které se budou vyskytovat na různých serverech, se ale zátěž na jeden stroj markantně zvyšuje a není to tudíž praktické řešení pro organizaci s větším počtem externích zdrojů dat, které chce tahat do datové virtualizace.

Doporučuje se instalovat i druhý server datové virtualizace na stejné síti jako jsou některá externí datová uložiště. Výhodou pak může možnost filtrace a transformace dat (v podstatě tedy předpřipravit data) před přenosem na primární server datové virtualizace. To pak může ulehčit zatížení primárního serveru datové virtualizace a zlepšit výkonnost. Pak je tu také u některých platforem možnost replikace serverů datové virtualizace a tím tedy mít jeden celek na více místech. To nám pak zajistí, že při výpadku jednoho serveru stále můžeme pracovat s datovou virtualizací na druhém serveru, jelikož tyto servery jsou v podstatě totožné (mají replikované tabulky, obaly i mapování a změna na jednom serveru se projeví i na druhém).

Také je zde výhoda snížení zatížení jednoho serveru, tudíž určitá distribuce zátěže. (13)

3.3.1 Bezpečnost

Bezpečnost je kriticky důležitým aspektem v datovém světě, a je důležité se k tomu stavět svědomitě. Data se musí vždy chránit proti jakémukoliv typu nevyžadovanému užití a mělo by se využít všech možností ochrany datového uložiště.

Zdrojová uložiště často mívají nastavené určité ochranné prvky proti nevyžadovaným přístupům. Ať už se jedná o obranu proti externím útokům (hackeři, organizované skupiny) nebo interní hrozby (chyby zaměstnanců), i v datové virtualizaci se musí nastavit obrana proti těmto jevům.

V datové virtualizaci se bezpečnost řídí především s ohledem na access management, tzn.

autentizaci a autorizaci uživatelů. Při vstupu na server se uživatelé musí identifikovat pomocí přihlašovacích údajů (např. ID a heslo) a server tím zkontroluje, zda uživatel opravdu je tím,

34

za koho se vydává. Tento systém je v podstatě stejný u všech typů databázových serverů, ovšem datová virtualizace může nabízet možnost konfigurace externího systému k tomu, aby se autentizovalo přes ně. Většinou servery datové virtualizace ukládají uživatelské přihlašovací údaje u sebe, některé pak umožňují ukládání těchto údajů „venku“, např. přes LDAP protokol.

(13)

Co se týče autorizace k přístupu do určených datových objektů, umožňuje datová virtualizace autorizaci i přes definice autorizací ze samotných zdrojů. V praxi to znamená přenos dotazu uživatele do zdrojového uložiště, kde se zkontrolují práva uživatele na dotazování se do daného objektu. Pokud uživatel má právo na dotazování se do daného objektu, dotaz úspěšně projde i v datové virtualizaci a uživateli se vrátí požadovaná odpověď. Dá se říct, že to je určitý způsob outsourcingu povinností datové virtualizace na zdrojové uložiště. Servery datové virtualizace ovšem podporují možnost definice přístupových práv i přímo u sebe. Můžou být seskupení do uživatelských skupin, rolí nebo jim mohou být přiřazena práva přímo na základě domény.

Práva pak mohou být udělena na úrovni tabulek, sloupců, řádků nebo na úrovni nejnižší granularity – konkrétní hodnoty. (13)

Pokud by datové uložiště, do kterého je přistupováno datovou virtualizací, nemělo žádnou vrstvu access managementu, tak by mohla být datová virtualizace jedinou složkou bezpečnosti i pro dané uložiště. Pokud ale zdroj má svoje vlastní bezpečnostní mechanismy pro přihlašování, tak musí uživatel dostat všechna požadovaná práva pro všechny jeho dotazy a změny. Ovšem i samotný server datové virtualizace musí mít práva pro přístup do zdrojů a exekuce dotazů a změn jejími uživateli.

Platformy datové virtualizace mohou také nabízet enkrypci dat, což nemusí vždy být umožněno uložišti pod úrovni datové virtualizace. V tomto případě pak datová virtualizace může být jistým štítem bránicím zdrojová data před neautorizovanými vstupy k datům. Stejně tak je některými platformy respektována i možnost maskování dat (tj. převedení citlivých dat do neidentifikovatelné formy). Tyto způsoby opatření pak pomáhají s dodržováním regulí stanovených na národní, federální či unijní úrovni (jako např. California Consumer Privacy Act – CCPA, General Data Protection Regulation – GDPR nebo Sarbanes-Oxley Act). (19)

Enkryptována ovšem nemusí být pouze data, ale i samotný převod dat přes síť. Zde také platformy datové virtualizace mnohdy podporují ochranný prvek ve formě SSL připojovacího mechanismu pro převod citlivých dat, kdy se vytvoří unikátní šifrovaný kanál pro soukromou komunikaci s uživatelskými aplikacemi, stejně tak je ale šifrovaná i komunikace se zdrojovými databázemi. (20)

3.3.2 Výkonnost

Když se většina Business Intelligence praktiků dozvídá o datové virtualizaci a její schopnosti integraci dat z heterogenních zdrojů v reálném čase, správně se obávají její možností vykonávat dotazy v rozumném čase.

Nepřekvapivě, pokud se datová virtualizace opravdu snaží provádět všechna zpracování dotazů pouze po svém, koneční uživatelé se mohou setkat s takovým zpomalením, že se služby datové virtualizace stávají nevyužitelným. Naštěstí jsou ale dnes produkty datové virtualizace dostatečně dospělé a tento problém mají z velké části vyřešený. Používají k tomu podobnou

35

strategii jako mají klasické relační databáze, tj. jejich dovednost vytvářet exekuční plány.

Datové virtualizace ovšem nelimitují své strategie na jednu databázi, ani na jeden typ databází, ani na jeden typ zdrojových dat. (21)

Je nutné dodat, že záleží také na zvolené platformě datové virtualizace a jejich systému vytváření exekučních plánů při spouštění dotazů. Společnost Denodo třeba poukazuje na to, že její platforma v případě dotazování se určitou agregaci dat ve zdrojové databázi s 200 miliony řádků nečte všechny řádky, ale pouze ty řádky, které potřebuje vyfiltrovat (tzn. splňující podmínky). Ne všechny platformy ovšem dokážou tvořit takové exekuční plány. (22)

Následující výkonnostní techniky pak datové virtualizace využívají k optimalizaci vracení dotazů v rozumném čase: (21)

• Pushdown processing (česky zpracování tlačením dolů) – Datová virtualizace nemusí provádět celý exekuční plán pouze na svém serveru a místo toho tlačí co nejvíce integrace, filtrace a řazení dolů na servery zdrojových databází, čímž distribuuje zátěž zpracování náročných aspektů pohledů na své zdroje s většími prostředky.

• Nahrazení dotazů – V tomto případě datová virtualizace nevidí důvod, proč zpracovat dotazy přesně tak, jak jsou napsané. Tudíž si dotaz překládá do své vlastní formy v podobě vytvoření souboru pod-dotazů, které se poté zašlou do svých zdrojových databází a tam se zpracují. Díky tomu se datové požadavky zpracují co nejefektivněji.

• Query injection (česky injekce dotazu) – Zde při přepisování dotazů datová virtualizace přenáší constrainty (česky omezení) v hierarchii exekučního plánu nahoru, aby se v konečném procesu vytlačila dolů do zdrojových databází dříve. „Injekce“ těchto omezení do segmentů dotazu dříve zajišťuje menší počet vracených řádků a tím minimalizuje celkovou práci na spojování dat.

• Ship joins – Datová virtualizace může i posílat data z jednoho uložiště do druhého, aby zátěž ze zpracování při spojování dat nesl rychlejší databázový server.

• Sort-merge joins – Je možné i potlačit dolů pouze ORDER BY podmínky, aby si zdrojové databáze data seřadila sama, a až poté posílala dále, čímž datové virtualizaci zůstává pouze spojovací část operace.

• Statistická data – Datová virtualizace kontinuálně získává informace ze zdrojových databází týkajících se objektů, které mají (např. počet řádků, průměrná délka řádků, indexované sloupce). Takové statistiky umožňují datové virtualizaci přepisovat exekuční plány pomocí různých zkratek.

• Rady – Vývojáři mohou vidět a kontrolovat exekuční plány datové virtualizace a díky tomu nalézt optimalizační možnosti, které nenalezl server datové virtualizace.

• SQL override (česky SQL přepis) – Někdy mohou vývojáři chtít větší vliv na zpracování dotazu. Platforma datové virtualizace jim umožní dodat SQL výkaz, který přepíše

36 3.3.3 Cache

Většina datových virtualizací nabízí široké mechanismy cachingu, tj. zisk obsahu virtuálních pohled z nižší úrovně zdrojových tabulek přes mapování a ukládání obsahu na disk nebo do paměti. Poté se při dotazování na virtuální pohled nemusí data získávat přímo ze zdroje, ale stačí vytahovat data z uloženého obsahu na disku nebo paměti.

Caching je jedním z nejdůležitějších komponentů, které datová virtualizace může nabízet pro zlepšení rychlosti dotazů, dostupnosti a minimalizace zásahu do zdrojových uložišť. Kromě velmi užitečného využití pro zvýšení výkonnosti dotazů, které většinou zpomaluje ne samotná datová virtualizace, ale zdrojová uložiště, ze kterých datová virtualizace vytahuje data, používáme caching i kvůli jiným důvodům, jako jsou například - (13)

• Optimalizace načítání zdrojů, kdy dané zdroje mohou být velmi starými systémy s horší výkonností a dotazování se přímo na zdroj může být časově náročnou záležitostí, a je v tomto případě rozumnější definování cache a zmenšit tím dotazování se přímo na zdrojový systém.

• Důsledné reportování pro uživatele, který chce vidět v reportu stejné výsledky při vícero náhledech v čase. To znamená, že pokud se zdrojový systém častěji aktualizuje, výsledky v reportu zůstanou stejné, pokud data do něj jdou přes cache.

• Dostupnost zdroje, tj. pokud není zdrojové uložiště někdy dostupné, periodicky aktualizované cache budou data udržovat a můžeme se na ně dotazovat místo zdroje kdykoliv budeme potřebovat, a nejsme tak závislý na zdrojovém uložišti.

• Komplexní transformace, kdy složitější transformace aplikovaná na data mohou být můžeme tedy díky vytvoření cache na virtuálnm pohledu, které bude udržovat dané agregace, zpřístupnit data pro uživatele.

Existují ovšem i určité nevýhody vztahující se ke cachingu. Cache je totiž smazaná v momentě, kdy se stroj, na kterém je udržovaná, zastaví. Dále může být problémem samotná paměť, na kterém se cache udržují. Ty totiž nejsou bez limitu a jsou dražší záležitostí, je tedy potřeba počítat i s těmito náklady. (13)

Pokud se ale cache udržují na disku, tak je udržujeme buď ve složkách nebo v tabulkách v databázi. Při použití složek datová virtualizace využívá vlastní strukturu formátu optimalizovanou pro zpracování dotazů. Díky tomu je výkonnost v tomhle případě vysoká i při dotazování se na větší počet dat. Nemusí se také kvůli tomu implementovat samostatný databázový server, je to tedy celkově lehčí způsob pro uložení dat. Ukládání dat do složek se doporučuje při menším počtu ukládaných dat, ale při kterých je potřeba se dotazovat na vysoká množství uložených dat. Tyto složky jsou spravované samotným serverem datové virtualizace.

(13)

Při ukládání „cached“ dat v databázi se vytváří vlastní tabulka, která je vytvořena přímo datovou virtualizací. Díky tomu pak můžeme vytvářet na tabulkách indexy a zlepšit rychlost

37

dotazů. Je tady také výhoda v určitém „outsourcování“ zátěže na databázový server a ulehčení práce pro datovou virtualizaci, která při dotazování se na cachovaná data uložená v tabulkách nedělá v podstatě nic, jelikož data vrací databázový server. (13)

Cache se také musejí aktualizovat, aby data v ní držela krok i s daty ve zdrojích. Cache mohou být zastaralá velice rychle pokud jsou vytvořená nad produkčními databázemi, které jsou průběžné aktualizované. Je tedy vyžadované, aby datová virtualizace nabízela určité spouštěče, které cache začnou aktualizovat. A ty nabízí následující - (13)

• Konstrukční aktualizace, kdy obsah cache je vytvořen pouze jednou při konstrukci, poté už cache nejsou aktualizované.

• Manuální aktualizace, kdy cache jsou zaktualizovaná při podnětu administrátora kdykoliv je to potřeba.

• Plánovaná aktualizace, kde se naplánuje jak často a kolikrát má aktualizace automaticky proběhnout.

• Aktualizace přes dotazy, kdy se naplánuje expirační datum/čas, který bude indikovat, jak stará data v cache mohou být při dotazování se na ně. Pokud se budeme dotazovat na danou cache a data v ní budou starší, než je povoleno podmínkou, tak se cache zaktualizuje těsně před provedením dotazu.

• Aktualizace přes události, tady se může naplánovat jakýkoliv typ události, které může daná platforma datové virtualizace rozeznat jako spouštěč. Tím může být např.

umístění složky do konkrétního souboru, nová data uložena do tabulky nebo provedená transakce.