Storage-engine in LuckyTemplates – VertiPaq-operators en querys

In deze zelfstudie wordt ingegaan op de VertiPaq-operators en query's voor opslagengines in LuckyTemplates. U leert hoe operators achter de berekening werken en hoe de opslagengine u helpt de prestaties van uw DAX-codes te optimaliseren.

Met de VertiPaq-operators en -query's kunt u de uitvoering van elke code volgen, zodat u deze indien nodig kunt verbeteren.

Inhoudsopgave

• VertiPaq-operators
• Storage Engine-query's
• Conclusie

VertiPaq-operators

VertiPaq heeft de mogelijkheid om eenvoudige queries te berekenen. Het heeft logische operators die uw DAX-codes uitvoeren om antwoorden te krijgen.

Dit zijn de logische operatoren van VertiPaq:

• Scannen
• GroupBy
• Filter
• Som
• min
• Max
• Graaf
• DistinctCount
• Gemiddeld
• Stdev.S
• Stdev.P
• Var.S
• Var.P

Dit zijn de logische en fysieke queryplannen die zijn gegenereerd door een voorbeeldquery.

Telkens wanneer een regel _Vertipaq heeft , betekent dit dat de VertiPaq-engine het werk zelf doet. Als u naar het Logical Query Plan kijkt , ziet u dat het de Sum_Vertipaq en Scan_Vertipaq heeft . Deze twee operators scannen en sommeren de FactSales' Quantity om een ​​antwoord te genereren.

In het Physical Query Plan ziet u ook een Sum_Vertipaq die een ProjectionSpool gebruikt . Dit betekent dat een query wordt verzonden naar de opslag-engine en vervolgens wordt teruggestuurd naar de formule-engine in een gegevenscache. U zult ook merken dat het maar één record heeft.

De kolom Records laat zien hoeveel rijen worden gerealiseerd van de opslagengine naar de formule-engine. Het heeft slechts één record nodig om efficiënt te werken. Bij meerdere records duurt het langer voordat de query is voltooid.

Als de opslag-engine een verzoek niet kan uitvoeren, neemt de formule-engine het over. De formule-engine kan alles doen wat u vraagt, maar het is veel langzamer.

Storage Engine-query's

Dit is een inleiding tot de opslagengine-query's en hoe u deze kunt lezen en begrijpen. U kunt deze informatie gebruiken om uw DAX-query te optimaliseren voor betere prestaties. Onthoud altijd dat de gegevenscache die door de opslagengine naar de formule-engine wordt geretourneerd, een niet-gecomprimeerde indeling heeft.

Dit is een voorbeeldquery die zal worden gebruikt.

Als u het uitvoert en het tabblad Physical Query Plan opent, ziet u de ProjectionSpool- operator. U moet begrijpen hoe het op de achtergrond van de berekening werkt om een ​​resultaat te produceren.

Query's van de opslagengine worden uitgedrukt in een pseudo-SQL-taal genaamd xmSQL . Het is geen echte programmeertaal. Het is meer een visuele weergave van wat de motor op de achtergrond doet.

Als u de voorbeeldquery uitvoert in DAX Studio, wordt de xmSQL weergegeven. Het laat zien dat de query de SalesData's Quantity selecteert en optelt uit de Sales Data tabel.

U zult merken dat de tabelnaam in de query verschilt van de xmSQL. De xmSQL gebruikt Sales Data in plaats van FactSales als tabelnaam omdat DAX Fact of DIM niet graag als naam gebruikt.

Voor snellere DAX-prestaties moet u de opslagengine nu zo veel mogelijk laten werken. Het kan eenvoudige wiskunde en aggregaties uitvoeren terwijl het naar de gegevens scant. Aangezien de voorbeeldquery alleen gebruikt , is de berekening uitgevoerd in de opslagengine.

De beste optimalisatietechniek is om de beste set te vinden, zodat de opslagengine het meeste werk doet en de formule-engine gewoon doet wat er nog over is.

VertiPaq Storage Engine in omgeving met meerdere threads
VertiPaq-compressie en opslag in LuckyTemplates
Wat is DAX Studio in LuckyTemplates Desktop

Conclusie

De storage-engine zorgt ervoor dat DAX sneller werkt. Hiermee kunt u het proces achter de hele berekening zien met behulp van het Logical and Physical Query Plan. U kunt volgen welk proces de hele prestatie vertraagt ​​en deze vervolgens optimaliseren.

Als u meer wilt weten over hoe de VertiPaq werkt, gebruik dan deze tutorial en oefen met het optimaliseren van uw DAX-codes.