SP2 – før og efter

Før

I forhold til det arktektoniske perspektiv er der 4 hovedkomponenter i Prophix setuppet. På Analysis Services siden findes 3 optioner;
 

  • Kuben hvor alle data findes i Analysis Services
  • Den relationelle Facttabel der ligger bagved kuben og indeholder al data indtil der køres en ’Update Cube’ proces
  • Writebacktabellen er en speciel relationel tabel der er en del af kubedefinitionen fra Analysis Services’ perspektiv.

På den anden side er Prophix klient applikationen.

Måden data flyder i systemet på er:

Kildedata, der findes i fact-tabellen på et leaf niveau af alle dimensionerne, loades. Når der køres en ’Update Cube’ proces eller kuben processeres i Analysis Services, bliver data flyttet ind i selve kuben så en kopi af data ligger i kuben som indeholder beregnings definitioner, aggregationer, indexes der gør data hurtigst mulig at forespørger imod osv. Grundlæggende flyttes data fra fact-tabellen n til kuben.

Når en bruger eksempelvis går i Ad Hoc Analysis og åbner et dataview bliver en MDX forespørgsel backend sendt afsted mod kuben. Kuben finder det data der er relevant og viser det på skærmen. Hvis brugeren er i Data Entry Mode og skal opdatere 1, 10 eller 20 celler vil de på et tidspunkt trykke ’Save’. Når dette gøres i Prophix vil disse 1, 10 eller 20 værdier de opdaterede blive skrevet ned i Writeback-tabellen. Dette data vil efterfølgende stadig blive vist når der forespørges mod kuben.

Problemet med denne arkitektur er at Analysis Services behandler Writeback tabellen på en speciel måde, der betyder, at når værdier gemmes ned i denne tabel, vil der pålægges hele Analysis Services databasen en eksklusiv lås. Hvis der er flere samtidige brugere der opdaterer data, vil man løbe ind i problemer med låse og dermed også forsinkelser. Specielt når der er tale om en kube med langsomme forespørgsler, da mange komplekse beregninger giver større risiko for at samtidige brugere støder ind i hinanden og skaber låse.

Generelt om kuber og partitioner

Strukturen i Analysis Services er således at en database indeholder en eller flere kuber, der indeholder en eller flere partioner.

Hvis man ser på strukturen i en Prophix AS database indeholder kuberne en Meassuregroup. Under denne findes to partitioner:

  • Default partitionen som er linket til fact-tabellen og tænkes på som selve kuben.
  • Writeback partitionen som er hvor nyligt opdateret data opbevares      

I SP2 generer Prophix en kube med en lidt anden struktur. Den har stadig en defaultpartition på samme måde som i tidligere versioner men nu eksisterer en ny partition der hedder ”ROLAP” efterfulgt af kubenavn. Der vil stadig være en writeback-partition men denne vil aldrig blive anvendt i SP2. Den vil kun eksisterer i kuber der er opgraderet fra tidligere versioner – hvis man opretter en ny kube i SP2 vil den ikke være til stede.

De to partitioner er af to forskellige arter – en MOLAP og en ROLAP:

MOLAP står for Multidimentionel OLAP og betragtes som selve kuben. MOLAP partitionen er den der tager data fra fact-tabellen når kuben processes. Når dette udføres flyttes data ind i MOLAP partitionen og en fysisk kopi af dette data oprettes her. MOLAP partitionen udfører fx aggregeringer, tilføjelse af indexes hvor Analysis Services finder det relevant at forbedre hastighed osv. Grundlæggende er MOLAP partionen når den er linket til en fact-tabel afskåret fra det perspektiv at når man forespørger imod det kommer ingen forespørgsler mod SQL databasen tilbage til fact-tabellen, men al data er opbevaret i denne MOLAP partition.

ROLAP står for Relationel OLAP og er en del af kubestrukturen. Det er dog kun en virtuel struktur der ikke indeholder data. Når kuben processes, flyttes der altså ingen data fra ROLAP tabellen ind i MOLAP partitionen – ROLAP data vil altid findes i ROLAP partitionen som er en separat SQL tabel.

Efter

Efter opgradering til SP2 vil flowet i systemet foregå således:

Kuben processes og data flyttes fra fact-tabellen ind i Prophix kuben der egentlig bare er en MOLAP partition, men kuben virker stadig på samme måde som før opgraderingen. En bruger åbner Ad Hoc Analysis, åbner et data view, sender en forespørgsel imod kuben der returnerer data som efterfølgende vises i Prophix. Brugeren udfører nogle indtastninger og trykker ’Save’ i Ad Hoc Analysis eller en template. Det der sker her er at der skrives data ned i ROLAP partitionen hvilket kun er en SQL tabel. Dette er en tabel som Analysis Services forstår og som er en del af kubedefinitionen. Tabellen har ingen specielle forbehold på samme måde som den gamle writeback tabel havde. På denne måde forekommer der ingen låse fordi strukturer ikke skal opbygges ved opdateringer.

Generelle forbedringer

  1. Brugere kan med det samme se ændringer gemt af andre brugere

Samtidige brugere forårsager ikke låseproblematikker for hinanden.