Hva er kubeoptimalisering i Planning Analytics?

…og hva betyr egentlig omrokkering av dimensjoner for ytelse?

Det finnes allerede mange gode kilder tilgjengelig på nett som forklarer hvordan du kan endre rekkefølgen på dimensjoner eller optimalisere en TM1-kube. Når vi i RAV sertifiserer oss til å bli TM1-utviklere lærer vi at en kube skal bygges med denne dimensjonsrekkefølgen: fra små til store dimensjoner og deretter sortert ut i fra tetthet, altså fra dimensjoner med spredt innhold til tett innhold.

I Architect er det en egen funksjon som kalles «Cube Optimizer». Denne finnes under valget om å endre dimensjonsrekkefølge og du kan se den når du høyreklikker på en kube i Architect. Du kan da velge å la systemet utføre endringen i dimensjonsrekkefølgen for deg ved å huke av for dette valget, eller manuelt gjøre det selv.

I Architect kan vi da se en prosentvis endring i minne, og negativt fortegn betyr at endringen i rekkefølgen av dimensjoner har redusert minnebruken med gitt prosent. Dette har jeg markert i rødt nedenfor. Du kan da se original rekkefølge, nåværende rekkefølge og den nye rekkefølgen basert på hva TM1 mener er mest hensiktsmessig for minne.

 
kubeoptimalisering.jpg
 

Tradisjonelt sett var det reduksjon i minne som det ble fokusert på ved kubeoptimalisering, men i senere tid har det dukket opp flere optimale rekkefølger for å få best mulig ytelse for kuben. Disse fire faktorene er identifisert som viktige for kubens ytelse:

  1. Optimal rekkefølge av dimensjoner for lagring på disk

  2. Optimal rekkefølge av dimensjoner for minnereduksjon

  3. Optimal rekkefølge av dimensjoner for å hente inn en visning

  4. Optimal rekkefølge av dimensjoner for å skrive tilbake til server

Ved å kun fokusere på en av disse fire faktorene, vet vi lite om vi faktisk optimaliserer kuben riktig for vårt bruk. Det finnes dermed ingen best-practice på dimensjonsrekkefølge for alle kuber. Hvilken dimensjonsrekkefølge du velger avhenger av hvilken faktor det er viktigst å optimalisere for den enkelte kuben. Har du en inputkube eller en kube som inneholder data som kun er for oppslag, bør disse to kubene optimaliseres med litt ulik fremgangsmåte. I RAV anser vi faktor nummer tre og fire som de mest relevante ved kubeoptimalisering, da mulighetene for utvidelse av minne og lagring er langt bedre enn de var «back in the day». Det kan også være årsaken til at Performance Modeler ikke har adoptert funksjonen for kubeoptimalisering for minne fra Architect.

Et tenkt eksempel kan være en kube som består av følgende dimensjoner:

  • Versjoner (Faktiske tall, Budsjett og Prognose)

  • Måneder (12 elementer)

  • Avdelinger (50 elementer)

  • Prosjekter (1000 elementer)

  • Nøkkeltall (5 elementer)

Når denne kuben eksempelvis skal optimaliseres må administrator identifisere hvilke dimensjoner som mest sannsynlig vil ligge i kontekst eller eksempelvis i et "WHERE-ledd" for en MDX setning. For best mulig ytelse bør de dimensjonene være først eller nær toppen i dimensjonsrekkefølgen.

I vårt eksempel vil et utvalg basert på faktiske tall i versjoner redusere antall celler som skal spørres på til maksimalt 33,3% av det totale kubevolumet, forutsatt at disse tre elementene har likt antall utfylte celler på laveste nivå. Hvis måned settes lik januar er antall celler som det skal spørres på mindre enn 8,5% av kuben og hvis det i tillegg velges et enkelt prosjekt tilsvarer det kun 0,1% av kubens totale volum.

For å forenkle hvorfor dimensjonsrekkefølgen spiller en rolle for ytelsen så kan vi si det på denne måten: Færre celler å søke i og oppsummere tilsvarer mindre CPU kraft som igjen tilsvarer kortere svartider.

De samme prinsippene gjelder ved kubeoptimalisering for å skrive data inn til kilden, altså å minimere antall celler eller kubevolum. Den gylne regelen for kubeoptimalisering for datainput er altså å sammenstille dimensjonene basert på andelen de representerer av datainput. Fokuset ligger derfor på hvor datainput skal utføres. Eksempelvis dersom input gjøres i faktiske tall i versjonsdimensjonen, så gjøres det endring i 33,3% av kubens totale volum, men dersom input gjøres på en avdeling, vil størrelsen på hver input da være 1/50 altså 2% av kubens totale volum, som tilsvarer mindre mengdeendringer per transaksjon som igjen vil gi raskere responstid.

Ved kubeoptimalisering ønsker vi i RAV at du tenker på den potensielle konsekvensen dimensjon- rekkefølgen har for ytelsen i din planleggingsløsning. Vår høyeste prioritet er at brukerne skal oppleve gode responstider og god funksjonalitet som løfter planleggingsprosessen. Dette er vesentlige faktorer som vi vurderer, når vi i designfasen planlegger hvordan kubene skal se ut i de planleggingsløsningene vi bygger- men også når vi ser på ytelse for eksisterende løsninger hos våre kunder.

Er du interessert i å lære mer om kubeoptimalisering eller ønsker hjelp med problemstillingen? Ta kontakt for en uforpliktet prat med en av våre konsulenter.

 
aarstad_jannicke_DSC4164_cropped_720px.jpg

OM FORFATTEREN

Jannicke Aarstad
Seniorkonsulent

 

RELATERTE ARTIKLER