Gegevenscache: wat het is en hoe het helpt om zoekopdrachten te optimaliseren

In deze tutorial leer je wat een datacache is en waarom het belangrijk is. Een datacache slaat stukjes gegevens op die waardevol kunnen worden voor toekomstig gebruik.

Als u dezelfde informatie nodig heeft bij een toekomstige maatregel of actie, zal de datacache u de informatie geven die u nodig heeft. Het voorkomt dat het systeem dezelfde gegevenssets opnieuw moet ophalen.

In deze zelfstudie doorloopt u acht belangrijke dingen die u moet onthouden bij het omgaan met gegevenscaches in LuckyTemplates:

Inhoudsopgave

• Definitie en doel van een gegevenscache
• Wat is de impact van een gegevenscache op het RAM-geheugen
• Hoe een gegevenscache zoekopdrachten optimaliseert
  • Niet-geoptimaliseerde functies
  • Verminderde herhalingen
• Conclusie

Definitie en doel van een gegevenscache

Een datacache is een tijdelijke tabel die door de opslagengine in het geheugen wordt gemaakt . Deze tijdelijke tabel wordt naar de formule-engine gestuurd, die vervolgens deze informatie herhaalt en verschillende bewerkingen uitvoert na de query.

Alle communicatie tussen de formule-engine en de opslag-engine vindt altijd plaats in de vorm van een datacache. De formule-engine bereidt de queryplannen voor en stuurt vervolgens de instructies naar de opslag-engine. De opslag-engine stuurt het vervolgens terug naar de formule-engine die het resultaat terugstuurt naar de gebruiker.

Aangezien de formule-engine geen directe toegang heeft tot de gegevens die zijn opgeslagen in DirectQuery en VertiPaq, vertrouwt deze op de opslag-engine voor de gegevenscaches.

De gegevenscache die door de opslagengine wordt verzonden, heeft een niet-gecomprimeerd formaat. Dit betekent dat de grootte van de gegevens die zijn opgeslagen in de Vertipaq-tool kan worden verkleind.

Maar wanneer het tijd is om de datacache terug te sturen naar de formule-engine, kan deze niet worden gecomprimeerd omdat de formule-engine niet werkt met gecomprimeerde datasets.

Wat is de impact van een gegevenscache op het RAM-geheugen

Als de opslagengine grote hoeveelheden gegevenscaches verzendt, neemt dit veel ruimte in het RAM-geheugen van de software in beslag. Het gaat ook een aanzienlijke hoeveelheid tijd kosten voor de formule-engine om iteraties uit te voeren en een resultaat te produceren.

Dus wanneer u uw DAX-code schrijft, moet u begrijpen dat deze zo moet worden geschreven dat de rijen in de gegevenscache worden geminimaliseerd.

Het beste scenario is om het aantal rijen dat in de visual wordt weergegeven, af te stemmen op het aantal rijen dat wordt geretourneerd in de gegevenscache.

Meestal is het moeilijk om hetzelfde aantal rijen te retourneren. Als dit gebeurt, moet u uw DAX-code controleren en opsplitsen op een manier die de gegevenscache die door de opslagengine wordt geproduceerd, optimaliseert.

Hoe een gegevenscache zoekopdrachten optimaliseert

Niet-geoptimaliseerde functies

Sommige functies in de DAX-taal zijn niet geoptimaliseerd voor de opslagengine. Laten we, om dit beter te begrijpen, naar een voorbeeld kijken.

In uw code kunt u bijvoorbeeld in plaats van SUMMARIZE de functie gebruiken . De functies SUMMARIZE en GROUPBY voeren dezelfde bewerking uit. Er zijn echter opmerkelijke verschillen afhankelijk van het scenario.

De functie GROUPBY is niet geoptimaliseerd voor de Storage Engine. Als u de GROUPBY-functie gebruikt op een feitentabel met 12 miljoen rijen, produceert deze een gegevenscache met hetzelfde aantal rijen. Dit kan zo groot zijn als 600mb tot 1gb.

Deze grootte kan veel druk uitoefenen op uw RAM. Gebruik dus in plaats van GROUPBY . De functie SUMMARIZE resulteert in een kleinere gegevenscache. Je kunt het koppelen met GROUPBY als een functie op het hoogste niveau.

Verminderde herhalingen

Wanneer u uw DAX-metingen of -query's schrijft, moet u ervoor zorgen dat de code die achter de schermen wordt geproduceerd, geschikt is voor de opslagengine.

U moet uw DAX-code zo schrijven dat er een gegevenscache ontstaat die ook in latere query's kan worden gebruikt. Het voordeel hiervan is dat in plaats van een aparte scan met VertiPaq uit te voeren , de storage-engine controleert of er al een vergelijkbare query is ontvangen.

Als dit waar is, betekent dit dat de datacache beschikbaar is in het geheugen. Dus in plaats van de query opnieuw te scannen, zal VertiPaq deze eenvoudig terugsturen van het cachegeheugen naar de formule-engine.

Als u een CALLBACKDATAID-operator ziet in uw query voor de opslagengine, betekent dit dat die query's niet in de cache kunnen worden opgeslagen. Als een vergelijkbare query naar de opslagengine wordt verzonden, zal deze een herhaling uitvoeren.

VertiPaq zal dus de formule-engine moeten aanroepen om de vraag op te lossen. Dit verhoogt de algehele uitvoeringstijd omdat het cachegeheugen in dit geval niet kan worden gebruikt.

Conclusie

De datacache is je beste vriend in de DAX-taal. Vergeet niet om uw DAX-code zo te schrijven dat de opslagruimte wordt gemaximaliseerd en het aantal iteraties van de VertiPaq-tool wordt verminderd. U kunt de gegevenscache die al door de Storage Engine is geproduceerd, hergebruiken om de uitvoeringstijd van query's te verkorten.