Optimalisering av DAX for LuckyTemplates ved hjelp av DAX Studio – Formelmotorer

Når du optimaliserer datamodellen og DAX for LuckyTemplates, hjelper det å huske at det er to motorer som kjører bak kulissene – formelmotoren og lagringsmotoren .

Disse to motorene jobber sammen for å returnere de nødvendige resultatene tilbake til brukeren. De gir resultatene satt i form av en tabell eller en skalaverdi.

Innholdsfortegnelse

• Formelmotorens rolle
• Hvordan Formelmotoren fungerer
• Hovedbegrensninger for formelmotoren
• Hvordan Formula Engine hjelper til med å optimalisere DAX for LuckyTemplates
• Reduserer belastningen på formelmotoren
• Verktøy som kan bidra til å optimalisere DAX for LuckyTemplates
• Konklusjon

Formelmotorens rolle

I denne artikkelen skal vi fokusere på formelmotoren.

Formelmotoren er motoren på toppnivå som administrerer hele arkitekturen til en spørring.

Uansett hva du gjør mens du utfører en spørring eller oppretter en beregnet kolonne eller en beregnet tabell, starter formelmotoren.

Formelmotoren forstår forespørslene mottatt ikke bare i DAX, men også i MDX. For eksempel, når du bruker Excel, lager du pivotmodeller basert på pivottabeller, og pivottabeller bruker faktisk MDX-språk.

Det er her formelmotoren starter. Fordi den forstår både DAX og MDX, kan du bruke en annen LuckyTemplates-modell. Spørringene som sendes fra denne datamodellen vil bruke DAX, mens spørringene som kommer fra pivotmodellen vil bruke MDX.

Hvordan Formelmotoren fungerer

Å forstå spørringene som kommer enten fra MDX-kilden eller DAX-kilden er bare én faktor i formelmotorens ytelse. Den går også gjennom andre trinn for å hjelpe deg med å jobbe med spørsmålene dine.

Først må den generere en spørringsplan som lagringsmotoren forstår . Som motor på lavere nivå, vet ikke lagringsmotoren om en pivottabell i Excel eller en visualisering i LuckyTemplates utførte spørringen.

Når du oppretter en spørringsplan, bygger formelmotoren først en logisk spørringsplan, deretter oppretter den en fysisk spørringsplan. Både den logiske og den fysiske spørringsplanen skal se ut som hverandre.

Etter å ha fullført den fysiske spørringsplanen, får brukeren eller klientverktøyet resultatene satt. Derfra dikterer klientverktøyet hvordan det vil bruke resultatene eller datasettet for å vise sluttresultatet til brukeren.

Hovedbegrensninger for formelmotoren

Formelmotoren spiller en stor rolle når du optimaliserer DAX for LuckyTemplates ved hjelp av DAX Studio. Det kommer imidlertid også med noen begrensninger.

For det første bruker formelmotoren alltid en enkelt kjerne for å administrere hele operasjonen din uavhengig av hvor mange CPU-kjerner som er tilgjengelige i systemet ditt .

Når jeg åpner Task Manager, vil du se at CPU-en min har seks kjerner.

Til tross for dette faktum, vil formelmotoren fortsatt velge en av disse seks kjernene å jobbe med, mens den lar lagringsmotoren bruke resten.

For det andre har ikke formelmotoren direkte tilgang til databasen din . På grunn av denne begrensningen, må du lagre data enten i internminnet, eller du kan lagre i databasen og lage en DirectQuery over den databasen.

Den er også avhengig av lagringsmotoren for å få dataene i form av en databuffer. Formelmotoren itererer deretter over denne databufferen for å fortsette før den kan gi resultater til sluttbrukeren.

Hvordan Formula Engine hjelper til med å optimalisere DAX for LuckyTemplates

Noen ganger, når du prøver å optimalisere datamodellen din eller DAX for LuckyTemplates, vil du legge merke til at lagringsmotoren går langsommere når den utfører spørringer. I dette tilfellet kan du bruke formelmotoren til å fullføre hele beregningen for å optimalisere prosessen.

Merk at hvis formelmotoren ender opp med å bygge hele tabellen på egen hånd, vil ikke resultatsettet som er opprettet i prosessen, bli brukt i de påfølgende spørringene som vil bli generert av klientverktøyet hvis de ligner på spørringene som ble utført tidligere . Men i tilfelle lagringsmotoren gir databufferen, kan den aktuelle databufferen beholdes i minnet slik at den kan optimalisere forespørsler som kommer fra klientverktøyet.

Hvordan vil det fungere?

La oss si at vi skriver en spørring som skal kjøres fullstendig av lagringsmotoren, men med noen aspekter som skal beregnes av formelmotoren. I dette tilfellet vil lagringsmotoren sende en databuffer tilbake til formelmotoren, og den databufferen (i tilfelle det er en enkel) kan beholdes i minnet.

Nå, hvis en lignende spørring kommer inn noen sekunder senere, i stedet for å skanne hele datamodellen igjen, vil formelmotoren eller lagringsmotoren bruke den aktuelle databufferen slik at spørringstiden kan reduseres og brukeropplevelsen kan forbedret.

Reduserer belastningen på formelmotoren

Igjen forstår formelmotoren DAX- og MDX-koder.

Så hvis du bruker,og andre oppgaver, formelmotoren kjenner alle funksjonene du bruker i DAX-språket og vil kunne løse alt på egen hånd. Dette kan imidlertid påvirke ytelsen til spørringen, spesielt siden formelmotoren prøver å gjøre alt ved å bruke en enkelt kjerne.

Dette er grunnen til at vi også må være oppmerksomme på å redusere belastningen på formelmotoren og øke belastningen på lagringsmotoren.

Et godt eksempel på hvor forskjellig beregningen er innenfor formelmotoren versus lagringsmotoren vil være bruken av CROSSJOIN versus.

Når du bruker CROSSJOIN, vil kun en begrenset mengde data sendes gjennom lagringsmotoren. Når det gjelder resten av beregningen, vil alt utføres av formelmotoren. Til sammenligning betyr bruk av SUMMARIZE å utføre hele spørringen i lagringsmotoren.

Dette vil selvfølgelig også avhenge av hvordan SUMMARIZE brukes.

Hvis SUMMARIZE brukes som den innerste funksjonen, vil den definitivt skyves ned til lagringsmotoren. Men i noen tilfeller brukes SUMMARIZE sammen med en annen kode som krever at formelmotoren fungerer. I dette tilfellet vil formelmotoren gå inn og gjøre jobben.

Å vite hvor lasten går, kan hjelpe deg med å optimalisere søkets ytelse, spesielt når du husker hva kapasiteten og begrensningene er for motorene du har til rådighet.

Verktøy som kan bidra til å optimalisere DAX for LuckyTemplates

Optimalisering av DAX vil være enklere hvis du maksimerer verktøyene som gjør det mulig. DAX Studio er et av disse verktøyene.

La oss ta eksempelet tidligere der formelmotoren tar på seg hele belastningen med å fullføre beregningen når SUMMARIZE-funksjonen brukes. DAX Studio kan hjelpe deg med å skrive om koden din på en måte som skyver SUMMARIZE inn i lagringsmotoren, og frigjør belastningen på formelmotoren. Dette forbedrer potensielt ytelsen til datamodellen og spørringene dine.

Selvfølgelig skal dette fungere sømløst for enkle spørsmål. Det er også mer kompliserte scenarier.

Du kan for eksempel bygge sammensatte modeller som bruker to lagringsmotorer i selve datamodellen. Den ene kan være for Vertipaq, mens den andre er for DirectQuery. I dette tilfellet må databasen din optimaliseres på en måte som gjør at spørringene som genereres, bygges for den spesifikke relasjonsdatamodellen.

La oss si at du har to tabeller inne i datomodellen din – Produkttabellen og Salg-tabellen. Produkttabellen er i Vertipaq-lageret, mens salgstabellen, som er en større tabell, lagres direkte i databasen gjennom en DirectQuery-tilkobling.

La oss også anta at du drar merkekolonnen inn i matrisen, så vel som Totalt salg-målet som kommer fra salgstabellen i DirectQuery-tilkoblingen.

I dette tilfellet må formelmotoren utføre operasjonen mellom begge motorene.

Først vil den hente produktnøkkel- og merkekolonnene fra produkttabellen. Deretter vil den hente nettopris-, kvantum- og produktnøkkel-kolonnene fra salgstabellen. Når den har databufferen fra både Vertipaq og DirectQuery, må formelmotoren ta databufferen og prøve å bli med dem for å gi resultatene til sluttbrukeren.

Konklusjon

Formelmotoren spiller virkelig en stor rolle når du jobber med DAX. Det er imidlertid viktig å forstå hvordan det fungerer først før du hopper inn. Å mestre hvordan du får formelmotoren og lagringsmotoren til å fungere sømløst sammen er nøkkelen, spesielt hvis du vil at DAX-søkene dine skal gi bedre resultater.

Som motoren på toppnivå i analysetjenestearkitekturen, må formelmotoren utføre mange operasjoner. Men når du også forstår inns og utsidene av lagringsmotoren, kan du finne ut hvilken operasjon du skal skyve inn i lagringsmotoren og hvilken du skal la være i formelmotoren.

Vi vil grave dypere inn i lagringsmotoren i en egen opplæring.

Beste ønsker,