Databuffer i en DAX-beregning

I denne opplæringen lærer du om hva databuffere gjør i en DAX-beregning. Du vil forstå hvordan de fungerer med formelen og lagringsmotorene for å gi svar på spørsmålene dine.

Innholdsfortegnelse

• Hva er datacacher?
• Hva er nøkkelfunksjonene?
• Hvor finner jeg datacacher?
• Konklusjon

Hva er datacacher?

Lagringsmotoren samhandler med formelmotoren i form av en databuffer.

Hvis du husker fra tidligere blogginnlegg om DAX Query Structure, vil du vite at formelmotoren ber om data fra lagringsmotoren. Sistnevnte går deretter til databasen, henter forskjellige typer data, og returnerer den deretter tilbake til formelmotoren i form av en databuffer.

Lagringsmotoren kan gjøre enkel matematikk og aggregering som gjør den raskere. Den tilbyr også parallellitet som kan fylle flere databuffere samtidig. En lagringsmotorspørring kan ta tid å generere et svar. Men hvis du legger sammen alle de forskjellige lagringsmotorspørringene, vil ikke resultatene være de samme fordi den fyller mer enn én databuffer.

Formelmotoren, derimot, fungerer på komplekse søk. Siden det er en enkelt-trådet motor, kan den bare bruke én endelig konsolidert databuffer. Den begynner å jobbe på databufferen når alle forespørsler er fylt av lagringsmotoren.

Hvis formelmotorforespørselen er nøyaktig den samme som den forrige forespørselen, vil hurtigbufferen som tidligere ble returnert, brukes igjen. Lagringsmotoren er smart nok til å returnere den samme databufferen hvis den mottar samme forespørsel. Dette gjør DAXs ytelse raskere siden dataene allerede er bufret.

Når du kjører et mål, er det viktig å kjøre det mot en kald cache; unngå alltid å kjøre søkene dine i den varme hurtigbufferen. En varm cache betyr at lagringsmotorens databuffer allerede er dannet og klar til å returneres.

Hva er nøkkelfunksjonene?

Datacacher er tabeller materialisert i minnet som tar tid og spiser RAM. Husk alltid at materialiseringen skal være så lav som mulig.

En annen nøkkelfunksjon er at disse cachene er ukomprimerte . Når den kommer ut av lagringsmotoren og sendes til formelmotoren, blir databufferen en ukomprimert full tabell i minnet. Denne kjøringen er mye tregere enn en peer-lagringsmotorforespørsel som alt er i minnet og komprimert.

Det er ikke noe problem med å bruke formelmotoren; du trenger bare å få lagringsmotoren til å gjøre jobben så mye som mulig.

Datacacher er også midlertidige. De eksisterer en stund og så er de borte. Selv om de er materialisert i minnet, er de ikke vedvarende, så de vil bli ryddet ut.

Hvor finner jeg datacacher?

Du kan finne denne informasjonen i fysiske spørreplaner-postkolonnen og i DAX Studios servertiminger i rad-kolonnen . Det vil du vise hvor mange rader som produseres av lagringsmotoren og sendes til formelmotoren.

Hvis du kjører visse tester i servertimingene, vil du legge merke til at antallet rader kan være litt redusert. Dette er bare en veiledning for hvor mange rader du trekker opp.

Det viktigste å huske på med databuffere er at antall rader som materialiseres skal være lik antall rader som trengs for utdata så nært som mulig. Hvis det er stor forskjell i antall rader, betyr det at ordreoperasjonen er av.

Hvis mengden materialiserte rader er lik mengden rader som trengs for utdata, kalles det Late Materialization . Imidlertid, hvis antallet materialiserte rader er større enn antallet rader som trengs, kalles det tidlig materialisering . Siden dette er ukomprimerte data, bør du ikke la begge motorene materialisere dem fordi det vil bremse DAXs ytelse.

Dette er et eksempel på en tidlig materialisering:

I den fysiske spørreplanen kan du se 25 millioner rader trekkes opp i postkolonnen. Eksempelspørringen trenger imidlertid ikke 25 millioner rader med utdata. Dette betyr at spørringen trakk for mange rader enn nødvendig.

Hvis du ser på servertimingene, vil du se samme mengde rader som trekkes i rad-kolonnen.

I SE CPU- bildene vil du se et tall hvis det er parallelliteter i søkene dine. Siden dette eksemplet ikke har noen, viste det 0.

Konklusjon

En saktegående DAX kan bety at søket trekker unødvendige cacher for at motorene dine skal fungere. Databuffere er ansvarlige for hastigheten og nøyaktigheten til din DAX fordi motorene jobber med dem for å generere svar for forskjellige forespørsler. For en raskere DAX-ytelse kan du løse dette problemet ved å bygge datamodellen og DAX-målene på riktig måte.