Storage Engine – Dens rolle i optimalisering av DAX-søk i LuckyTemplates

I denne opplæringen skal vi ta en titt på den andre motoren i analysetjenester - lagringsmotoren.

Vi diskuterte motoren på toppnivå, den, i en tidligere opplæring. Når brukere forstår hvordan begge disse motorene fungerer, er det lettere å optimalisere og forbedre ytelsen til DAX-søkene dine.

Lagringsmotorens hovedformål er å jobbe direkte med databasen.

Formelmotoren har ikke direkte tilgang til databasen, så den går vanligvis gjennom lagringsmotoren for dette formålet.

Lagringsmotoren kommer i to typer - importmodus og DirectQuery . Du kan mikse og matche begge typene i samme datamodell for å lage en sammensatt modell.

Innholdsfortegnelse

• Arbeider med importmodus i lagringsmotoren
• Arbeide med DirectQuery i lagringsmotoren
• Arbeid med komposittmodeller
• Andre kritiske punkter om lagringsmotoren
• Arbeider med kompliserte spørsmål
• Konklusjon

Arbeider med importmodus i lagringsmotoren

La oss først snakke om importmodusen. Dette er også mer kjent som Vertipaq, men det kalles også xVelocity eller In Memory Columnar Database.

Det er fire viktige ting å forstå om hvordan importmodusen fungerer.

Først lager Vertipaq en kopi av dataene rett fra datakilden og lagrer dem i RAM i komprimert format .

For det andre er dataene som behandles i importmodus basert på den siste oppdateringsoperasjonen . Dette betyr at hvis du sist oppdaterte dataene dine forrige uke, så er dataene du har å gjøre med fortsatt de samme dataene fra forrige uke. Dette er spesielt viktig hvis du bruker et sammensatt oppsett der en tabell er i importmodus og den andre tabellen er i DirectQuery-modus.

La oss si at du har produkter-tabellen, som ble oppdatert forrige uke, i importmodus. Når det gjelder salgstabellen, bestemte du deg for å kurse den gjennom DirectQuery på grunn av størrelsen. La oss også anta at du lager rapporten din basert på begge tabellene der du henter inn merkekolonnen og oppretter et mål for totalt salg over den samme salgstabellen. Du vil også visualisere salgsbeløpet basert på merkevaren.

Du må oppdatere dataene som kommer fra importmodus først fordi du kan ende opp med ferske og oppdaterte data fra DirectQuery, og utdaterte data fra Vertipaq. Dette vil etterlate noen tomme rader på matrisen og visualiseringen din.

Det neste du trenger å vite om Vertipaq er at bare grunnleggende operasjoner som , , eller er naturlig tilgjengelig . Dette betyr at hvis det er andre mer kompliserte operasjoner inkludert i spørringsplanen, må lagringsmotoren kalle formelmotoren for å løse denne delen av koden.

Til slutt er lagringsmotoren en svært optimalisert database på grunn av Vertipaqs kolonnestruktur . Dette betyr at alle data lagres kolonne for kolonne og ikke rad for rad. På grunn av denne strukturen vil Vertipaq alltid være raskere enn en DirectQuery-tilkobling selv om du oppretter indekser i relasjonsdatamodellen din.

Arbeide med DirectQuery i lagringsmotoren

Det neste alternativet vi har inne i LuckyTemplates-analysetjenestene er DirectQuery. Hvis du bruker DirectQuery-tilkoblingen, fungerer analysetjenestene bare som en gjennomgang for spørringene som sendes av formelmotoren.

Så la oss si at du skriver en spørring. Formelmotoren vil generere en spørringsplan. Den vil deretter videresende spørringen til lagringsmotoren, som allerede er oversatt til databasens morsmål. Mesteparten av tiden kommer disse spørringene i SQL.

Hvis spørringen bruker DirectQuery, forvent at den er oppdatert hele tiden. Det er ingen grunn til å bekymre deg for når du sist oppdaterte dataene.

Prosessen med å optimalisere DAX-koden og datamodellen vil også avhenge av hvordan relasjonsdatabasen ble opprettet. Hvis du har indekser i kolonnene dine, vil søkene dine alltid være optimalisert. Men hvis databasen din ikke er optimalisert når det gjelder å lage rapporter ved hjelp av analysetjenester eller LuckyTemplates, kan du møte noen ytelsesutfordringer. Så vær bevisst ved å lage databasene dine for rapportutvikling.

Arbeid med komposittmodeller

Det tredje alternativet er å lage en sammensatt modell slik at du kan ha en tabell i importmodus og en annen tabell i DirectQuery.

Når du bruker to tabeller fra forskjellige kilder, sender formelmotoren én forespørsel til Vertipaq og en annen forespørsel til DirectQuery-datakilden. I begge tilfeller vil analysetjenester også hente databufferen fra både Vertipaq og DirectQuery. Formelmotoren vil da bruke JOIN,, eller hvilken som helst iterasjon på begge databuffrene før resultatene leveres til sluttbrukeren.

Så la oss si at du prøver å visualisere salgsbeløpet etter produktets merke i rapporten. Formelmotoren vil sende en forespørsel til Vertipaq, hvor den vil hente produkt, merke og produktnøkkel. Deretter, fra DirectQuery, vil den prøve å hente salg, nettopris, salgskvantum og salgsproduktnøkkel.

Når den har de to databufferne basert på produktnøkkelen, vil den slå sammen de to databufferne og beregne det totale salgsbeløpet. Den vil deretter presentere resultatene for sluttbrukeren.

Andre kritiske punkter om lagringsmotoren

Nå som vi har dekket de forskjellige typene, er det noen andre kritiske faktorer du trenger å vite om lagringsmotoren for å hjelpe deg med å optimalisere DAX-søkene dine.

Som jeg har nevnt tidligere, gir lagringsmotoren databufferen tilbake til formelmotoren i form av en ukomprimert databuffer. Når du er i importmodus, utføres forespørselen som sendes tilbake til Vertipaq i prosessen i et xmSQL-språk.

xmSQL-språket ligner litt på SQL, men er ikke helt det samme. Vi skal snakke om xmSWL i detalj når vi snakker om spørringsplaner i en annen opplæring.

Det er også viktig å huske at lagringsmotoren bruker alle kjernene som er tilgjengelige i CPU-en din. Muligheten til å bruke flere kjerner er fordelaktig i tilfelle du har flere segmenter i datamodellen din.

La oss si at du har en tabell i LuckyTemplates med 12 millioner rader. Denne tabellen vil da bli delt inn i 12 segmenter fordi i både Power Pivot og LuckyTemplates, passer hvert segment til 1 million rader. Dette er i motsetning til analysetjenester generelt, hvor ett segment rommer 8 millioner rader.

Så hvis jeg har seks kjerner i CPU'en, vil alle seks kjerner skanne de første seks av de 12 segmentene samtidig. Når de er ferdige, vil de gå videre til de neste seks segmentene.

Men hvis jeg jobber med analysetjenester der standardsegmentet har 8 millioner rader, vil bare to av mine seks kjerner bli brukt – ett segment vil behandle 8 millioner rader mens det andre behandler 4 millioner.

Arbeider med kompliserte spørsmål

Tidligere nevnte jeg at importmodusen bare støtter grunnleggende operasjoner som MIN, MAX, SUM, COUNT og GROUPBY. Så hva skjer hvis du jobber med mer kompliserte spørsmål?

La oss si at du bestemmer deg for å bruke en IF-setning i radkonteksten, eller en nestet iterasjon som SUMX over produkt- og salgstabellene.

I dette tilfellet vil ikke lagringsmotoren kunne løse spørringen på egen hånd. Den vil da kalle opp formelmotoren, som vil begynne å løse den komplekse beregningen rad for rad inne i lagringsmotoren. Noen vil kanskje tro at dette er et gunstig scenario, med begge motorene som jobber sammen - men dette er langt fra sannheten.

Du ser, når dette skjer, kan ikke databufferen produsert av lagringsmotoren bufres i tilfelle det er en tilbakeringingsdata-ID i den aktuelle spørringen. Så hvis du oppdaterer det visuelle, vil den samme beregningen måtte gjøres av både formelmotoren og lagringsmotoren, selv om du nettopp utførte den samme spørringen for noen sekunder siden. Dette vil føre til ytelsesforsinkelser og dårlig brukeropplevelse.

Merk også at lagringsmotoren ikke vet om spørringer ble utført med DAX eller MDX. Som vi nevnte tidligere, er det formelmotorens jobb å konvertere spørringene til riktig språk før spørringsplanen sendes videre.

Til slutt sender formelmotoren spørringer inn i lagringsmotoren én etter én. Dette betyr at det virkelig er bedre å ha flere segmenter, slik at den totale skannetiden i Vertipaq kan reduseres, med flere segmenter som skannes samtidig.

Konklusjon

Å forstå inn- og utsiden av lagringsmotoren hjelper virkelig med å optimalisere DAX-spørringene dine, spesielt hvis du bruker DAX Studio. Hvis du også har gått gjennom veiledningen som forklarer formelmotoren, kan du ta bedre beslutninger om hvordan du oppretter søk med bedre resultater.

Selv om formelmotoren fungerer som motoren på toppnivå, er det ingen tvil om at den ikke kan yte så godt som den kan hvis vi ikke maksimerer begge motorene.

Beste ønsker,