Denne tutorial vil diskutere materialisering af datacaches i DAX Studio. Dette indlæg viser, hvordan det påvirker din beregning, mens det genererer resultater med din forespørgsel. Du vil lære, hvilken materialisering der er bedre for at maksimere DAX's ydeevne.
Der er to ideer om materialisering: tidlig materialisering og sen materialisering .
Indholdsfortegnelse
Tidlig materialisering
Tidlig materialisering er, når antallet af materialiserede rækker er større end antallet af rækker, der er nødvendige for output.
Hvis dit output er en tabel efter kalenderår, og du har fem års data, er det unødvendigt at bringe en masse materialiserede rækker. Den bedste praksis er at have antallet af materialiserede rækker lig med antallet af nødvendige rækker. Det er dog ikke altid tilfældet, fordi det afhænger af kompleksiteten af dinog dataopsætning.
Husk altid, at data består af kolonner. Så når formelmotoren skal arbejde på en tabel, samles kolonner igen i et tabelformat, som er materialiseringen. I en tidlig materialiseringsidé sender lagermotoren datacache til formelmotoren. Formelmotoren arbejder derefter på denne cache og udfører komplekse processer.
Tidlig materialisering kan være forårsaget af at have komplekse joinforbindelser eller et mange-til-mange forhold i dine datamodeller. Det kan også være forårsaget af komplekse filtre eller iteratorer.
Det er ikke forkert at have komplekse mål; du skal bare indstille dem korrekt for at udnytte lagermotoren så meget som muligt.
Sen materialisering
Sen materialisering er, når du har antallet af materialiserede rækker lig med eller tæt på antallet af rækker, der er nødvendige for dit output.
Lagermotoren udfører næsten alt arbejdet og efterlader intet til formelmotoren. Dette gør hele beregningen hurtigere.
Disse er eksempler på forespørgsler om tidlig og sen materialisering:
Før du kører disse forespørgsler, skal du sørge for at rydde cachen. Dette vil få dine forespørgsler til at køre mod den kolde cache. Hvis du kører din DAX uden at rydde cachen, får du dette resultat:
Den samlede udførelsestid er kun 1861 millisekunder, fordi den allerede brugte en cache. Så ryd altid din cache, før du kører dine forespørgsler.
Hvis du kører Early Materialization-forespørgslen, kan du se, at den samlede tid, det tog, er 9485 millisekunder. Det genererede en datacache og et output med én række, men returnerede 25 millioner rækker.
Du behøver ikke materialisere 25 millioner rækker for at få et resultat på én række, fordi det tager tid og sænker DAX's ydeevne.
Hvis du kører Late Materialization-forespørgslen, kan du se, at hele beregningen kun tog 1340 millisekunder. Det genererede også 2 datacaches, hvor hver returnerede 5003 rækker.
Hvis du ser på den fysiske forespørgselsplan, kan du se 5000 rækker. De har ikke lige mange rækker. Server Timings' resultat vil nogle gange have en lille uoverensstemmelse med det nøjagtige antal rækker i forespørgselsplanen.
Så fra at arbejde på én datacache med 25 millioner rækker, har du nu to datacaches med 5003 rækker. Det er derfor, at arbejde med Later Materialization får hurtigere resultater end Early Materialization.
Inde i hver materialiseringsforespørgsel
Ved blot at se på forespørgslen kan du allerede se, at den senere materialisering er hurtigere. Tidlig materialisering-forespørgsel tæller rækkerne i en opsummeret tabel.
Tabellen, der er opsummeret og materialiseret, er større end blot at gøre enaf på bordet, hvilket er, hvad Late Materialization-forespørgslen gør.
Hvis din forespørgsel er langsom, skal du starte med at se på, hvor mange rækker der trækkes i din forespørgsel, og hvor mange der er nødvendige for outputtet. Du kan også gå til den logiske forespørgselsplan og følge den arbejdsgang, der foregår i beregningen.
Konklusion
Materialisering sker, når dine forespørgsler trækker kolonner eller rækker fra din datamodel. Denne proces sker naturligt, når din motor henter data fra din datamodel for at give resultater til din forespørgsel.
Der kan dog opstå problemer, hvis din DAX trækker for mange rækker, end hvad der er nødvendigt for resultatet. Dette problem kan løses ved at forenkle din DAX til at udføre specifikke processer.
Denne blog indeholder LuckyTemplates TOPN DAX-funktionen, som giver dig mulighed for at få unik indsigt fra dine data, hvilket hjælper dig med at træffe bedre markedsføringsbeslutninger.
Find ud af, hvorfor det er vigtigt at have en dedikeret datotabel i LuckyTemplates, og lær den hurtigste og mest effektive måde at gøre det på.
Denne korte vejledning fremhæver LuckyTemplates mobilrapporteringsfunktion. Jeg vil vise dig, hvordan du kan udvikle rapporter effektivt til mobilenheder.
I denne LuckyTemplates Showcase gennemgår vi rapporter, der viser professionel serviceanalyse fra et firma, der har flere kontrakter og kundeengagementer.
Gå gennem de vigtigste opdateringer til Power Apps og Power Automate og deres fordele og implikationer for Microsoft Power Platform.
Opdag nogle almindelige SQL-funktioner, som vi kan bruge, såsom streng, dato og nogle avancerede funktioner til at behandle eller manipulere data.
I denne tutorial lærer du, hvordan du opretter din perfekte LuckyTemplates-skabelon, der er konfigureret til dine behov og præferencer.
I denne blog vil vi demonstrere, hvordan man lagdelte feltparametre med små multipler for at skabe utrolig nyttig indsigt og visuals.
I denne blog vil du lære, hvordan du bruger LuckyTemplates rangerings- og brugerdefinerede grupperingsfunktioner til at segmentere et eksempeldata og rangordne det efter kriterier.
I denne tutorial vil jeg dække en specifik teknik omkring, hvordan du kun viser Kumulativ Total op til en bestemt dato i dine visuals i LuckyTemplates.
