kontakta oss

För att fullt ut förstå OLTP och OLAP, det är nödvändigt att ge lite sammanhang. Under de första dagarna av programvarans existens lagrades data vanligtvis i en enda fil. Men när det började ta itu med större problem, hanteringssystem för relationsdatabaser (DBMS) tog marknaden med storm. Under de följande decennierna var det allas lösningar för datalagring.
Med tillkomsten av webben förändrades allt massivt. Sökmotorer och sociala nätverk modellerar nu data i domäner där relationerna mellan data inte är lätt identifierbara eller ibland inte ens behövs (t.ex. sökmotorer som indexerar dokument).
Ändå används några termer från den gamla världen fortfarande idag, och det är viktigt att titta på dem med ett modernt tillvägagångssätt. Två av dem är, exakt, OLTP och OLAP. Men för ett övergripande sammanhang, låt oss ta en titt på följande bild som visar förhållandet mellan OLTP och OLAP.
Innan vi identifierar de viktigaste skillnaderna mellan OLTP mot OLAP, låt oss först ge ett övergripande sammanhang angående deras relation. Ta en titt på följande bild som visar förhållandet mellan OLTP och OLAP.

Bilden ovan understryker är att OLTP och OLAP är inte konkurrenternas tillvägagångssätt till samma fråga, utan snarare processer som kompletterar varandra. I allmänhet tillhandahåller OLTP-system källdata till datalagren, medan OLAP-system hjälper till att analysera data.
Därefter hittar du en mer djupgående förklaring av var och en av dessa termer, följt av en beskrivning av hur OLTP och OLAP kompletterar varandra.
Termen OLTP hänvisar till Online transaktionsbehandling. Det används ofta för att nämna databaser som lagrar och hanterar relevant data för den dagliga verksamheten i ett system eller företag. Tidigare var denna term vanligtvis kopplad till relationsdatabaser i drift, där huvudfokus var att samla in data från vad som hände i ett givet sammanhang.
Kort sagt: OLTP används för att lagra och hantera data för den dagliga verksamheten.
Eftersom informationen lagras i ett OLTP-datalager ofta var avgörande för verksamheten, gjordes en enorm ansträngning för att säkerställa Atomicitet, Konsekvens, Isolering och Hållbarhet (SYRA) av uppgifterna. Uppgifter som lagras enligt dessa fyra principer är markerade som ACID-kompatibel, och det är här hanteringssystem för relationsdatabaser utmärka sig.
Men att ha en ACID-kompatibel Datastore betyder inte att vi inte behöver göra några ytterligare ansträngningar för att säkerställa att våra data överensstämmer med dessa principer: hur vi behandlar uppgifterna är viktigt. Hur kan vi till exempel garantera att uppgifterna är konsekventa om vi tillåter redundans i vårt datalager?
Om vi lagrar kunders adresser är det viktigt att se till att när klienten flyttar till en annan plats uppdateras adressen överallt. Men att lagra adresser på flera ställen gör det svårt att hålla data i ett konsekvent tillstånd. Det är därför relationsdatabaser ofta är utformade för att matcha 5: e normala formen - ett sätt att designa relationsdata som undviker redundans.
Som sagt tidigare har världen förändrats sedan OLTP-termen definierades, och nuförtiden är det lätt att lagra data på icke-relationella databaser. De flesta av dessa datalager följer endast några av de fyra principerna för ACID. Beroende på användningsfallet är det OK att koppla av på en eller flera av dessa principer i utbyte mot andra fördelar (hastighet, skalbarhet etc.).
Om vi till exempel lagrar ”gillar” i ett inlägg på ett socialt nätverk, är det verkligen viktigt att se till att antalet likes är 100% korrekt? Eller är det OK att visa 995 likes istället för 998 i utbyte mot ett snabbare svar till miljontals användare?
Eftersom OLTP hänvisar till Online Transaction Processing ser vi att termen inte är begränsad till relationsdatabaser eller ens helt kompatibla ACID-databaser. Det hänvisar helt enkelt till hur dessa datalager används. Om vi till exempel använder en dokumentdatalagring (t.ex. MongoDB) för att lagra och bearbeta data från den dagliga driften av en social app (t.ex. för att registrera användare, lagra likes etc.), kan vi säga att det är OLTP.
Termen OLAP hänvisar till Online analytisk bearbetning, och används ofta för att nämna databaser som lagrar och hanterar relevant data för analys och beslutsfattande.
OLAP är starkt kopplat till Business Intelligence (BI), en specialisering av mjukvaruutveckling inriktad på att leverera applikationer för affärsanalys. Med andra ord, målet med BI är att tillåta chefer på högsta nivå att fråga och utforska data utan hjälp av att involvera IT-personal.
Kort sagt: OLAP används för att analysera data och fatta beslut.
Det största framsteget som detta område har medfört var kapaciteten att generera rapporter i farten. Det slutade behovet av att ringa IT-avdelningen för att be om en anpassad rapport, eller för att automatisera genereringen av specifika rapporter. EN BI-system kan nu svara på frågor som utvecklarna inte hade behov av att veta i förväg att frågan skulle ställas.
BI-system möjliggörs genom att organisera data i en form som kallas Hyperkub. Detta formulär utforskar de många dimensionerna av data, och tillåter användare att aggregat eller borra ner data genom att navigera i kubens dimensioner.
Det roliga är att med rätt gränssnitt, Ledningen på högsta nivå kan generera rapporter i fartenutan hjälp av IT.
OLAP-system kan implementeras med hjälp av relationsdatabaser (t.ex. MySQL), och denna teknik kallas ofta ROLAP (Relationell OLAP). Men för det måste vi utforma databasen inte i den femte normala formen utan i 3: e normala formen.
Vi kan leva med överflödiga data när vi analyserar data. Det som verkligen betyder något är förmågan att navigera genom datans dimensioner. Det är här ROLAP lyser, eftersom ett databasschema i den tredje normalformen lämpar sig för aggregeringar och borrningar.
Som sagt tidigare, medan OLTP ger en omedelbar rapport om affärsaktivitet, fokuserar OLAP å andra sidan på att generera dataanalys och insikter från de sammanställda uppgifterna. OLTP och OLAP kompletterar varandra eftersom OLAPs insikter bara är lika bra som den datapipeline som är resultatet av OLTP.
Ta reda på de viktigaste skillnaderna mellan OLTP och OLAP i följande tabell:
När man stöter på termerna OLTP och OLAP för första gången är det lätt att ifrågasätta vilken som är bättre, när man faktiskt borde fråga: Hur kompletterar det ena det andra?
Vi vet nu att:
Det är exakt hur de används i en befintlig verksamhet.

Uppgifterna från den övre delen av ovanstående exempel (HR-databas, CRM, faktureringssystem) behandlas vanligtvis i batch - ofta över natten - via en process som kallas Extrahera, omvandla och ladda (ETL).
ETL är namnet på operationen som samlar in data från flera OLTP-källor och placerar den i ett OLAP-datalager, vilket möjliggör analys över flera system. I den nedre delen av ovanstående figur kan du se att data lagrades och organiserades korrekt i OLAP-kub.
På så sätt kan de personer som utför analysen arbeta med uppdaterad information och fatta snabba beslut utan att störa verksamheten.
Den här artikeln förklarade de viktigaste skillnaderna mellan OLAP vs OLTP och hur de kompletterar varandra.
Varje dag förvärvas nya data; i alla fall, vi måste organisera och analysera samma data för att fatta välgrundade beslut och hämta värdefulla insikter. Därför har en organisation vanligtvis två typer av databehandlingsförmågor: OLTP och OLAP.
Som vi har beskrivit i hela artikeln spelar både OLTP och OLAP en avgörande roll när det gäller data, trots deras olika tillvägagångssätt mot det. Vi hoppas att du har hittat det här inlägget användbart!

Hittade den här artikeln användbar? Du kanske gillar dessa också!

VD @ Imaginary Cloud och medförfattare till boken Product Design Process. Jag gillar mat, vin och Krav Maga (inte nödvändigtvis i denna ordning).
Människor som läste det här inlägget tyckte också att dessa var intressanta: