OLTP en OLAP

Wat zijn OLTP en OLAP?

OLTP (Online Transaction Processing) is de verzamelnaam voor systemen die de dagelijkse werking van je bedrijf verwerken. Elke bestelling in je webshop, elke factuur in je ERP, elke voorraadbeweging is een transactie: een kleine schrijfactie die meteen en foutloos in de database moet belanden.

OLAP (Online Analytical Processing) is de verzamelnaam voor systemen waarmee je diezelfde gegevens analyseert. Niet 'schrijf deze ene bestelling weg', maar 'toon de omzet per maand per productgroep over de voorbije drie jaar'. Een andere vraag, dus ook een andere machine.

Je kan het vergelijken met een kassa en een boekhouder. De kassa registreert elke verkoop op het moment zelf, snel en correct. De boekhouder legt achteraf alle tickets naast elkaar en vertelt je hoe het kwartaal ging. Je wil niet dat de boekhouder aan de kassa staat te rekenen terwijl klanten aanschuiven.

OLTP en OLAP zijn labels voor het soort werklast, geen software die je koopt. Je komt de begrippen tegen bij databases, data warehouses en BI-tools, en zowat elke data-architectuur is rond dit onderscheid gebouwd.

De vier grote verschillen tussen OLTP en OLAP

Het onderscheid komt telkens neer op dezelfde vier dimensies.

Doel

Een OLTP-systeem houdt je bedrijf draaiend. Het moet een bestelling correct wegschrijven, de voorraad bijwerken en de betaling registreren, en dat als één geheel: mislukt één stap, dan wordt alles teruggedraaid. Databases noemen dat ACID-garanties.

Een OLAP-systeem helpt je datzelfde bedrijf te begrijpen. Het beantwoordt vragen over trends en evoluties, en mag daar seconden over doen zonder dat iemand aan een kassa staat te wachten.

Querypatroon

OLTP verwerkt heel veel kleine lees- en schrijfacties, elk in milliseconden. Een webshop die honderd bestellingen per minuut binnenkrijgt, doet honderd keer per minuut een minieme update.

OLAP doet het omgekeerde: weinig queries, maar elke query leest miljoenen rijen om ze samen te vatten tot een handvol cijfers. Zo'n query duurt seconden tot minuten en schrijft zelden iets weg.

Datamodel

OLTP-databases zijn genormaliseerd: elk gegeven staat er precies één keer. Klanten in één tabel, orders in een andere, orderlijnen in een derde. Dat maakt schrijven veilig en goedkoop, want een adreswijziging is één update op één plek.

OLAP-omgevingen zijn dimensioneel gemodelleerd, meestal als ster-schema: een brede feitentabel met cijfers, omringd door dimensietabellen met context. Dat maakt lezen eenvoudig en snel, ten koste van wat dubbele opslag.

Historiek

Een OLTP-systeem toont de actuele toestand. Verhuist een klant, dan overschrijft het nieuwe adres het oude. Oude transacties worden bovendien vaak gearchiveerd of verwijderd om het systeem snel te houden.

Een OLAP-omgeving bewaart de geschiedenis bewust. Je wil net kunnen zien wat de omzet per regio was toen die klant nog in Hasselt zat, en hoe die evolueerde na de verhuis.

Rijopslag versus kolomopslag

Ook fysiek, op de schijf, zetten beide systemen hun data anders neer.

Neem een ordertabel met de kolommen datum, klant, product en bedrag. Een OLTP-database gebruikt rijopslag: alle velden van één bestelling staan naast elkaar. Eén bestelling toevoegen of opzoeken is dan één plek op de schijf, en dat is exact wat een transactioneel systeem de hele dag doet.

Analytische systemen gebruiken kolomopslag: alle waarden van één kolom staan naast elkaar. Wil je de som van drie jaar bedragen, dan leest het systeem enkel de kolom bedrag en laat het de rest van de tabel links liggen. Omdat gelijkaardige waarden naast elkaar staan, comprimeert kolomopslag ook sterk. Microsoft claimt voor zijn columnstore-indexen tot tien keer snellere analytische queries dan klassieke rijopslag, en compressie tot een tiende van de oorspronkelijke datagrootte.

De keerzijde: één rij bijwerken is in kolomopslag omslachtig, want die ene bestelling ligt verspreid over al die aparte kolommen. Vandaar de taakverdeling: rijopslag voor OLTP, kolomopslag voor OLAP.

Hoe stroomt data van OLTP naar OLAP?

De data voor je analyses ontstaat in je operationele systemen. Een ETL- of ELT-pijplijn kopieert ze vandaar naar een data warehouse of lakehouse: ophalen uit ERP, CRM en webshop, opschonen, samenvoegen en historiek opbouwen.

Klassiek draait die pijplijn 's nachts in batch. Wie snellere cijfers wil, gebruikt change data capture: de pijplijn leest dan continu de wijzigingen uit de brondatabase in plaats van elke nacht alles opnieuw op te halen.

HTAP en mirroring

De scheidingslijn is minder absoluut dan ze ooit was. Sinds SQL Server 2016 kan je een columnstore-index bovenop een transactionele tabel leggen en analytische queries op hetzelfde platform draaien. Microsoft noemt dat hybrid transactional and analytical processing, kortweg HTAP.

Microsoft Fabric gaat een stap verder met mirroring: het repliceert operationele databases zoals SQL Server, Azure SQL, PostgreSQL, Oracle of Snowflake bijna realtime naar OneLake, in een formaat dat klaarstaat voor analyse. Je rapporteert dan op een verse kopie, zonder zelf een pijplijn te bouwen en zonder je bronsysteem te belasten.

Handig, maar eigenlijk bevestigt mirroring de tweedeling: ook hier ontstaat een aparte analytische kopie. De queries draaien nog altijd niet op je operationele database, alleen het kopieerwerk is onzichtbaar geworden.

Waar moet je op letten bij OLTP en OLAP

Rapporteren rechtstreeks op je ERP of webshop
De klassieke instapfout. Het begint met één verkooprapport rechtstreeks op de productiedatabase, tot dat rapport groeit en de kassa of webshop merkbaar trager maakt: aggregatiequeries over miljoenen rijen en transacties vechten om dezelfde databaseresources. Daarbovenop is het genormaliseerde model onhandig voor analyse (joins over tientallen tabellen voor één simpele vraag) en ontbreekt de historiek die je voor trendanalyse nodig hebt.

Een replica of mirror kan een eerste stap zijn
Heb je één bronsysteem, een beperkt datavolume en vooral vragen over recente data, dan volstaat een leesreplica of een Fabric-mirror vaak. Je haalt de rapporteringslast weg van het bronsysteem zonder een volledig warehouse op te zetten. Wat je er niet mee krijgt: de combinatie van meerdere bronnen, opgebouwde historiek en eenduidige definities. Daarvoor blijft een warehouse- of lakehouse-laag de standaard.

Niet elke vraag is een analysevraag
'Welke bestellingen staan vandaag nog open?' hoort bij je operationele systeem, dat daar prima op antwoordt. Duw zo'n vraag niet naar een warehouse dat pas 's nachts ververst, want dan kijk je naar cijfers van gisteren.

FAQ over OLTP en OLAP

1. Zijn OLTP en OLAP producten die ik moet kopen?
Nee, het zijn benamingen voor het soort werk dat een systeem doet. Eén databaseproduct kan beide werklasten aan, maar in de praktijk kies je per rol een omgeving die ervoor gebouwd is: een transactionele database onder je applicaties, een warehouse of lakehouse voor je analyses.

2. Kan ik Power BI rechtstreeks op mijn operationele database aansluiten?
Technisch wel, en voor een klein bedrijf met een handvol rapporten werkt dat een tijd. Zodra rapporten zwaarder worden of gebruikers ze de hele dag openen, belast je je bronsysteem en botst je op de grenzen van het genormaliseerde model. Een import naar een apart model of een replica is de eerste verbetering, een warehouse de structurele.

3. Hoe actueel is de data in een OLAP-omgeving?
Zo actueel als je pijplijn ze maakt. Een nachtelijke batch geeft cijfers tot en met gisteren, wat voor de meeste managementrapportering ruim volstaat. Met change data capture of mirroring zit je op minuten of minder na de bron.

4. Is een OLAP-systeem hetzelfde als een data warehouse?
Een data warehouse is de bekendste vorm van OLAP, maar niet de enige. Ook een lakehouse met een SQL-laag, een semantisch model in Power BI of een klassieke kubus zijn OLAP-omgevingen: allemaal gebouwd om veel te lezen en weinig te schrijven.