Storage Engine – dens rolle i optimering af DAX-forespørgsler i LuckyTemplates

I denne vejledning vil vi tage et kig på den anden motor inde i analysetjenester - lagermotoren.

Vi diskuterede motoren på topniveau, den, i et tidligere selvstudie. Når brugerne forstår, hvordan begge disse motorer fungerer, er det nemmere at optimere og forbedre ydeevnen af ​​dine DAX-forespørgsler.

Storagemotorens hovedformål er at arbejde direkte med databasen.

Formelmotoren har ikke direkte adgang til databasen, så den går normalt gennem lagermotoren til dette formål.

Lagermotoren kommer i to typer - importtilstand og DirectQuery . Du kan blande og matche begge typer i den samme datamodel for at skabe en sammensat model.

Indholdsfortegnelse

• Arbejder med importtilstand i lagermotoren
• Arbejde med DirectQuery i Storage Engine
• Arbejde med sammensatte modeller
• Andre kritiske punkter om lagermotoren
• Arbejder på komplicerede forespørgsler
• Konklusion

Arbejder med importtilstand i lagermotoren

Lad os først tale om importtilstanden. Dette er også mere almindeligt kendt som Vertipaq, men det kaldes også xVelocity eller In Memory Columnar Database.

Der er fire vigtige ting at forstå om, hvordan importtilstanden fungerer.

Først opretter Vertipaq en kopi af dataene direkte fra datakilden og gemmer dem i RAM i komprimeret format .

For det andet er de data, der behandles i importtilstanden, baseret på den sidste opdateringsoperation . Det betyder, at hvis du sidst opdaterede dine data i sidste uge, så er de data, du har med at gøre med, stadig de samme data fra sidste uge. Dette er især vigtigt, hvis du bruger en sammensat opsætning, hvor den ene tabel er i importtilstand, og den anden tabel er i DirectQuery-tilstand.

Lad os sige, at du har tabellen Produkter, som blev opdateret i sidste uge, i importtilstand. Med hensyn til salgstabellen besluttede du at kurse den gennem DirectQuery på grund af dens størrelse. Lad os også antage, at du opretter din rapport baseret på begge tabeller, hvor du bringer Brand-kolonnen ind og opretter et samlet salgsmål over den samme salgstabel. Du ønsker også at visualisere salgsbeløbet baseret på mærket.

Du skal først opdatere de data, der kommer fra importtilstand, fordi du kan ende med friske og opdaterede data fra DirectQuery og forældede data fra Vertipaq. Dette vil efterlade et par tomme rækker på din matrix og din visualisering.

Den næste ting, du skal vide om Vertipaq, er, at kun grundlæggende operationer som,,, eller er indbygget tilgængelige . Dette betyder, at hvis der er andre mere komplicerede operationer inkluderet i forespørgselsplanen, skal lagermotoren kalde formelmotoren for at løse denne del af koden.

Endelig er lagermotoren en meget optimeret database på grund af Vertipaqs søjlestruktur . Det betyder, at alle data er lagret kolonne for kolonne og ikke række for række. På grund af denne struktur vil Vertipaq altid være hurtigere end en DirectQuery-forbindelse, selvom du opretter indekser i din relationelle datamodel.

Arbejde med DirectQuery i Storage Engine

Den næste mulighed, vi har inde i LuckyTemplates-analysetjenesterne, er DirectQuery. Hvis du bruger DirectQuery-forbindelsen, fungerer analysetjenesterne kun som gennemløb for de forespørgsler, der sendes af formelmotoren.

Så lad os sige, at du skriver en forespørgsel. Formelmotoren genererer en forespørgselsplan. Det vil derefter videresende forespørgslen til lagermotoren, der allerede er oversat til databasens modersmål. Det meste af tiden kommer disse forespørgsler i SQL.

Hvis forespørgslen bruger DirectQuery, skal du forvente, at den hele tiden er opdateret. Der er ingen grund til at bekymre sig om, hvornår du sidst har opdateret dataene.

Processen med at optimere DAX-koden og datamodellen vil også afhænge af, hvordan relationsdatabasen blev oprettet. Hvis du har indekser i dine kolonner, så vil dine forespørgsler altid være optimeret. Men hvis din database ikke er optimeret i forhold til at oprette rapporter ved hjælp af analysetjenester eller LuckyTemplates, så kan du stå over for et par præstationsudfordringer. Så vær bevidst med at lave dine databaser bygget til rapportudvikling.

Arbejde med sammensatte modeller

Den tredje mulighed er at oprette en sammensat model, så du kan have en tabel i importtilstand og en anden tabel i DirectQuery.

Når du bruger to tabeller fra forskellige kilder, sender formelmotoren en anmodning til Vertipaq og en anden anmodning til DirectQuery-datakilden. I begge tilfælde vil analysetjenester også hente datacachen fra både Vertipaq og DirectQuery. Formelmotoren vil derefter bruge JOIN,, eller enhver iteration på begge datacaches, før resultaterne leveres til slutbrugeren.

Så lad os sige, at du prøver at visualisere salgsbeløbet efter produktets brand i din rapport. Formelmotoren sender en anmodning til Vertipaq, hvor den henter produktet, mærket og produktnøglen. Derefter vil den fra DirectQuery forsøge at hente salg, nettopris, salgsmængde og salgsproduktnøgle.

Når den har de to datacaches baseret på produktnøglen, vil den forbinde de to datacaches og beregne det samlede salgsbeløb. Det vil derefter præsentere resultaterne for slutbrugeren.

Andre kritiske punkter om lagermotoren

Nu hvor vi har dækket dens forskellige typer, er der et par andre kritiske faktorer, som du skal vide om storage-motoren for at hjælpe dig med at optimere dine DAX-forespørgsler.

Som jeg har nævnt tidligere, leverer lagermotoren datacachen tilbage til formelmotoren i form af en ukomprimeret datacache. Når du er i importtilstand, udføres anmodningen, der sendes tilbage til Vertipaq i processen, i et xmSQL-sprog.

XmSQL-sproget minder lidt om SQL, men er ikke helt det samme. Vi kommer til at tale om xmSWL i detaljer, når vi taler om forespørgselsplaner i en anden tutorial.

Det er også vigtigt at huske, at lagringsmotoren bruger alle de tilgængelige kerner i din CPU. Muligheden for at bruge flere kerner er fordelagtig, hvis du har flere segmenter i din datamodel.

Lad os sige, at du har en tabel i LuckyTemplates med 12 millioner rækker. Denne tabel vil derefter blive opdelt i 12 segmenter, fordi i både Power Pivot og LuckyTemplates, passer hvert segment til 1 million rækker. Dette er i modsætning til analysetjenester generelt, hvor et segment rummer 8 millioner rækker.

Så hvis jeg har seks kerner i min CPU, vil alle seks kerner scanne de første seks af de 12 segmenter på samme tid. Når de er færdige, vil de gå videre til de næste seks segmenter.

Men hvis jeg arbejder med analysetjenester, hvor standardsegmentet rummer 8 millioner rækker, vil kun to af mine seks kerner blive brugt - det ene segment vil behandle 8 millioner rækker, mens det andet behandler 4 millioner.

Arbejder på komplicerede forespørgsler

Tidligere nævnte jeg, at importtilstanden kun understøtter grundlæggende operationer som MIN, MAX, SUM, COUNT og GROUPBY. Så hvad sker der, hvis du arbejder med mere komplicerede forespørgsler?

Lad os sige, at du beslutter dig for at bruge en IF-sætning i rækkekonteksten eller en indlejret iteration som SUMX over tabellerne Produkter og Salg.

I dette tilfælde vil lagringsmotoren ikke være i stand til at løse forespørgslen på egen hånd. Det vil derefter kalde formelmotoren, som begynder at løse den komplekse beregning række for række inde i lagermotoren. Nogle vil måske mene, at dette er et gunstigt scenario, hvor begge motorer arbejder sammen - men det er langt fra sandheden.

Du kan se, når dette sker, kan datacachen produceret af lagermotoren ikke cachelagres, hvis der er et tilbagekaldsdata-ID i den pågældende forespørgsel. Så hvis du opdaterer det visuelle, skal den samme beregning udføres af både formelmotoren og lagermotoren, selvom du lige udførte den samme forespørgsel for et par sekunder siden. Dette vil føre til forsinkelser i ydeevnen og dårlig brugeroplevelse.

Bemærk også, at lagermotoren ikke ved, om forespørgsler blev udført ved hjælp af DAX eller MDX. Som vi nævnte tidligere, er det formelmotorens opgave at konvertere forespørgslerne til det rigtige sprog, før forespørgselsplanen videregives.

Til sidst sender formelmotoren forespørgsler ind i lagermotoren én efter én. Det betyder, at det virkelig er bedre at have flere segmenter, så den samlede scanningstid i Vertipaq kan reduceres, idet flere segmenter scannes på samme tid.

Konklusion

At forstå ins og outs af storage-motoren hjælper virkelig med at optimere dine DAX-forespørgsler, især hvis du bruger DAX Studio. Hvis du også har gennemgået selvstudiet, der forklarer formelmotoren, kan du træffe bedre beslutninger om, hvordan du opretter forespørgsler med bedre resultater.

Selvom formelmotoren fungerer som motoren på topniveau, er der ingen tvivl om, at den ikke kan præstere så godt, som den kan, hvis vi ikke maksimerer begge motorer.

Alt det bedste,