Storage Engine – dess roll i att optimera DAX-frågor i LuckyTemplates

I den här handledningen ska vi ta en titt på den andra motorn i analystjänster - lagringsmotorn.

Vi diskuterade motorn på toppnivå, den, i en tidigare handledning. När användarna förstår hur båda dessa motorer fungerar är det lättare att optimera och förbättra prestandan för dina DAX-frågor.

Lagringsmotorns huvudsakliga syfte är att arbeta direkt med databasen.

Formelmotorn har inte direkt åtkomst till databasen, så den går normalt genom lagringsmotorn för detta ändamål.

Lagringsmotorn finns i två typer - importläge och DirectQuery . Du kan blanda och matcha båda typerna i samma datamodell för att skapa en sammansatt modell.

Innehållsförteckning

• Arbeta med importläge i lagringsmotorn
• Arbeta med DirectQuery i Storage Engine
• Arbeta med kompositmodeller
• Andra kritiska punkter om lagringsmotorn
• Arbetar med komplicerade frågor
• Slutsats

Arbeta med importläge i lagringsmotorn

Låt oss först prata om importläget. Detta är också mer känt som Vertipaq, men det kallas också xVelocity eller In Memory Columnar Database.

Det finns fyra viktiga saker att förstå om hur importläget fungerar.

Först skapar Vertipaq en kopia av data direkt från datakällan och lagrar den i RAM-minnet i komprimerat format .

För det andra är data som behandlas i importläget baserad på den senaste uppdateringsoperationen . Det betyder att om du senast uppdaterade din data förra veckan, så är den data du har att göra med fortfarande samma data från förra veckan. Detta är särskilt viktigt om du använder en sammansatt konfiguration där en tabell är i importläge och den andra tabellen är i DirectQuery-läge.

Låt oss säga att du har tabellen Produkter, som uppdaterades förra veckan, i importläget. När det gäller försäljningstabellen bestämde du dig för att kursa den genom DirectQuery på grund av dess storlek. Låt oss också anta att du skapar din rapport baserat på båda tabellerna där du tar in kolumnen Varumärke och skapar ett totalförsäljningsmått över samma försäljningstabell. Du vill också visualisera försäljningsbeloppet baserat på varumärket.

Du måste uppdatera data som kommer från importläget först eftersom du kan få färska och uppdaterade data från DirectQuery och inaktuella data från Vertipaq. Detta kommer att lämna några tomma rader på din matris och din visualisering.

Nästa sak du behöver veta om Vertipaq är att endast grundläggande funktioner som , , eller är inbyggt tillgängliga . Detta innebär att om det finns andra mer komplicerade operationer som ingår i frågeplanen, måste lagringsmotorn anropa formelmotorn för att lösa denna del av koden.

Slutligen är lagringsmotorn en mycket optimerad databas på grund av Vertipaqs kolumnstruktur . Detta innebär att all data lagras kolumn för kolumn och inte rad för rad. På grund av denna struktur kommer Vertipaq alltid att vara snabbare än en DirectQuery-anslutning även om du skapar index i din relationsdatamodell.

Arbeta med DirectQuery i Storage Engine

Nästa alternativ som vi har i LuckyTemplates analystjänster är DirectQuery. Om du använder DirectQuery-anslutningen fungerar analystjänsterna endast som en genomgång för de frågor som skickas av formelmotorn.

Så låt oss säga att du skriver en fråga. Formelmotorn genererar en frågeplan. Den kommer sedan att vidarebefordra frågan till lagringsmotorn, som redan är översatt till databasens modersmål. För det mesta kommer dessa frågor i SQL.

Om frågan använder DirectQuery, förvänta dig att den är uppdaterad hela tiden. Du behöver inte oroa dig för när du senast uppdaterade data.

Processen att optimera DAX-koden och datamodellen kommer också att bero på hur relationsdatabasen skapades. Om du har index i dina kolumner kommer dina frågor alltid att vara optimerade. Men om din databas inte är optimerad när det gäller att skapa rapporter med hjälp av analystjänster eller LuckyTemplates, kan du möta några prestandautmaningar. Så var avsiktlig när du gör dina databaser byggda för rapportutveckling.

Arbeta med kompositmodeller

Det tredje alternativet är att skapa en sammansatt modell så att du kan ha en tabell i importläge och en annan tabell i DirectQuery.

När du använder två tabeller från olika källor kommer formelmotorn att skicka en begäran till Vertipaq och en annan begäran till DirectQuery-datakällan. I båda fallen kommer analystjänster också att hämta datacachen från både Vertipaq och DirectQuery. Formelmotorn kommer då att använda JOIN,, eller någon iteration på båda datacacharna innan resultaten ges till slutanvändaren.

Så låt oss säga att du försöker visualisera försäljningsbeloppet efter produktens varumärke i din rapport. Formelmotorn kommer att skicka en förfrågan till Vertipaq, där den kommer att hämta produkten, varumärket och produktnyckeln. Sedan, från DirectQuery, kommer den att försöka hämta försäljning, nettopris, försäljningskvantitet och försäljningsproduktnyckel.

När den har de två datacacharna baserat på produktnyckeln kommer den att slå samman de två datacacharna och beräkna det totala försäljningsbeloppet. Den kommer sedan att presentera resultaten för slutanvändaren.

Andra kritiska punkter om lagringsmotorn

Nu när vi har täckt dess olika typer finns det några andra kritiska faktorer som du behöver veta om lagringsmotorn för att hjälpa dig att optimera dina DAX-frågor.

Som jag har nämnt tidigare, tillhandahåller lagringsmotorn datacache tillbaka till formelmotorn i form av en okomprimerad datacache. När du är i importläge exekveras begäran som skickas tillbaka till Vertipaq i processen i ett xmSQL-språk.

Språket xmSQL påminner något om SQL men är inte helt detsamma. Vi kommer att prata om xmSWL i detalj när vi pratar om frågeplaner i en annan handledning.

Det är också viktigt att komma ihåg att lagringsmotorn använder alla kärnor som finns tillgängliga i din CPU. Möjligheten att använda flera kärnor är fördelaktigt om du har flera segment i din datamodell.

Låt oss säga att du har en tabell i LuckyTemplates med 12 miljoner rader. Denna tabell kommer sedan att delas upp i 12 segment eftersom i både Power Pivot och LuckyTemplates, passar varje segment 1 miljon rader. Detta är till skillnad från analystjänster i allmänhet, där ett segment rymmer 8 miljoner rader.

Så om jag har sex kärnor i min CPU kommer alla sex kärnor att skanna de första sex av de 12 segmenten samtidigt. När de är klara går de vidare till nästa sex segment.

Men om jag arbetar med analystjänster där standardsegmentet innehåller 8 miljoner rader, kommer bara två av mina sex kärnor att användas – ett segment kommer att behandla 8 miljoner rader medan det andra bearbetar 4 miljoner.

Arbetar med komplicerade frågor

Tidigare nämnde jag att importläget endast stöder grundläggande operationer som MIN, MAX, SUM, COUNT och GROUPBY. Så vad händer om du arbetar med mer komplicerade frågor?

Låt oss säga att du bestämmer dig för att använda en IF-sats i radkontexten, eller en kapslad iteration som SUMX över produkt- och försäljningstabellerna.

I det här fallet kommer lagringsmotorn inte att kunna lösa frågan på egen hand. Den kommer sedan att anropa formelmotorn, som kommer att börja lösa den komplexa beräkningen rad för rad inuti lagringsmotorn. Vissa kanske tycker att detta är ett gynnsamt scenario, med båda motorerna som arbetar tillsammans - men detta är långt ifrån sanningen.

Du ser, när detta händer kan datacachen som produceras av lagringsmotorn inte cachelagras om det finns ett callbackdataID i den specifika frågan. Så om du uppdaterar visualiseringen måste samma beräkning göras av både formelmotorn och lagringsmotorn, även om du precis körde samma fråga för några sekunder sedan. Detta kommer att leda till prestandaförseningar och dålig användarupplevelse.

Observera också att lagringsmotorn inte vet om frågor kördes med DAX eller MDX. Som vi nämnde tidigare är det formelmotorns uppgift att konvertera frågorna till rätt språk innan frågeplanen skickas vidare.

Slutligen skickar formelmotorn frågor till lagringsmotorn en efter en. Detta innebär att det verkligen är bättre att ha flera segment så att den totala skanningstiden inom Vertipaq kan minskas, med flera segment som skannas samtidigt.

Slutsats

Att förstå lagringsmotorns ins och outs hjälper verkligen till att optimera dina DAX-frågor, särskilt om du använder DAX Studio. Om du också har gått igenom handledningen som förklarar formelmotorn, kan du fatta bättre beslut om hur du skapar bättre resultat.

Även om formelmotorn fungerar som motor på toppnivå, råder det ingen tvekan om att den inte kan prestera så bra som den kan om vi inte maximerar båda motorerna.

Med vänliga hälsningar,