Lagringsmotor i LuckyTemplates – VertiPaq-operatører og spørringer

Denne opplæringen vil diskutere om spørringene og lagringsmotoren i LuckyTemplates. Du vil lære hvordan operatører jobber bak beregningen og hvordan lagringsmotoren hjelper deg med å optimalisere DAX-kodenes ytelse.

VertiPaq-operatørene og spørringene lar deg overvåke utførelsen av hver kode slik at du kan forbedre dem om nødvendig.

Innholdsfortegnelse

• VertiPaq-operatører
• Storage Engine Queries
• Konklusjon

VertiPaq-operatører

VertiPaq har muligheten til å beregne enkle spørringer. Den har logiske operatorer som utfører din for å få svar.

Dette er VertiPaq logiske operatører:

• Skann
• Gruppe av
• Filter
• Sum
• Min
• Maks
• Telle
• DistinctCount
• Gjennomsnitt
• Stdev.S
• Stdev.P
• Var.S
• Var.P

Dette er de logiske og fysiske spørringsplanene som genereres av en eksempelspørring.

Når en linje har _Vertipaq , betyr det at VertiPaq-motoren gjør jobben selv. Hvis du ser på , vil du se at den har Sum_Vertipaq og Scan_Vertipaq . Disse to operatørene jobber med å skanne og summere FactSales' Quantity for å generere et svar.

I den fysiske spørringsplanen vil du også se en Sum_Vertipaq som bruker en ProjectionSpool . Det betyr at en spørring blir sendt til lagringsmotoren og deretter returnert til formelmotoren i en databuffer. Du vil også legge merke til at den bare har én rekord.

Kolonnen Records viser hvor mange rader som materialiseres fra lagringsmotoren til formelmotoren. Den trenger bare én post for å fungere effektivt. Flere poster tar lengre tid for spørringen å fullføre.

Hvis lagringsmotoren ikke kan utføre en forespørsel, tar formelmotoren over. Formelmotoren kan gjøre alt du ber om, men den er mye tregere.

Storage Engine Queries

Dette er en introduksjon til og hvordan du kan lese og forstå dem. Du kan bruke denne informasjonen til å optimalisere DAX-søket ditt for bedre ytelse. Husk alltid at databufferen som returneres av lagringsmotoren til formelmotoren, er i et ukomprimert format.

Dette er et eksempelsøk som vil bli brukt.

Hvis du kjører den og åpner fanen Physical Query Plan, vil du se ProjectionSpool- operatøren. Du må forstå hvordan det fungerer i bakgrunnen av beregningen for å produsere et resultat.

Lagringsmotorspørringer uttrykkes i et pseudo SQL-språk kalt . Det er ikke et ekte programmeringsspråk. Det er mer en visuell representasjon av hva motoren gjør i bakgrunnen.

Hvis du kjører eksempelspørringen i DAX Studio, vil den vise xmSQL. Den viser at spørringen velger SalesData's Quantity og summerer den fra Sales Data- tabellen.

Du vil legge merke til at tabellnavnet i spørringen er forskjellig fra xmSQL. xmSQL bruker Sales Data i stedet for FactSales som tabellnavn fordi DAX ikke liker å bruke Fact eller DIM som navn.

Nå, for å ha raskere DAX-ytelse, må du la lagringsmotoren fungere så mye som mulig. Den kan utføre enkel matematikk og aggregering mens den skanner etter dataene. Siden eksempelspørringen bare bruker, ble beregningen gjort i lagringsmotoren.

Den beste optimaliseringsteknikken er å finne det beste settet slik at lagringsmotoren gjør det meste av jobben og formelmotoren ganske enkelt gjør det som er igjen.

Konklusjon

Lagringsmotoren er ansvarlig for å få DAX til å fungere raskere. Den lar deg se prosessen bak hele beregningen ved hjelp av den logiske og fysiske spørreplanen. Du kan spore hvilken prosess som bremser hele ytelsen og deretter optimalisere den.

Hvis du vil vite mer om hvordan VertiPaq fungerer, bruk denne opplæringen og øv deg på å optimalisere DAX-kodene dine.