Materialisatie-ideeën voor gegevenscaches in DAX Studio

In deze zelfstudie wordt ingegaan op materialisatie voor gegevenscaches in DAX Studio. Dit bericht laat zien hoe het uw berekening beïnvloedt terwijl het resultaten genereert met uw zoekopdracht. U leert welke materialisatie beter is om de prestaties van DAX te maximaliseren.

Er zijn twee ideeën over materialisatie: vroege materialisatie en late materialisatie .

Inhoudsopgave

• Vroege materialisatie
• Late materialisatie
• Binnen elke materialisatievraag
• Conclusie

Vroege materialisatie

Vroege materialisatie is wanneer het aantal gerealiseerde rijen groter is dan het aantal rijen dat nodig is voor de uitvoer.

Als uw uitvoer een tabel per kalenderjaar is en u beschikt over vijf jaar aan gegevens, is het niet nodig om veel opgebouwde rijen mee te nemen. De best practice is om het aantal gerealiseerde rijen gelijk te hebben aan het aantal rijen dat nodig is. Dat is echter niet altijd het geval, omdat het afhangt van de complexiteit van uw DAX en data-instellingen.

Onthoud altijd dat gegevens uit kolommen bestaan. Dus wanneer de formule-engine aan een tabel moet werken, worden kolommen weer samengebracht in een tabelindeling, wat de materialisatie is. In een Early Materialization-idee stuurt de opslagengine de gegevenscache naar de formule-engine. De formule-engine werkt vervolgens aan die cache en voert complexe processen uit.

Vroege materialisatie kan worden veroorzaakt door complexe joins of een veel-op-veel-relatie in uw datamodellen. Het kan ook worden veroorzaakt door complexe filters of iterators.

Het is niet verkeerd om complexe maatregelen te hebben; u hoeft ze alleen maar correct in te stellen om zoveel mogelijk gebruik te maken van de storage-engine.

Late materialisatie

Late materialisatie is wanneer het aantal gematerialiseerde rijen gelijk is aan of in de buurt komt van het aantal rijen dat nodig is voor uw uitvoer.

De opslag-engine doet bijna al het werk en laat niets over voor de formule-engine. Dit maakt de hele berekening sneller.

Dit zijn voorbeeldquery's van vroege en late materialisatie:

Voordat u deze query's uitvoert, moet u ervoor zorgen dat u de cache wist. Hierdoor worden uw query's tegen de koude cache uitgevoerd. Als u uw DAX uitvoert zonder de cache te wissen, krijgt u dit resultaat:

De totale uitvoeringstijd is slechts 1861 milliseconden omdat er al een cache werd gebruikt. Wis dus altijd uw cache voordat u uw query's uitvoert.

Als u de query Early Materialization uitvoert, kunt u zien dat de totale tijd die hiervoor nodig was 9485 milliseconden is. Het genereerde één gegevenscache en een uitvoer van één rij, maar retourneerde 25 miljoen rijen.

U hoeft geen 25 miljoen rijen te realiseren om een ​​resultaat van één rij te krijgen, omdat dit tijd kost en de prestaties van DAX vertraagt.

Als u de query Late materialisatie uitvoert, ziet u dat de hele berekening slechts 1340 milliseconden in beslag nam. Het genereerde ook 2 datacaches, die elk 5003 rijen retourneerden.

Als u naar het Physical Query Plan kijkt, ziet u 5000 rijen. Ze hebben niet hetzelfde aantal rijen. Het resultaat van de Server Timings wijkt soms enigszins af van het juiste aantal rijen in het Queryplan.

Dus van het werken aan één datacache met 25 miljoen rijen, heb je nu twee datacaches met 5003 rijen. Daarom levert het werken met Latere materialisatie snellere resultaten op dan met vroege materialisatie.

Binnen elke materialisatievraag

Door alleen naar de query te kijken, kun je al zien dat de Latere Materialisatie sneller is. De query Early Materialization telt de rijen van een samengevatte tabel.

van op de tabel uitvoeren , wat de Late Materialization-query doet.

Als uw query traag is, kijk dan eerst hoeveel rijen er in uw query worden opgehaald en hoeveel er nodig zijn voor de uitvoer. U kunt ook naar het Logical Query Plan gaan en de werkstroom volgen die binnen de berekening plaatsvindt.

Wat is DAX Studio in LuckyTemplates Desktop
DAX-zelfstudie: context en de berekeningsengine
Meten in LuckyTemplates: optimalisatietips en -technieken

Conclusie

Materialisatie vindt plaats wanneer uw query's kolommen of rijen uit uw gegevensmodel halen. Dit proces vindt op natuurlijke wijze plaats wanneer uw engine gegevens uit uw gegevensmodel haalt om resultaten voor uw zoekopdracht te leveren.

Er kunnen echter problemen optreden als uw DAX te veel rijen ophaalt dan nodig is voor het resultaat. Dit probleem kan worden opgelost door uw DAX te vereenvoudigen om specifieke processen uit te voeren.