Prestatieprobleem in DAX Studio: CallBackDataID

In deze zelfstudie wordt gesproken over CallBackDataID , wat een prestatieprobleem is in DAX Studio. U leert wat het doet en hoe het de prestaties van uw DAX-query beïnvloedt.

De opslag-engine levert gegevens aan de formule-engine in de vorm van een gegevenscache. Maar wanneer de opslagengine een expressie niet kan evalueren, vraagt ​​en roept deze de formule-engine om hulp met behulp van de CallBackDataID .

Het hebben van een CallBackDataID in uw berekening vertraagt ​​de prestaties van DAX omdat het zowel de opslag- als de formule-engine gebruikt. Het is echter nog steeds beter dan alleen de formule-engine al het werk te laten doen, omdat het nog steeds presteert op gecomprimeerde gegevens en geen materialisatie vereist.

Ook als de formule-engine erbij betrokken is, worden de resultaten niet in de cache opgeslagen. Caches verbeteren de gebruikerservaring bij het uitvoeren van een query of meting in LuckyTemplates.

Inhoudsopgave

• Waar vindt u de CallBackDataID
• Hoe het prestatieprobleem op te lossen
• Conclusie

Waar vindt u de CallBackDataID

CallBackDataID is te vinden in de Server Timings in DAX Studio. Vanwege hun belang worden ze gemarkeerd in de xmSQL-verklaring. Als u uw DAX wilt optimaliseren, is het vinden van de CallBackDataID de beste plek om te beginnen.

Een andere optimalisatietechniek is om waar mogelijk gebruik te maken van de filters in Het gebruik van CALCULATE in de filters is beter dan het gebruik van als een tabel. FILTER is een iterator en wanneer u een tabel filtert, wordt deze herhaald door . De aanwezigheid van deze twee iterators kan uw zoekopdracht vertragen.

Hier zijn twee voorbeeldquery's met en zonder de CallBackDataID .

Dit is een gelokaliseerde meting die de twee bovenstaande query's definieert.

De bovenste meting herhaalt de verkooptabel, vermenigvuldigt de huidige prijs en hoeveelheid en telt deze vervolgens op. De onderste meting controleert of de aankoopdatum groter is dan of gelijk is aan 31 maart 2016. Het hebben van een functie in een meting creëert een CallBackDataID omdat deze geen gebruik maakt van CALCULATE .

Om dit te testen, voert u de query uit met de CallBackDataID . Zorg ervoor dat u de cache wist en de Server Timings en Query Plans inschakelt voordat u het uitvoert.

Als u onderaan op het tabblad Server Timings klikt, kunt u zien dat de eerste scan is gemarkeerd. Dit komt door de aanwezigheid van de CallBackDataID .

U kunt de CallBackDataID ook zien in de xmSQL-instructie. De IF- functie in de meting valt buiten de mogelijkheden van de opslagengine, dus vraagt ​​deze om hulp van de formule-engine.

Hoe het prestatieprobleem op te lossen

Als u de query uitvoert die geen CallBackDataID heeft , kunt u zien dat de scans niet langer zijn gemarkeerd.

Dit komt doordat het CALCULATE- filter naar beneden wordt geduwd naar de opslag-engine. Het heeft geen hulp meer nodig van de formule-engine omdat het op zichzelf kan werken.

Probeer zoveel mogelijk filters te gebruiken in CALCULATE . Het optimaliseert de DAX-prestaties door het meeste werk naar de opslagengine te duwen, waardoor deze sneller wordt.

Storage Engine in LuckyTemplates – VertiPaq-operators en query's
meten in LuckyTemplates: optimalisatietips en -technieken
VertiPaq Analyzer in DAX Studio | LuckyTemplates-zelfstudie

Conclusie

Er kunnen prestatiehits optreden als uw query te complex is voor de opslagengine om te werken. Het brengt onnodige processen zoals de CallBackDataID mee in de berekening en vertraagt ​​je DAX. U kunt dit beperken door filters te gebruiken in CALCULATE .