For fuldt ud at forstå OLTP og OLAP, det er nødvendigt at give lidt kontekst. I de tidlige dage af softwareeksistens blev data typisk gemt i en enkelt fil. Men da det begyndte at løse større problemer, relationelle databasestyringssystemer (DBMS) tog markedet med storm. Gennem de følgende årtier var det alles løsninger til datalagring.
Med fremkomsten af internettet ændrede alt sig massivt. Søgemaskiner og sociale netværk modellerer nu data på domæner, hvor forholdet mellem data ikke er let identificerbart eller undertiden ikke engang nødvendigt (f.eks. søgemaskiner, der indekserer dokumenter).
Ikke desto mindre bruges nogle få udtryk fra den gamle verden stadig i dag, og det er vigtigt at se på dem med en moderne tilgang. To af dem er netop OLTP og OLAP. Men for en overordnet kontekst, lad os se på følgende billede, der viser forholdet mellem OLTP og OLAP.
Før vi identificerer de vigtigste forskelle mellem OLTP k OLAP, lad os først give en overordnet kontekst vedrørende deres forhold. Se på følgende billede, der viser forholdet mellem OLTP og OLAP.
Billedet ovenfor understreger, at OLTP og OLAP er ikke konkurrenters tilgange til det samme problem, men snarere processer, der supplerer hinanden. Generelt leverer OLTP-systemer kildedataene til datavarehusene, mens OLAP-systemer hjælper med at analysere dataene.
Dernæst finder du en mere dybtgående forklaring af hvert af disse udtryk efterfulgt af en beskrivelse af, hvordan OLTP og OLAP supplerer hinanden.
Udtrykket OLTP henviser til Online transaktionsbehandling. Det bruges ofte til at nævne databaser, der gemmer og administrerer relevante data til den daglige drift af et system eller en virksomhed. Tidligere var dette udtryk normalt knyttet til relationelle databaser i drift, hvor hovedfokus var at indsamle data fra, hvad der skete i en given kontekst.
Kort sagt: OLTP bruges til at gemme og administrere data til den daglige drift.
Da oplysningerne gemmes på et OLTP-datalager ofte var kritisk for virksomheden, blev der lagt en stor indsats for at sikre, at Atomicitet, Konsistens, Isolering og Holdbarhed (SYRE) af dataene. Data, der lagres i henhold til disse fire principper, er markeret som ACID-kompatibel, og det er her relationelle databasestyringssystemer udmærke sig.
Men at have en ACID-kompatibel Datastore betyder ikke, at vi ikke behøver at gøre nogen yderligere indsats for at sikre, at vores data overholder disse principper: måden, hvorpå vi behandler dataene, betyder noget. Hvordan kan vi for eksempel garantere, at data er konsistente, hvis vi tillader redundans i vores datalager?
Hvis vi gemmer kunders adresser, er det vigtigt at sikre, at når klienten flytter til et andet sted, opdateres adressen overalt. Men lagring af adresser flere steder gør det svært at holde dataene i en ensartet tilstand. Dette er grunden til, at relationelle databaser ofte er designet til at matche 5. normale form - en måde at designe relationelle data på, der undgår redundans.
Som sagt tidligere har verden ændret sig siden OLTP-udtrykket blev defineret, og i dag er det let at gemme data på ikke-relationelle databaser. De fleste af disse datalagre overholder kun nogle af de fire principper i ACID. Afhængigt af brugssagen er det OK at slappe af på et eller flere af disse principper i bytte for andre fordele (hastighed, skalerbarhed osv.).
For eksempel, hvis vi gemmer „likes“ i et indlæg på et socialt netværk, er det virkelig vigtigt at sikre, at antallet af likes er 100% nøjagtigt? Eller er det OK at vise 995 likes i stedet for 998 i bytte for et hurtigere svar til millioner af brugere?
Da OLTP henviser til online transaktionsbehandling, ser vi, at udtrykket ikke er begrænset til relationelle databaser eller endda fuldt kompatible ACID-databaser. Det henviser simpelthen til hvordan disse datalagre bruges. Hvis vi for eksempel bruger et dokumentdatalager (f.eks. MongoDB) for at gemme og behandle data fra den daglige drift af en social app (f.eks. for at registrere brugere, gemme likes osv.), er vi OK til at sige, at det er OLTP.
Udtrykket OLAP henviser til Online analytisk behandling, og bruges ofte til at nævne databaser, der gemmer og administrerer relevante data til analyse og beslutningstagning.
OLAP er stærkt forbundet med Business Intelligence (BI), en specialisering af softwareudvikling målrettet mod levering af applikationer til forretningsanalyse. Formålet med BI er med andre ord at give ledere på øverste niveau mulighed for at forespørge og udforske data uden hjælp fra at involvere it-medarbejdere.
Kort sagt: OLAP bruges til at analysere data og træffe beslutninger.
Det største fremskridt, som dette område har medført, var kapaciteten til at generere rapporter på farten. Det sluttede behovet for at ringe til it-afdelingen at bede om en brugerdefineret rapport eller automatisere genereringen af specifikke rapporter. EN BI-system kan nu besvare spørgsmål, som udviklerne ikke havde behov for at vide på forhånd, at spørgsmålet skulle stilles.
BI-systemer muliggøres ved at organisere dataene i en form kaldet Hyperkube. Denne formular udforsker de mange dimensioner af dataene, og giver brugerne mulighed for at aggregat eller bore ned data ved at navigere i terningens dimensioner.
Det sjove er, at med den rigtige grænseflade, topledelsen kan generere rapporter på fartenUden hjælp fra IT.
OLAP-systemer kan implementeres ved hjælp af relationelle databaser (f.eks. MySQL), og denne teknik navngives ofte ROLAP (Relationel OLAP). Men til det er vi nødt til at designe databasen ikke i den 5. normale form, men i 3. normale form.
Vi kan leve med overflødige data, når vi analyserer data. Det, der virkelig betyder noget, er evnen til at navigere gennem dimensionerne af dataene. Det er her ROLAP skinner, da et databaseskema i den 3. normale form er velegnet til aggregeringer og uddybninger.
Som sagt før, mens OLTP giver en øjeblikkelig rapport om forretningsaktivitet, fokuserer OLAP på den anden side på at generere dataanalyse og indsigt fra de kompilerede data. OLTP og OLAP supplerer hinanden, fordi OLAP's indsigt kun er lige så god som den datapipeline, der er resultatet af OLTP.
Find ud af de vigtigste forskelle mellem OLTP og OLAP i følgende tabel:
Når man møder udtrykkene OLTP og OLAP for første gang, er det let at stille spørgsmålstegn ved, hvilken der er bedre, når man faktisk skal spørge: Hvordan supplerer den ene den anden?
Vi ved nu, at:
Det er præcis, hvordan de bruges i en eksisterende virksomhed.
Dataene fra den øverste del af ovenstående eksempel (HR-database, CRM, faktureringssystem) behandles normalt i batch - ofte natten over - via en proces kaldet Uddrag, transformér og indlæs (ETL).
ETL er navnet på den operation, der indsamler data fra flere OLTP-kilder og placerer dem i et OLAP-datalager, hvilket tillader analyse på tværs af systemer. I den nederste del af ovenstående figur kan du se, at dataene blev korrekt gemt og organiseret i OLAP-terning.
På den måde kan de personer, der udfører analysen, arbejde med opdaterede oplysninger og træffe rettidige beslutninger uden at forstyrre driften.
Denne artikel forklarede de vigtigste forskelle mellem OLAP vs OLTP, og hvordan de supplerer hinanden.
Hver dag indsamles nye data; men vi er nødt til at organisere og analysere de samme data for at træffe informerede beslutninger og hente værdifuld indsigt. Derfor har en organisation normalt to typer databehandlingsevner: OLTP og OLAP.
Som vi har beskrevet i hele artiklen, spiller både OLTP og OLAP en afgørende rolle med hensyn til data, på trods af deres forskellige tilgange til det. Vi håber, du har fundet dette indlæg nyttigt!
Fandt du denne artikel nyttig? Du kan måske også lide disse!
CEO @ Imaginary Cloud og medforfatter af bogen Product Design Process. Jeg nyder mad, vin og Krav Maga (ikke nødvendigvis i denne rækkefølge).
People who read this post, also found these interesting:
.webp)
.webp)
.webp)
.webp)
.webp)
.webp)
.webp)
.webp)
