Lagermotor i LuckyTemplates – VertiPaq-operatører og -forespørgsler

Denne tutorial vil diskutere om lagringsmotorforespørgsler i LuckyTemplates. Du lærer, hvordan operatører arbejder bag beregningen, og hvordan storage-motoren hjælper dig med at optimere dine DAX-koders ydeevne.

VertiPaq-operatørerne og forespørgslerne giver dig mulighed for at overvåge udførelsen af ​​hver kode, så du kan forbedre dem, hvis det er nødvendigt.

Indholdsfortegnelse

• VertiPaq-operatører
• Storage Engine-forespørgsler
• Konklusion

VertiPaq-operatører

VertiPaq har evnen til at beregne simple forespørgsler. Det har logiske operatorer, der udfører din for at få svar.

Disse er de logiske VertiPaq-operatorer:

• Scan
• GroupBy
• Filter
• Sum
• Min
• Maks
• Tælle
• DistinctCount
• Gennemsnit
• Stdev.S
• Stdev.P
• Var.S
• Var.P

Disse er de logiske og fysiske forespørgselsplaner, der genereres af en eksempelforespørgsel.

Når en linje har _Vertipaq , betyder det, at VertiPaq-motoren udfører arbejdet selv. Hvis du ser på , vil du se, at den har Sum_Vertipaq og Scan_Vertipaq . Disse to operatører arbejder på at scanne og summere FactSales' mængde for at generere et svar.

I den fysiske forespørgselsplan vil du også se en Sum_Vertipaq , som bruger en ProjectionSpool . Det betyder, at en forespørgsel sendes til lagermotoren og derefter returneres til formelmotoren i en datacache. Du vil også bemærke, at den kun har én rekord.

Kolonnen Records viser, hvor mange rækker der bliver materialiseret fra lagermotoren til formelmotoren. Det kræver kun én post for at fungere effektivt. Flere registreringer tager længere tid for forespørgslen at fuldføre.

Hvis lagermotoren ikke kan udføre en anmodning, tager formelmotoren over. Formelmotoren kan alt, hvad du beder om, men den er meget langsommere.

Storage Engine-forespørgsler

Dette er en introduktion til og hvordan man læser og forstår dem. Du kan bruge disse oplysninger til at optimere din DAX-forespørgsel for en bedre ydeevne. Husk altid, at datacachen, der returneres af lagermotoren til formelmotoren, er i et ukomprimeret format.

Dette er en eksempelforespørgsel, der vil blive brugt.

Hvis du kører det og åbner fanen Fysisk forespørgselsplan, vil du se ProjectionSpool- operatøren. Du skal forstå, hvordan det fungerer i baggrunden af ​​beregningen for at frembringe et resultat.

Storage engine-forespørgsler er udtrykt i et pseudo SQL-sprog kaldet . Det er ikke et rigtigt programmeringssprog. Det er mere en visuel repræsentation af, hvad motoren laver i baggrunden.

Hvis du kører eksempelforespørgslen i DAX Studio, vil den vise xmSQL. Det viser, at forespørgslen vælger SalesData's Quantity og summerer det fra Sales Data- tabellen.

Du vil bemærke, at tabelnavnet i forespørgslen er forskelligt fra xmSQL. xmSQL'en bruger Sales Data i stedet for FactSales som tabelnavnet, fordi DAX ikke kan lide at bruge Fact eller DIM som navne.

Nu, for at få hurtigere DAX-ydeevne, skal du lade storage-motoren arbejde så meget som muligt. Den kan udføre simpel matematik og aggregering, mens den scanner efter dataene. Da eksempelforespørgslen kun bruger, blev beregningen foretaget i lagermotoren.

Den bedste optimeringsteknik er at finde ud af det bedste sæt, så lagermotoren udfører det meste af arbejdet, og formelmotoren simpelthen gør det, der er tilbage.

Konklusion

Lagermotoren er ansvarlig for at få DAX til at arbejde hurtigere. Det giver dig mulighed for at se processen bag hele beregningen ved hjælp af den logiske og fysiske forespørgselsplan. Du kan spore, hvilken proces der bremser hele ydeevnen og derefter optimere den.

Hvis du vil vide mere om, hvordan VertiPaq fungerer, så brug denne vejledning og øv dig i at optimere dine DAX-koder.