V následujícím krátkém článku a bych rád upozornil na nejpodstatnější novinky a změny, na které se můžeme těšit v připravované verzi Microsoft SQL Server 2016. V době psaní tohoto článku se jedná o novinky v CTP2 a proto může být v RTM vše jinak. Jak sami zjistíte, SQL 2016 obsahuje celou řadu vylepšení toho, co bylo již uvedeno v předchozí verzi a přitom nesmyslná omezení bránila jejich masivnějšímu nasazení. A jaký byl můj první dojem z chystané verze ? “Takto měla vypadat již verze MS SQL 2014 !!!”

 

 Temporal Tables

Jedná se o nový typ tabulky, který umožňuje efektivněji pracovat s historickými daty. Pokud nad klasickou tabulkou spustíte příkaz SELECT, výsledkem dotazu budou aktuálně zpracovaná data, která se v ní právě teď nacházejí. Data se však mohou neustále měnit (Insert/Update/Delete/Merge) a pokud stejný příkaz spustíte později, můžete dostat zcela jiný výsledek. Ne však s Temporal Tables. Zjednodušeně řečeno, díky nové klauzuli můžete požádat SQL Server o zpracování příkazu SELECT nad daty, která byla v tabulce platná například před hodinou, včera, před měsícem. Tuto novinku lze využít v mnoha oblastech jako například sledování vývoje dat v čase, audit změn, business trendy, ale třeba i pro částečnou obnovu dat při náhodném či chybném smazání/změně.

 

Dynamic Data Masking

Voláte na hotline Vaší banky/pojišťovny. Běžně se stává, že Vás operátor požádá o poslední 4 číslice z Vašeho rodného čísla a to jako bezpečnostní kontrolu. Rodné číslo, číslo občanského průkazu nebo platební karty je však vysoce citlivou informací, která by mohl být snadno zneužitelná třeba i dotyčným operátorem, proto je třeba i jemu zobrazit jen část senzitivních informací, která je potřebná pro kontrolu. Rodné číslo je však uloženo ve sloupci celé a proto musel programátor vyřešit, jakým způsobem a jakou část dat bude v aplikaci, kterou operátor používá, prezentovat. Díky novince Dynamic Data Masking má situaci výrazně zjednodušenou. Při tvorbě sloupce v tabule (nebo ALTER existujícího) lze požádat SQL Server o “maskování” dat, která budou v daném sloupci uložena. Pokud pak uživatel dotáže sloupec Email příkazem SELECT, může obdržet výsledek dxxxx@xxxxxxxx.pro namísto david@hlavacek.pro. Pouze uživatel, který má nové security oprávnění UNMASK, uvidí data tak, jak jsou uložena. Není proto potřeba měnit syntaxi příkazu SELECT, o vše se postará SQL Server.

 

 Always Encrypted

Ne vždy je z hlediska bezpečnosti dostačující šifrovat citlivá data, která jsou uložena ve sloupci tabulky. V takovém případě je také nutné upravit SQL příkazy tak, aby prováděli ENCRYPT a DECRYPT, což vyžaduje zásah do samotné aplikace. Data jsou sice uložena v šifrované podobě, ale při procesování dotazu jsou dešifrována a přes síť zaslána aplikaci už v nešifrované podobě. Always Encrypted jde dál a jak název napovídá, data jsou jak uložena v šifrované podobě tak také zaslána jako výsledek aplikaci. Až ovladač na straně aplikace provede dešifrování dat a samotná aplikace s nimi pracuje již v běžné podobě. Vše je plně transparentní a proto není třeba provádět změnu v kódu aplikace, jak jsem již uvedl, o automatické šifrování/dešifrování dat se stará ovladač na straně aplikace. Je vyžadován .NET Framework 4.6 a zatím je podporován pouze .Net Framework Data Provider for SqlServer (který si můžete vyzkoušet třeba při použití Import/Export Wizard v Management Studiu). Volbu šifrovacího klíče a algoritmu provede vývojář v rámci definice sloupce tabulky na straně SQL Serveru.

 

Row-Level Security

Možnost přidělit oprávnění nad tabulkou nebo nad sloupcem pro vybrané uživatele není žádnou novinkou, ale co když se vyskytne komplikovanější požadavek ? Pojišťovací agent by měl mít přístup jen k zákazníkům v jeho regionu, manažer by měl mít možnost měnit a zobrazovat detaily pouze svých podřízených, lékař by měl mít přístup k informacím pouze svých pacientů. Obvykle máme však tabulky obsahující řádky o všech zákaznících, zaměstnancích nebo pacientech. Konfigurace oprávnění pouze na vybrané řádky nebyla k dispozici a toto bylo řešeno filtrem klauzule WHERE nebo specifickým programovým objektem jako je pohled/procedura/funkce. V MS SQL 2016 je možné vytvořit tzv. SECURITY POLICY, kterou přiřadíme tabulce. Při dotazu na data tabulky provede Security Policy filtrování na základě specifikované funkce a dotaz bude mít k dispozici pouze profiltrovaná data. Funkce, kterou Security Policy filtruje data, je plně pod kontrolou administrátora/programátora a může tak filtrovat stejně, jako kdyby použil klauzuli WHERE v samotném dotazu. Řádky, které budou zpracovány dotazem tak mohou být filtrovány na základě jména uživatele, jeho členství v databázové roli, názvu aplikace nebo počítače apod. Opět platí, že filtrování je plně transparentní, probíhá na pozadí a není nutné měnit dotazy aplikace na tabulku.

In-memory OLTP

V MS SQL 2014 opravdu hezký pokus. Jen kdyby nebylo těch drastických omezujících faktorů, které nám často bránili v reálném využití. Obecně se předpokládalo, že následující verze celou řadu omezení odstraní a proto celá řada vývojářů pouze vyčkává, než aby se složitě snažili obcházet celou řadu omezení nebo provést jen částečnou implementaci. Čekání je téměř u konce…

Výčet podstatných změn v In-memory OLTP :

  • ALTER operace memory optimalizované tabulky je podporována a lze tedy přidat/změnit/odebrat indexy, sloupce, contrainty
  • ALTER operace nativně kompilované procedury je podporována
  • MARS jsou podporovány
  • Podpora pro nativně kompilované skalární uživatelské funkce
  • Lze použít i non-BIN2 collations a kódové stránky jiné jež 1252
  • V nativně kompilovaných procedurách a funkcích mohou být použity doposud nedostupné operace jako OUTER JOIN, NOT, OR, IN, UNION, SELECT DISTINCT, COLLATE atd.
  • Částečná podpora paralelních operací

 

Columnstore Index

Columnstore index jsme měli možnost použít už v MS SQL 2012 a byl také rozšířen v  MS SQL 2014. Jeho cílem je zvýšit výkon analytických a report dotazů, u datových skladů při práci s velkým množstvím řádků. Další a naprosto zásadní rozšíření přináší MS SQL 2016, kde je odstraněno velké množství omezujících faktorů předchozích verzí a rozšíření použitelnosti.

  • Nad tabulkou může být vytvořen jeden updatable noncusltered columnstore index (tyto indexy byly v minulosti pouze read-only)
  • Nonclustered columnstore index může být filtrovaný a indexovat tak pouze část řádků tabulky
  • Columnstore index může být vytvořen nad memory-optimized tabulkou (doposud pouze nad disk-based tabulkou)
  • Nad tabulkou může být vytvořen jak clustered columnstore index tak i další rowstore indexy (doposud mohl být clustered columnstore index jediným nad celou tabulkou)
  • Tabulka může mít Primární klíč a současně clustered columnsote index viz předchozí bod
  • Bylo rozšířeno použití batch módu při operacích, kde to nebylo podporováno