Funktionerna i SQL Server 2016 du som jobbar med BI och datalager måste ha koll på

31 juli 2017

Tid för uppdatering

Äntligen är det sommar och semester! Jag tycker det är skönt när man i lugn och ro kan läsa ikapp och reflektera över nya features och uppdateringar i verktygen man jobbar med. Allt för att kunna hjälpa till och få ut det där lilla extra av datalagret när man sätter igång igen i höst.

Det har gått ett bra tag sedan SQL Server 2016 släpptes och inför det skrev Martin om de mest spännande nyheterna. Nu har vi jobbat på med 2016 i många projekt sedan släppet och det är dags att lista vilka features som är användbara på riktigt.

För att hjälpa till har jag i detta och ett kommande blogginlägg samlat några av de features i SQL Server 2016 som jag tycker kan vara värda att läsa in sig på. Jag bifogar fördjupningslänkar till varje feature.  En nyhet på senare tid är att många av dessa nu är tillgängliga för Standard edition, detta i och med Service Pack 1. Mycket bra för många att det inte längre krävs Enterprise-nivå på licensen för att dra nytta av riktigt bra funktioner. Dock kommer en del funktioner med vissa begränsningar i Standard edition på t.ex. tillåtet minne som kan allokeras.

Men då kör vi. Här kommer första delen av min lista:

1 – Columnstore index

En av höjdpunkterna för analys i SQL Server-motorn sedan 2012 som i 2016 blev ännu bättre är columnstore index. Det är ett sätt för SQL Server att hantera och lagra data kolumnbaserat istället för radbaserat. Förenklat kan man säga att antalet rader blir mindre viktigt. I stället blir det antalet unika förekomster av ett värde i en kolumn som ger komplexiteten. Till exempel skulle det i en faktatabell med 1 miljard rader med kolumnerna LÄN och IP-adress kunna gå att komprimera till max 21 förekomster för LÄN medan IP-adress antagligen skulle ge oss fler unika förekomster. Denna förändrade lagring gör att det blir både mindre data att söka igenom samt mindre lagring, dvs snabbare och billigare!

Den största förändringen i och med 2016 är att det går att uppdatera rader i tabeller med columnstore index. Man behöver inte ta bort och lägga till indexet vid data-uppdateringar och kombinera med andra traditionella index. Det går även att skapa Columnstore-index på in-memory tabeller och på så sätt kombinera två riktigt bra tekniker. Mer om det nedan.

Vid scenarion som t.ex. frågor mot en kombination av faktatabeller och dimensioner där stora mänger data ska grupperas och summeras kan ett columnstore index ge nästan magiska prestandaförbättringar. Här kan t.ex. Tableau-extrakt visa sig vara onödiga och det istället är snabbare att låta SQL Server sköta jobbet. (Jag kan få äta upp det påståendet när Tableaus nya Hyper-motor kommer i höst..)

Dock finns det frågor där ett traditionellt index är bättre. Framför allt när det handlar om att hitta specifika rader t.ex. för ETL där några specifika faktarader ska uppdateras.

Fördjupning:
https://docs.microsoft.com/en-us/sql/relational-databases/indexes/columnstore-indexes-overview

2 – Temporal data

Detta är en teknik där SQL Server out-of-the-box stödjer historisering av data och hanterar detta helt sömlöst.

Passar perfekt för hantering av audit eller som grund för dimensionshantering i t.ex. slowly-changing scenarion.

Det enda man behöver göra är att vid skapande av en tabell, eller senare, peka ut vad som ska vara historiseringstabellen och lägga till kolumner för en viss rads giltighetstid, dvs From- och To date.

När detta är gjort kan man sedan fråga denna tabeller om hur en viss rad såg ut vid ett givet tillfälle, t.ex. orderstatus för order 100 klockan 10 igår. Som ses på bilden nedan behöver man inte tänka på hur data historiseras eller rör sig till historiseringstabellen det sköter sql server.

Fördjupning:
https://docs.microsoft.com/en-us/sql/relational-databases/tables/temporal-table-usage-scenarios

3 – In-Memory OLTP

In-Memory OLTP är en teknik där arbetsminnet kan användas för att lagra tabeller. I och med 2016 har in-memory tabellerna och tekniken runt dem förbättrats avsevärt och stödjer nu det mesta i SQL. Allt från stored procedures till triggers och gör dessutom att man blir oberoende av IO och eliminerar LOCKs.

Trots att namnet nämner OLTP finns det scenarion där In-Memory kan användas även inom BI och ETL. När man arbetar radbaserat i t.ex. ETL för stage och arbetstabeller och behöver göra operationer per rad kan det passa väldigt bra. Men använd inte detta för columnstore index-scenarion där man vill jobba med grupperingar och summeringar över stora datamängder. Då finns stor risk att du blir besviken.

Fördjupning 1:
https://blogs.msdn.microsoft.com/sqlserverstorageengine/2016/11/17/in-memory-oltp-in-standard-and-express-editions-with-sql-server-2016-sp1/

Vill man få ut ännu mer prestanda kan man dessutom arbeta med förkompilerad kod tillsammans med dessa tabeller för att än mer utnyttja fördelarna med tekniken.

Fördjupning 2:
https://docs.microsoft.com/en-us/sql/relational-databases/in-memory-oltp/creating-natively-compiled-stored-procedures

4 – Query store

Prestanda och tuning är som vi alla vet något som det läggs mycket tid på. Som tur är finns nu en feature i SQL Server som kan underlätta det arbetet. I query store finns verktyg både för att analysera hur olika frågors query plans blir samt välja vilken query plan en viss fråga ska få. Vill du t.ex. premiera en resurssnål plan framför en snabb?

Här är en länk där du kan läsa mer om hur query store kan aktiveras samt hur du kan använda den.
https://blogs.technet.microsoft.com/dataplatform/2017/01/31/query-store-how-it-works-how-to-use-it/

 

I nästa blogginlägg fortsätter listan med fler riktigt bra funktioner för oss som jobbar med analys och datalager.

Har du frågor om hur du kan utnyttja de olika teknikerna bäst i just ditt datalager tveka inte att höra av dig till oss!