Dataindeksering i Vertipaq: Rækkelager versus kolonnelager

I denne tutorial skal vi dække forskellen på, hvordan dataindeksering fungerer i en relationel database versus i Vertipaq.

Relationelle databaser gemmer dataene på en række for række basis. På den anden side gør Vertipaq det kolonne for kolonne.

Lad os se, hvordan disse to måder at gemme og indeksere data på kan påvirke din rapportudviklingsproces, især når du kører dine forespørgsler.

Indholdsfortegnelse

• Dataindeksering pr. række
• Dataindeksering pr. kolonne
• Sammenligning af eksekveringstid i simple forespørgsler
• Sammenligning af eksekveringstid i mere komplicerede forespørgsler
• Konklusion

Dataindeksering pr. række

Lagring af data række for række er den traditionelle måde at gemme data på. Denne proces tager dog længere tid, hvilket vil påvirke din forespørgsels ydeevne.

Lad os sige, at vi har en tabel, der indeholder mærke, farve, køn, mængde og nettopris.

Hvis vi gemmer alt i denne tabel i en database, vil den gemme dataene i en række for række. Det er derfor, den traditionelle datalagringsstruktur også kaldes for rækkelager.

Først på samme linje gemmer den kolonneoverskrifterne i den første række - Brand, Farve, Køn, Kvantitet og Nettopris. Derefter går den videre til næste linje for at gemme de første elementer under hver kolonne - A. Datum, Azure, en blank, 1 og 103.2. Dette fortsætter række for række.

Så hvordan skal vi beregne foraf mængden ved hjælp af denne dataindekseringsmetode?

Først starter den med den første række, som indeholder kolonneoverskrifterne. Derefter hopper den ind i den næste linje og springer gennem de andre stykker data, indtil den når den første mængde, den ser, som er 1. Derefter hopper den fra linje til linje, kører gennem alle de data, hver række indeholder og samler alle mængder er fund.

Når den har afsat alle mængderne fra hver række, er det den eneste gang, beregningen er afsluttet.

Du kan sikkert forestille dig, hvor kedelig processen er, hvis du forbereder en LuckyTemplates-rapport, der bruger en DirectQuery-forbindelse til en SQL-datakilde. I dette tilfælde vil analysetjenester konvertere DAX-koden til SQL-sproget og derefter begynde at gennemgå datastrukturen række for række.

Dataindeksering pr. kolonne

For at undgå den langvarige proces, der er involveret, har du mulighed for at gemme dataene på en kolonne for kolonne basis gennem Vertipaq, når du vælger importtilstand.

Når du bruger kolonnelager i stedet for rækkelager, vil mærke, farve, køn, mængde og nettopris hver blive gemt i forskellige datastrukturer.

Lad os sige, at vi ønsker at få SUMMEN af værdierne i kolonnen Mængde. Der vil ikke være behov for at gå gennem mærket, farven og andre stykker data uden for kolonnen Antal. I en enkelt scanning læser den hele kolonnen Antal fra top til bund og opsummerer alle værdierne.

På grund af dette vil forespørgslerne blive udført hurtigere sammenlignet med at gøre det fra venstre mod højre.

Sammenligning af eksekveringstid i simple forespørgsler

For virkelig at se den enorme forskel mellem rækkelager og kolonnelager, lad os lave nogle testforespørgsler i både SQL og Vertipaq. Udførelsestiden skal fortælle os, hvor hurtig den ene proces er i forhold til den anden.

Lad os starte med en simpel forespørgsel i SQL. Vi skal beregne SUMMEN af kolonnen Antal i tabellen Salg.

Som du kan se, er den samlede udførelsestid 2,2 sekunder.

Lad os nu gå til DAX Studio og bruge EVALUATE- funktionen til at udføre den samme forespørgsel. Vi er nødt til at slå servertimingerne til og vente på, at sporingen er fuldført.

Vi skal også sikre os, at indstillingen "Ryd cache, så kør" er valgt, når vi kører forespørgslen.

Når forespørgslen er udført, vil du se, at det kun tager 3 millisekunder at fuldføre den samme forespørgsel, som vi gjorde i SQL tidligere.

Resultatsættet bør også matche for både SQL og DAX Studio. Hvis vi lægger dem side om side, kan du se, at vi returnerer den samme værdi.

Du kan prøve at køre forespørgslen et par gange mere for at se, hvor ensartet udførelsestiden er.

Sammenligning af eksekveringstid i mere komplicerede forespørgsler

Lad os denne gang sammenligne udførelsestiden, når vi kører mere komplicerede forespørgsler.

Lad os sige, at vi ønsker at identificere SUM of Sales Quantity for hvert mærke. For at gøre dette kan vi brugeoveraf hvert produkts mærke. I den lave kontekst vil vi også oprette en ny tabel kaldet Total Quantity, hvor vi skal henfor SUMMEN af Salgsmængden.

Hvis vi kører denne kode, kan du se, at den samlede eksekveringstid er 7 millisekunder.

I baggrunden kører denne kode faktisk to forespørgsler. Den første tager mærkekolonnen fra tabellen Produkter og udfører derefter en OUTER JOIN på produktnøglekolonnerne fra både kolonnen Salg og kolonnen Produkter.

Den anden forespørgsel henter blot mærkekolonnen fra tabellen Produkter.

Hvis jeg går til resultatskærmen, kan du se, at målingen for den samlede mængde er blevet opdelt baseret på hvert mærke.

Lad os nu gå til SQL-serveren og skrive den samme forespørgsel.

Vi skubber DaxStudio Sales-tabellen til næste linje med reference til Sales-tabellen AS S. Derefter vil vi også udføre en LEFT JOIN i DaxStudio Products-tabellen med reference til AS P, med S.Product Key lig med P. Produktnøgle. Vi vil også bruge P.Brand med SUMMEN af mængden og den samlede mængde i SELECT- sætningen. Endelig skal vi brugefor P.brand.

Når vi har kørt denne kode, får vi en tabel, der indeholder den samlede mængde adskilt af hvert mærke, hvilket er det samme, som vi tidligere fik i Vertipaq.

Hvad angår den samlede udførelsestid, forbliver den meget langsommere på 2,5 sekunder.

Konklusion

Det er tydeligt, hvor hurtigt kolonnelageret gennem Vertipaq virkelig er i forhold til rækkelageret i en SQL-database. Dette viser vigtigheden af ​​virkelig at lære den måde, dataindeksering fungerer på gennem forskellige platforme.

Det kan umiddelbart virke som et lille offer, hvis du stadig vælger at gå efter de 2,5 sekunder, som rækkebutikken kører din forespørgsel i forhold til 7 millisekunder. Men vi kører alle adskillige forespørgsler, når vi opretter vores rapporter, og alle disse udførelsestider vil lægge sammen, hvilket påvirker produktiviteten og brugeroplevelsen i det lange løb.