Gegevenscaches in een DAX-berekening

In deze zelfstudie leert u wat gegevenscaches doen in een DAX-berekening. U zult begrijpen hoe ze werken met de formule- en opslagengines om antwoorden op uw vragen te geven.

Inhoudsopgave

• Wat zijn gegevenscaches?
• Wat zijn de belangrijkste kenmerken?
• Waar vindt u gegevenscaches?
• Conclusie

Wat zijn gegevenscaches?

De opslag-engine communiceert met de formule-engine in de vorm van een gegevenscache.

Als u zich herinnert uit de vorige blogberichten over de DAX-querystructuur, weet u dat de formule-engine gegevens opvraagt ​​bij de opslag-engine. De laatste gaat vervolgens naar de database, haalt verschillende soorten gegevens op en stuurt deze vervolgens terug naar de formule-engine in de vorm van een gegevenscache.

De opslagengine kan eenvoudige wiskunde en aggregaties uitvoeren, waardoor deze sneller wordt. Het biedt ook parallellisme dat meerdere gegevenscaches tegelijk kan vullen. Het genereren van een antwoord op één query voor de opslagengine kan enige tijd in beslag nemen. Maar als u alle verschillende query's voor de opslagengine bij elkaar optelt, zullen de resultaten niet hetzelfde zijn omdat het meer dan één gegevenscache vult.

De formule-engine daarentegen werkt aan complexe zoekopdrachten. Omdat het een engine met één thread is, kan deze slechts één laatste geconsolideerde gegevenscache gebruiken. Het begint te werken aan de datacache zodra alle verzoeken zijn gevuld door de opslagengine.

Als het verzoek van de formule-engine exact hetzelfde is als het vorige verzoek, wordt de eerder geretourneerde cache opnieuw gebruikt. De storage-engine is slim genoeg om dezelfde datacache te retourneren als dezelfde aanvraag wordt ontvangen. Dit maakt de prestaties van de DAX sneller omdat de gegevens al in de cache zijn opgeslagen.

Wanneer u een meting uitvoert, is het belangrijk om deze uit te voeren tegen een koude cache; vermijd altijd het uitvoeren van uw vragen in de warme cache. Een warme cache betekent dat de gegevenscache van de opslagengine al is gevormd en klaar is om te worden geretourneerd.

Wat zijn de belangrijkste kenmerken?

Gegevenscaches zijn tabellen die in het geheugen zijn gematerialiseerd, wat tijd kost en RAM opeet. Houd er altijd rekening mee dat de materialisatie zo laag mogelijk moet zijn.

Een ander belangrijk kenmerk is dat deze caches ongecomprimeerd zijn . Zodra het uit de opslagengine komt en naar de formule-engine wordt verzonden, wordt de datacache een niet-gecomprimeerde volledige tabel in het geheugen. Deze uitvoering is veel langzamer dan een verzoek van een peer-opslagengine dat zich allemaal in het geheugen bevindt en gecomprimeerd is.

Er is geen probleem met het gebruik van de formule-engine; u hoeft alleen maar de opslagengine het werk zoveel mogelijk te laten doen.

Gegevenscaches zijn ook tijdelijk. Ze bestaan ​​voor een tijdje en dan zijn ze weg. Ook al zijn ze in het geheugen gematerialiseerd, ze zijn niet persistent, dus ze worden gewist.

Waar vindt u gegevenscaches?

U kunt deze informatie vinden in de kolom Records van Physical Query Plans en in de kolom Server Timings van DAX Studio in de kolom Rijen . U kunt zien hoeveel rijen er worden geproduceerd door de opslagengine en naar de formule-engine worden gestuurd.

Als u bepaalde tests uitvoert in de servertiming, zult u merken dat het aantal rijen een klein beetje kan afwijken. Dit is slechts een richtlijn voor het aantal rijen dat u omhoog trekt.

Het belangrijkste om in gedachten te houden bij gegevenscaches is dat het aantal gematerialiseerde rijen gelijk moet zijn aan het aantal rijen dat nodig is om de uitvoer zo goed mogelijk te benaderen. Als er een groot verschil is in het aantal rijen, betekent dit dat de orderbewerking is uitgeschakeld.

Als het aantal gerealiseerde rijen gelijk is aan het aantal rijen dat nodig is voor de uitvoer, wordt dit Late materialisatie genoemd . Als het aantal gematerialiseerde rijen echter groter is dan het aantal benodigde rijen, wordt dit Early Materialization genoemd . Aangezien dit niet-gecomprimeerde gegevens zijn, moet u ze niet door beide engines laten materialiseren, omdat dit de prestaties van DAX zal vertragen.

Dit is een voorbeeld van een vroege materialisatie:

In het Physical Query Plan ziet u dat er 25 miljoen rijen worden opgehaald in de Records-kolom. De voorbeeldquery heeft echter geen 25 miljoen rijen uitvoer nodig. Dit betekent dat de query te veel rijen heeft opgehaald dan nodig.

Als u naar de servertiming kijkt, ziet u hetzelfde aantal rijen dat wordt opgehaald in de rijenkolom.

In de SE CPU- visuals ziet u een nummer als er parallellen in uw query's zijn. Omdat dit voorbeeld er geen heeft, werd er 0 weergegeven.

Wat is DAX Studio in LuckyTemplates Desktop
DAX-zelfstudie: context en de berekeningsengine
VertiPaq Analyzer in DAX Studio | LuckyTemplates-zelfstudie

Conclusie

Een traag presterende DAX kan betekenen dat uw query onnodige caches ophaalt om uw engines te laten werken. Datacaches zijn verantwoordelijk voor de snelheid en nauwkeurigheid van uw DAX omdat de engines erop werken om antwoorden voor verschillende verzoeken te genereren. Voor snellere DAX-prestaties kunt u dit probleem oplossen door uw datamodel en DAX-maatregelen correct te bouwen.