Dataindexering i Vertipaq: Radlagring kontra kolumnlagring

I den här handledningen kommer vi att täcka skillnaden på hur dataindexering fungerar i en relationsdatabas jämfört med i Vertipaq.

Relationsdatabaser lagrar data rad för rad. Å andra sidan gör Vertipaq det kolumn för kolumn.

Låt oss se hur dessa två sätt att lagra och indexera data kan påverka din rapportutvecklingsprocess, särskilt när du kör dina frågor.

Innehållsförteckning

• Dataindexering per rad
• Dataindexering per kolumn
• Jämföra exekveringstid i enkla frågor
• Jämföra exekveringstid i mer komplicerade frågor
• Slutsats

Dataindexering per rad

Att lagra data rad för rad är det traditionella sättet att lagra data. Den här processen tar dock längre tid, vilket kommer att påverka din frågas prestanda.

Låt oss säga att vi har en tabell som innehåller varumärke, färg, kön, kvantitet och nettopris.

Om vi ​​lagrar allt i den här tabellen i en databas, kommer den att lagra data i rad för rad. Det är därför den traditionella datalagringsstrukturen också kallas för radlagring.

Först, på samma rad, kommer det att lagra kolumnrubriker som finns på den första raden - varumärke, färg, kön, kvantitet och nettopris. Sedan går den vidare till nästa rad för att lagra de första objekten under varje kolumn — A. Datum, Azure, en blank, 1 och 103.2. Detta fortsätter rad för rad.

Så hur ska vi beräkna förav kvantiteten med denna dataindexeringsmetod?

Först börjar det med den första raden, som innehåller kolumnrubriker. Sedan hoppar den in på nästa rad och hoppar igenom de andra databitarna tills den kommer till den första kvantiteten den ser, vilket är 1. Sedan hoppar den från rad till rad, går igenom all data som varje rad innehåller och samlar alla kvantiteter är fynd.

När den väl har avsatt alla kvantiteter från varje rad är det enda gången som beräkningen är klar.

Du kan förmodligen föreställa dig hur tråkig processen är om du förbereder en LuckyTemplates-rapport som använder en DirectQuery-anslutning till en SQL-datakälla. I det här fallet kommer analystjänster att konvertera DAX-koden till SQL-språket och sedan börja gå igenom datastrukturen rad för rad.

Dataindexering per kolumn

För att undvika den utdragna processen har du möjlighet att lagra data kolumn för kolumn genom Vertipaq när du väljer importläge.

När du använder kolumnlager istället för radlager lagras Varumärke, Färg, Kön, Kvantitet och Nettopris i olika datastrukturer.

Låt oss säga att vi vill få SUMMA av värdena i kolumnen Kvantitet. Det kommer inte att finnas något behov av att passera genom varumärket, färgen och andra delar av data utanför kolumnen Kvantitet. I en enda skanning läser den hela kolumnen Kvantitet uppifrån och ned och summerar alla värden.

På grund av detta kommer frågorna att köras snabbare jämfört med att göra det från vänster till höger.

Jämföra exekveringstid i enkla frågor

För att verkligen se den enorma skillnaden mellan radbutik och kolumnbutik, låt oss göra några testfrågor i både SQL och Vertipaq. Exekveringstiden bör berätta hur snabb en process är jämfört med den andra.

Låt oss börja med en enkel fråga i SQL. Vi kommer att beräkna SUMMA för kolumnen Kvantitet i tabellen Försäljning.

Som du kan se är den totala exekveringstiden 2,2 sekunder.

Nu, låt oss gå till DAX Studio och använda EVALUATE -funktionen för att köra samma fråga. Vi måste slå på serverns timings och vänta på att spårningen ska slutföras.

Vi måste också se till att alternativet "Rensa cache sedan kör" är valt när vi kör frågan.

När frågan har körts kommer du att se att det bara tar 3 millisekunder att slutföra samma fråga som vi gjorde i SQL tidigare.

Resultatuppsättningen bör också matcha för både SQL och DAX Studio. Om vi ​​lägger dem sida vid sida kan du se att vi returnerar samma värde.

Du kan prova att köra frågan några gånger till för att se hur konsekvent körningstiden är.

Jämföra exekveringstid i mer komplicerade frågor

Den här gången ska vi jämföra körningstiden när vi kör mer komplicerade frågor.

Låt oss säga att vi vill identifiera SUMMA av försäljningskvantitet för varje varumärke. För att göra detta kan vi användaöverav varje produkts varumärke. I det låga sammanhanget kommer vi också att skapa en ny tabell som heter Total Quantity dit vi skaför summan av försäljningskvantiteten.

Om vi ​​kör den här koden kan du se att den totala exekveringstiden är 7 millisekunder.

I bakgrunden kör den här koden faktiskt två frågor. Den första tar kolumnen Varumärke från tabellen Produkter och kör sedan en OUTTER JOIN på produktnyckelkolumnerna från både kolumnen Försäljning och kolumnen Produkter.

Den andra frågan hämtar helt enkelt kolumnen Varumärke från tabellen Produkter.

Om jag går till resultatskärmen kan du se att måttet Total kvantitet har delats upp baserat på varje varumärke.

Låt oss nu gå till SQL-servern och skriva samma fråga.

Vi flyttar DaxStudio-försäljningstabellen till nästa rad, med hänvisning till försäljningstabellen AS S. Sedan kommer vi också att utföra en LEFT JOIN i DaxStudio Products-tabellen med referens AS P, med S.Product Key lika med P. Produktnyckel. Vi kommer också att använda P.Brand med summan av kvantitet och total kvantitet i SELECT -satsen. Äntligen ska vi användaför P.brand.

När vi kört den här koden får vi en tabell som innehåller den totala kvantiteten uppdelad av varje varumärke, vilket är samma sak som vi tidigare fick i Vertipaq.

När det gäller den totala exekveringstiden förblir den mycket långsammare på 2,5 sekunder.

Slutsats

Det är uppenbart hur snabb kolumnlagringen genom Vertipaq verkligen är i jämförelse med radlagringen i en SQL-databas. Detta visar vikten av att verkligen lära känna hur dataindexering fungerar genom olika plattformar.

Det kan tyckas vara en liten uppoffring till en början om du fortfarande väljer att gå under de 2,5 sekunder som radbutiken kör din fråga jämfört med 7 millisekunder. Men vi kör alla flera frågor när vi skapar våra rapporter och alla dessa körtider kommer att läggas ihop, vilket påverkar produktiviteten och användarupplevelsen i det långa loppet.