DAX optimaliseren voor LuckyTemplates met behulp van DAX Studio – Formula Engines

Wanneer u uw datamodel en uw DAX voor LuckyTemplates optimaliseert, helpt het om te onthouden dat er achter de schermen twee engines draaien: de formule-engine en de opslag-engine .

Deze twee engines werken samen om de benodigde resultaten terug te sturen naar de gebruiker. Ze geven de resultaten weer in de vorm van een tabel of een schaalwaarde.

Inhoudsopgave

• De rol van de formule-engine
• Hoe de formule-engine werkt
• Belangrijkste beperkingen van de formule-engine
• Hoe de formule-engine DAX helpt optimaliseren voor LuckyTemplates
• Vermindering van de belasting van de formule-engine
• Tools die kunnen helpen bij het optimaliseren van DAX voor LuckyTemplates
• Conclusie

De rol van de formule-engine

In dit artikel gaan we ons concentreren op de formule-engine.

De formule-engine is de engine op het hoogste niveau die de hele architectuur van een query beheert.

Wat u ook doet tijdens het uitvoeren van een query of tijdens het maken van een berekende kolom of een berekende tabel, de formule-engine begint.

De formule-engine begrijpt de ontvangen vragen niet alleen in DAX, maar ook in MDX. Als u bijvoorbeeld Excel gebruikt, maakt u draaitabellen op basis van draaitabellen, en draaitabellen gebruiken eigenlijk de MDX-taal.

Hier komt de formule-engine om de hoek kijken. Omdat deze zowel DAX als MDX begrijpt, kunt u een ander LuckyTemplates-model gebruiken. De query's die vanuit dit datamodel worden verzonden, gebruiken DAX, terwijl de query's die uit het spilmodel komen, MDX gebruiken.

Hoe de formule-engine werkt

Het begrijpen van de query's die afkomstig zijn van de MDX-bron of de DAX-bron is slechts één factor in de prestaties van de formule-engine. Het doorloopt ook andere stappen om u te helpen bij het oplossen van uw vragen.

Eerst moet het een queryplan genereren dat de opslagengine begrijpt . Als engine op een lager niveau weet de storage-engine eigenlijk niet of een draaitabel in Excel of een visual in LuckyTemplates de query heeft uitgevoerd.

Bij het maken van een queryplan bouwt de formule-engine eerst een logisch queryplan en daarna een fysiek queryplan. Zowel het logische als het fysieke queryplan moeten op elkaar lijken.

Na voltooiing van het fysieke queryplan krijgt de gebruiker of de clienttool de resultatenset. Van daaruit bepaalt de clienttool hoe het de resultaten of gegevensset zal gebruiken om het eindresultaat aan de gebruiker weer te geven.

Belangrijkste beperkingen van de formule-engine

De formule-engine speelt een grote rol wanneer u DAX voor LuckyTemplates optimaliseert met DAX Studio. Het komt echter ook met enkele beperkingen.

Ten eerste gebruikt de formule-engine altijd een enkele kern om uw hele bewerking te beheren, ongeacht hoeveel CPU-kernen er in uw systeem beschikbaar zijn .

Wanneer ik mijn Taakbeheer open, zie je dat mijn CPU zes kernen heeft.

Ondanks dit feit zal de formule-engine nog steeds een van die zes kernen kiezen om mee te werken, terwijl het de opslag-engine verlaat om de rest te gebruiken.

Ten tweede heeft de formule-engine geen directe toegang tot uw database . Vanwege deze beperking moet u gegevens ofwel in het interne geheugen opslaan, ofwel in de database opslaan en een DirectQuery over die database maken.

Het vertrouwt ook op de opslagengine om de gegevens in de vorm van een datacache te krijgen. De formule-engine herhaalt vervolgens die gegevenscache om door te gaan voordat deze resultaten aan de eindgebruiker kan leveren.

Hoe de formule-engine DAX helpt optimaliseren voor LuckyTemplates

Soms, wanneer u probeert uw datamodel of uw DAX voor LuckyTemplates te optimaliseren, zult u merken dat de opslagengine vertraagt ​​terwijl deze query's uitvoert. In dit geval kunt u de formule-engine gebruiken bij het voltooien van de volledige berekening om het proces te optimaliseren.

Houd er rekening mee dat als de formule-engine uiteindelijk zelf de hele tabel opbouwt, de resultatenset die tijdens het proces is gemaakt, niet zal worden gebruikt in de volgende query's die door de clienttool worden gegenereerd als ze vergelijkbaar zijn met de eerder uitgevoerde query's . Maar als de opslagengine de datacache levert, kan die specifieke datacache in het geheugen worden bewaard, zodat deze verzoeken van de clienttool kan optimaliseren.

Hoe zal dat werken?

Laten we zeggen dat we een query schrijven die volledig door de opslagengine moet worden uitgevoerd, maar met enkele aspecten die door de formule-engine moeten worden berekend. In dit geval stuurt de opslag-engine een datacache terug naar de formule-engine en kan die datacache (voor het geval het een eenvoudige is) in het geheugen worden bewaard.

Als een soortgelijke vraag een paar seconden later binnenkomt, zal de formule-engine of de opslag-engine in plaats van het hele gegevensmodel opnieuw te scannen, die specifieke gegevenscache gebruiken, zodat de zoektijd kan worden verkort en de gebruikerservaring kan worden verbeterd. verbeterd.

Vermindering van de belasting van de formule-engine

Nogmaals, de formule-engine begrijpt DAX- en MDX-codes.

Dus als u , en andere taken gebruikt, kent de formule-engine alle functies die u gebruikt binnen de DAX-taal en kan deze alles zelf oplossen. Dit kan echter van invloed zijn op de prestaties van de query, vooral omdat de formule-engine alles probeert te doen met een enkele kern.

Daarom moeten we er ook op letten de belasting van de formule-engine te verminderen en de belasting van de opslag-engine te vergroten.

Een goed voorbeeld van hoe verschillend de berekening is binnen de formule-engine ten opzichte van de opslag-engine, is het gebruik van CROSSJOIN versus .

Wanneer u CROSSJOIN gebruikt, wordt slechts een beperkte hoeveelheid gegevens door de opslagengine geleid. Wat de rest van de berekening betreft, deze wordt allemaal uitgevoerd door de formule-engine. Ter vergelijking: het gebruik van SUMMARIZE betekent het uitvoeren van de volledige query binnen de opslagengine.

Dit zou natuurlijk ook afhangen van hoe SAMENVATTEN wordt gebruikt.

Als SAMENVATTEN wordt gebruikt als de binnenste functie, wordt deze zeker naar de opslag-engine geduwd. Maar in sommige gevallen wordt SUMMARIZE gebruikt in combinatie met een andere code waarvoor de formule-engine moet werken. In dit geval komt de formule-engine tussenbeide en doet het werk.

Als u weet waar de belasting naartoe gaat, kunt u de prestaties van uw query optimaliseren, vooral als u rekening houdt met de capaciteit en beperkingen van de engines die u tot uw beschikking heeft.

Tools die kunnen helpen bij het optimaliseren van DAX voor LuckyTemplates

Het optimaliseren van DAX wordt eenvoudiger als u de tools maximaliseert die dit mogelijk maken. DAX Studio is een van die tools.

Laten we het eerdere voorbeeld nemen, waarbij de formule-engine de volledige belasting van het voltooien van de berekening op zich neemt wanneer de functie SAMENVATTEN wordt gebruikt. DAX Studio kan u helpen uw code te herschrijven op een manier die SUMMARIZE naar de opslagengine duwt, waardoor de belasting van de formule-engine wordt vrijgemaakt. Dit verbetert mogelijk de prestaties van uw datamodel en query's.

Dit zou natuurlijk naadloos moeten werken voor eenvoudige vragen. Er zijn ook meer gecompliceerde scenario's.

U kunt bijvoorbeeld samengestelde modellen bouwen die gebruikmaken van twee storage-engines binnen het datamodel zelf. De ene zou voor Vertipaq kunnen zijn, terwijl de andere voor DirectQuery zou kunnen zijn. In dit geval moet uw database zodanig worden geoptimaliseerd dat de gegenereerde query's worden gebouwd voor dat specifieke relationele gegevensmodel.

Stel dat u twee tabellen in uw datummodel heeft: de tabel Producten en de tabel Verkoop. De Products-tabel bevindt zich in de Vertipaq-opslag, terwijl de Sales-tabel, die een grotere tabel is, rechtstreeks in de database wordt opgeslagen via een DirectQuery-verbinding.

Laten we er ook van uitgaan dat u de kolom Merk naar de matrix sleept, evenals de totale verkoopmaatstaf die afkomstig is uit de tabel Verkoop binnen de DirectQuery-verbinding.

In dit geval zal de formule-engine de bewerking tussen beide engines moeten uitvoeren.

Eerst worden de kolommen Productsleutel en Merk opgehaald uit de tabel Producten. Vervolgens haalt het de kolommen Nettoprijs, Hoeveelheid en Productcode op uit de tabel Verkoop. Zodra het de datacache van zowel Vertipaq als DirectQuery heeft, zal de formule-engine de datacache moeten nemen en proberen deze samen te voegen om de resultaten aan de eindgebruiker te verstrekken.

DAX Query-optimalisatietechnieken en -lessen
Queryprestaties en DAX Studio-instellingen
DAX-optimalisatie: waar vindt u de verborgen DAX-trap

Conclusie

De formule-engine speelt echt een grote rol wanneer u met DAX werkt. Het is echter van cruciaal belang om eerst te begrijpen hoe het werkt voordat u eraan begint. Het is essentieel om te leren hoe u de formule-engine en de opslag-engine naadloos kunt laten samenwerken, vooral als u wilt dat uw DAX-query's beter presteren.

Als engine op het hoogste niveau binnen de architectuur van analyseservices moet de formule-engine veel bewerkingen uitvoeren. Maar als u eenmaal de ins en outs van de opslag-engine begrijpt, kunt u erachter komen welke bewerking u in de opslag-engine moet pushen en welke u binnen de formule-engine moet laten.

In een aparte zelfstudie gaan we dieper in op de opslagengine.

Al het beste,