Storage Engine – Zijn rol bij het optimaliseren van DAX-querys in LuckyTemplates

In deze zelfstudie gaan we kijken naar de tweede engine binnen analyseservices: de opslagengine.

We hebben de engine op het hoogste niveau, de formule-engine , besproken in een eerdere zelfstudie. Wanneer gebruikers begrijpen hoe beide engines werken, is het eenvoudiger om de prestaties van uw DAX-query's te optimaliseren en te verbeteren.

Het belangrijkste doel van de storage-engine is om rechtstreeks met de database te werken.

De formule-engine heeft geen directe toegang tot de database, dus deze gaat hiervoor normaal gesproken via de opslag-engine.

Er zijn twee soorten storage-engine: importmodus en DirectQuery . U kunt beide typen in hetzelfde gegevensmodel mixen en matchen om een ​​samengesteld model te maken.

Inhoudsopgave

• Werken met de importmodus in de Storage Engine
• Werken met DirectQuery in de Storage Engine
• Werken met samengestelde modellen
• Andere kritieke punten over de Storage Engine
• Werken aan gecompliceerde vragen
• Conclusie

Werken met de importmodus in de Storage Engine

Laten we het eerst hebben over de importmodus. Dit is ook beter bekend als Vertipaq, maar wordt ook wel xVelocity of In Memory Columnar Database genoemd.

Er zijn vier cruciale dingen die u moet begrijpen over hoe de importmodus werkt.

Eerst maakt Vertipaq een kopie van de gegevens rechtstreeks uit de gegevensbron en slaat deze in gecomprimeerd formaat op in het RAM .

Ten tweede zijn de gegevens die in de importmodus worden verwerkt, gebaseerd op de laatste verversingsbewerking . Dit betekent dat als u uw gegevens vorige week voor het laatst heeft vernieuwd, de gegevens waarmee u te maken heeft nog steeds dezelfde gegevens zijn als vorige week. Dit is vooral belangrijk als u een samengestelde opstelling gebruikt waarbij de ene tabel zich in de importmodus bevindt en de andere tabel in de DirectQuery-modus.

Stel dat u de tabel Producten, die vorige week is vernieuwd, in de importmodus heeft. Wat de Sales-tabel betreft, u hebt besloten om deze via DirectQuery te gebruiken vanwege de grootte ervan. Laten we er ook van uitgaan dat u uw rapport maakt op basis van beide tabellen waarin u de kolom Merk invoert en een Total Sales-meting maakt over dezelfde Sales-tabel. U wilt ook het verkoopbedrag visualiseren op basis van het merk.

U moet eerst de gegevens uit de importmodus vernieuwen, omdat u mogelijk verse en bijgewerkte gegevens van DirectQuery en verouderde gegevens van Vertipaq krijgt. Dit laat een paar lege rijen achter op uw matrix en uw visualisatie.

Het volgende dat u moet weten over Vertipaq is dat alleen basisbewerkingen zoals , , , of native beschikbaar zijn . Dit betekent dat als er andere, meer gecompliceerde bewerkingen in het queryplan zijn opgenomen, de opslagengine de formule-engine zou moeten aanroepen om dit deel van de code op te lossen.

Ten slotte is de storage-engine een zeer geoptimaliseerde database vanwege de kolomstructuur van Vertipaq . Dit betekent dat alle gegevens kolom voor kolom worden opgeslagen en niet rij voor rij. Vanwege deze structuur is Vertipaq altijd sneller dan een DirectQuery-verbinding, zelfs als u indexen maakt in uw relationele gegevensmodel.

Werken met DirectQuery in de Storage Engine

De volgende optie die we hebben binnen de LuckyTemplates-analyseservices is DirectQuery. Als u de DirectQuery-verbinding gebruikt, fungeren de analyseservices alleen als doorvoer voor de query's die door de formule-engine worden verzonden.

Stel dat u een query schrijft. De formule-engine genereert een queryplan. Vervolgens wordt de query doorgestuurd naar de opslagengine, die al is vertaald in de moedertaal van de database. Meestal komen deze vragen in SQL.

Als de query gebruikmaakt van DirectQuery, verwacht dan dat deze altijd up-to-date is. U hoeft zich geen zorgen te maken over wanneer u de gegevens voor het laatst heeft vernieuwd.

Het proces van het optimaliseren van de DAX-code en het gegevensmodel hangt ook af van hoe de relationele database is gemaakt. Als u indexen in uw kolommen heeft, worden uw zoekopdrachten altijd geoptimaliseerd. Maar als uw database niet is geoptimaliseerd voor het maken van rapporten met behulp van analyseservices of LuckyTemplates, dan kunt u enkele prestatie-uitdagingen tegenkomen. Wees dus opzettelijk bij het bouwen van uw databases voor rapportontwikkeling.

Werken met samengestelde modellen

De derde optie is om een ​​samengesteld model te maken, zodat u één tabel in importmodus kunt hebben en een andere tabel in DirectQuery.

Wanneer u twee tabellen uit verschillende bronnen gebruikt, stuurt de formule-engine een verzoek naar Vertipaq en een ander verzoek naar de DirectQuery-gegevensbron. In beide gevallen halen analyseservices ook de datacache op van zowel Vertipaq als DirectQuery. De formule-engine gebruikt dan JOIN, of een iteratie op beide gegevenscaches voordat de resultaten aan de eindgebruiker worden verstrekt.

Stel dat u in uw rapport probeert het verkoopbedrag per merk van het product te visualiseren. De formule-engine stuurt een verzoek naar Vertipaq, waar het het product, het merk en de productsleutel ophaalt. Vervolgens probeert het vanuit DirectQuery de verkoop, nettoprijs, verkoophoeveelheid en verkoopproductcode op te halen.

Zodra het de twee datacaches heeft op basis van de productcode, zal het de twee datacaches samenvoegen en het totale verkoopbedrag berekenen. Vervolgens presenteert het de resultaten aan de eindgebruiker.

Andere kritieke punten over de Storage Engine

Nu we de verschillende typen hebben behandeld, zijn er nog enkele andere kritieke factoren die u moet weten over de opslagengine om u te helpen uw DAX-query's te optimaliseren.

Zoals ik eerder heb vermeld, levert de opslag-engine de gegevenscache terug naar de formule-engine in de vorm van een niet-gecomprimeerde gegevenscache. Wanneer u zich in de importmodus bevindt, wordt het verzoek dat tijdens het proces naar Vertipaq wordt teruggestuurd, uitgevoerd in een xmSQL-taal.

De xmSQL-taal lijkt enigszins op SQL, maar is niet helemaal hetzelfde. We gaan het in detail hebben over xmSWL als we het hebben over queryplannen in een andere zelfstudie.

Het is ook belangrijk om te onthouden dat de opslagengine alle kernen gebruikt die beschikbaar zijn in uw CPU. De mogelijkheid om meerdere cores te gebruiken is handig als u meerdere segmenten binnen uw datamodel heeft.

Stel dat u een tabel in LuckyTemplates heeft met 12 miljoen rijen. Deze tabel wordt vervolgens verdeeld in 12 segmenten omdat in zowel Power Pivot als LuckyTemplates elk segment 1 miljoen rijen past. Dit in tegenstelling tot analyseservices in het algemeen, waar één segment plaats biedt aan 8 miljoen rijen.

Dus als ik zes cores in mijn CPU heb, zullen alle zes cores de eerste zes van de 12 segmenten tegelijkertijd scannen. Als ze klaar zijn, gaan ze verder met de volgende zes segmenten.

Maar als ik werk met analyseservices waarbij het standaardsegment 8 miljoen rijen bevat, worden slechts twee van mijn zes kernen gebruikt: het ene segment verwerkt 8 miljoen rijen en het andere 4 miljoen.

Werken aan gecompliceerde vragen

Eerder heb ik vermeld dat de importmodus alleen basisbewerkingen zoals MIN, MAX, SUM, COUNT en GROUPBY ondersteunt. Dus wat gebeurt er als u aan ingewikkeldere vragen werkt?

Stel dat u besluit een IF-instructie in de rijcontext te gebruiken, of een geneste iteratie zoals SUMX over de tabellen Producten en Verkoop.

In dit geval kan de opslagengine de query niet zelf oplossen. Het zal dan de formule-engine aanroepen, die zal beginnen met het rij voor rij oplossen van de complexe berekening in de opslag-engine. Sommigen denken misschien dat dit een gunstig scenario is, waarbij beide motoren samenwerken, maar dit is verre van waar.

Zie je, wanneer dit gebeurt, kan de datacache die door de opslag-engine wordt geproduceerd, niet in de cache worden geplaatst voor het geval er een callbackdataID in die specifieke query staat. Dus als u de visual vernieuwt, moet dezelfde berekening worden uitgevoerd door zowel de formule-engine als de opslag-engine, ook al heeft u zojuist dezelfde query een paar seconden geleden uitgevoerd. Dit zal leiden tot prestatievertragingen en een slechte gebruikerservaring.

Houd er ook rekening mee dat de opslagengine niet weet of query's zijn uitgevoerd met DAX of MDX. Zoals we eerder vermeldden, is het de taak van de formule-engine om de query's in de juiste taal om te zetten voordat het queryplan wordt doorgegeven.

Ten slotte stuurt de formule-engine query's één voor één naar de opslag-engine. Dit betekent dat het hebben van meerdere segmenten echt beter is, zodat de totale scantijd binnen Vertipaq kan worden verkort, waarbij meerdere segmenten tegelijkertijd worden gescand.

DAX voor LuckyTemplates: optimaliseren met behulp van formule-engines in DAX Studio
Technieken en lessen voor het optimaliseren van DAX-query's
Queryprestaties en DAX Studio-instellingen

Conclusie

Als u de ins en outs van de opslagengine begrijpt, kunt u uw DAX-query's echt optimaliseren, vooral als u DAX Studio gebruikt. Als u ook de zelfstudie hebt doorlopen waarin de formule-engine wordt uitgelegd, kunt u betere beslissingen nemen over het maken van beter presterende query's.

Hoewel de formule-engine als motor op het hoogste niveau dient, lijdt het geen twijfel dat hij niet zo goed kan presteren als hij zou kunnen als we niet beide motoren maximaliseren.

Al het beste,