Dataindeksering i Vertipaq: radbutikk versus kolonnebutikk

I denne opplæringen skal vi dekke forskjellen på hvordan dataindeksering fungerer i en relasjonsdatabase versus i Vertipaq.

Relasjonsdatabaser lagrer dataene på rad for rad basis. På den annen side gjør Vertipaq det kolonne for kolonne.

La oss se hvordan disse to måtene å lagre og indeksere data på kan påvirke rapportutviklingsprosessen, spesielt når du kjører søkene dine.

Innholdsfortegnelse

• Dataindeksering per rad
• Dataindeksering per kolonne
• Sammenligning av utførelsestid i enkle spørringer
• Sammenligning av utførelsestid i mer kompliserte spørringer
• Konklusjon

Dataindeksering per rad

Lagring av data rad for rad er den tradisjonelle måten å lagre data på. Denne prosessen tar imidlertid mer tid, noe som vil påvirke søkets ytelse.

La oss si at vi har en tabell som inneholder merkevare, farge, kjønn, kvantitet og nettopris.

Hvis vi lagrer alt i denne tabellen i en database, vil den lagre dataene i en rad for rad. Det er derfor den tradisjonelle datalagringsstrukturen også kalles radlager.

Først, på samme linje, vil den lagre kolonneoverskriftene på den første raden - Merke, Farge, Kjønn, Kvantitet og Nettopris. Deretter går den videre til neste linje for å lagre de første elementene under hver kolonne - A. Datum, Azure, en blank, 1 og 103.2. Dette fortsetter rad for rad.

Så hvordan skal vi beregne forav mengden som bruker denne dataindekseringsmetoden?

Først starter den med den første raden, som inneholder kolonneoverskriftene. Deretter hopper den inn i neste linje og hopper gjennom de andre dataene til den kommer til den første mengden den ser, som er 1. Deretter hopper den fra linje til linje, går gjennom alle dataene hver rad inneholder og samler alle mengder er funn.

Når den har satt til side alle mengdene fra hver rad, er det den eneste gangen beregningen er fullført.

Du kan sikkert forestille deg hvor kjedelig prosessen er hvis du utarbeider en LuckyTemplates-rapport som bruker en DirectQuery-tilkobling til en SQL-datakilde. I dette tilfellet vil analysetjenester konvertere DAX-koden til SQL-språket, og deretter begynne å gå gjennom datastrukturen rad for rad.

Dataindeksering per kolonne

For å unngå den langvarige prosessen som er involvert, har du muligheten til å lagre dataene på en kolonne for kolonne gjennom Vertipaq når du velger importmodus.

Når du bruker kolonnelager i stedet for radlager, vil merkevare, farge, kjønn, kvantitet og nettopris hver lagres i forskjellige datastrukturer.

La oss si at vi ønsker å få SUMMEN av verdiene i kolonnen Antall. Det vil ikke være behov for å gå gjennom merkevare, farge og andre deler av data utenfor Antall-kolonnen. I en enkelt skanning leser den hele kolonnen Antall fra topp til bunn og summerer opp alle verdiene.

På grunn av dette vil spørringene bli utført raskere sammenlignet med å gjøre det fra venstre mot høyre.

Sammenligning av utførelsestid i enkle spørringer

For å virkelig se den enorme forskjellen mellom radlager og kolonnelager, la oss gjøre noen testspørringer i både SQL og Vertipaq. Utførelsestiden skal fortelle oss hvor rask en prosess er sammenlignet med den andre.

La oss starte med en enkel spørring i SQL. Vi skal beregne SUMMEN for Antall-kolonnen i Salg-tabellen.

Som du kan se, er den totale utførelsestiden 2,2 sekunder.

La oss nå gå til DAX Studio og bruke EVALUATE- funksjonen til å utføre den samme spørringen. Vi må slå på servertimingene og vente på at sporingen skal fullføres.

Vi må også sørge for at alternativet "Tøm buffer og kjør" er valgt når vi kjører spørringen.

Når spørringen er utført, vil du se at det bare tar 3 millisekunder å fullføre den samme spørringen vi gjorde i SQL tidligere.

Resultatsettet skal også samsvare for både SQL og DAX Studio. Hvis vi legger dem side om side, kan du se at vi returnerer samme verdi.

Du kan prøve å kjøre spørringen et par ganger til for å se hvor konsistent utførelsestiden er.

Sammenligning av utførelsestid i mer kompliserte spørringer

Denne gangen, la oss sammenligne utførelsestiden når vi kjører mer kompliserte spørringer.

La oss si at vi ønsker å identifisere SUM of Sales Quantity for hvert merke. For å gjøre dette kan vi brukeoverav hvert produkts merke. I den lave konteksten vil vi også lage en ny tabell kalt Totalt kvantitet der vi skalfor SUMMEN av salgsmengden.

Hvis vi kjører denne koden, kan du se at den totale utførelsestiden er 7 millisekunder.

I bakgrunnen kjører denne koden faktisk to spørringer. Den første tar merkekolonnen fra produkttabellen, og kjører deretter en YTRE JOIN på produktnøkkel-kolonnene fra både Salg-kolonnen og Produkter-kolonnen.

Den andre spørringen henter ganske enkelt merkekolonnen fra produkttabellen.

Hvis jeg går til resultatskjermen, kan du se at totalmengdemålet er delt opp basert på hvert merke.

La oss nå gå til SQL-serveren og skrive den samme spørringen.

Vi skyver DaxStudio Sales-tabellen til neste linje, og refererer til Sales-tabellen AS S. Deretter skal vi også utføre en LEFT JOIN i DaxStudio Products-tabellen referert til AS P, med S.Product Key lik P. Produktnøkkel. Vi kommer også til å bruke P.Brand med SUMMEN av Quantity og Total Quantity i SELECT -setningen. Til slutt skal vi brukefor P.brand.

Når vi kjører denne koden, får vi en tabell som inneholder den totale mengden adskilt av hvert merke, som er det samme som vi tidligere fikk i Vertipaq.

Når det gjelder den totale utførelsestiden, forblir den mye tregere på 2,5 sekunder.

Konklusjon

Det er tydelig hvor raskt kolonnelageret gjennom Vertipaq egentlig er i forhold til radlageret i en SQL-database. Dette viser viktigheten av å virkelig bli kjent med hvordan dataindeksering fungerer gjennom ulike plattformer.

Det kan virke som et lite offer i begynnelsen hvis du fortsatt velger å gå for de 2,5 sekundene radbutikken kjører søket ditt sammenlignet med 7 millisekunder. Men vi kjører alle flere søk når vi lager rapportene våre, og alle disse utførelsestidene vil legge seg opp, og påvirke produktiviteten og brukeropplevelsen i det lange løp.