Geen resultaten gevonden

Uw zoekopdracht heeft geen resultaten opgeleverd.

We raden u aan het volgende te proberen om te vinden wat u zoekt:

  • Controleer de spelling van het trefwoord in uw zoekopdracht.
  • Gebruik synoniemen voor het trefwoord dat u hebt getypt. Probeer bijvoorbeeld “applicatie” in plaats van “software”.
  • Start een nieuwe zoekopdracht.
Contact opnemen Aanmelden bij Oracle Cloud

Wat is OLTP?

Definitie van OLTP

OLTP (online transaction processing) is een soort dataverwerking die bestaat uit het uitvoeren van een aantal transacties die gelijktijdig plaatsvinden, bijvoorbeeld tijdens online bankieren, winkelen, orderinvoer of het versturen van tekstberichten. Deze transacties worden traditioneel aangeduid als economische of financiële transacties en worden vastgelegd en beveiligd, zodat een onderneming op elk gewenst moment toegang heeft tot de informatie voor boekhoud- of rapportagedoeleinden.

In het verleden had OLTP alleen betrekking op echte interacties waarbij iets werd uitgewisseld, zoals producten, informatie, serviceaanvragen enzovoort. Maar de definitie van een transactie in deze context is in de loop der jaren, en vooral sinds de opkomst van het internet, uitgebreid en omvat nu elke vorm van digitale interactie of betrokkenheid met een bedrijf die kan worden geactiveerd van over de hele wereld en via elke sensor die is verbonden met het internet. Het omvat ook elke vorm van interactie of actie, zoals het downloaden van pdf's op een webpagina, het bekijken van een specifieke video, of automatische onderhoudstriggers of opmerkingen op sociale kanalen, waarvan het van essentieel belang is dat een bedrijf die vastlegt om zijn klanten beter van dienst te kunnen zijn.


De primaire definitie van een economische of financiële transactie blijft voor de meeste OLTP-systemen de basis vormen, dus online transactieverwerking heeft meestal betrekking op het invoegen, bijwerken en/of verwijderen van kleine hoeveelheden data in een dataopslag om die transacties te verzamelen, te beheren en te beveiligen. Doorgaans worden in een mobiele, bedrijfs- of webapplicatie alle interacties en transacties met klanten, leveranciers en partners bijgehouden en in de OLTP-database bijgewerkt. Deze transactiedata die in de database worden opgeslagen, zijn van essentieel belang voor bedrijven en worden gebruikt voor rapportagedoeleinden of het analyseren van datagestuurde besluitvorming.

Lees hoe andere bedrijven, zoals Retraced, Archaeological Park of Pompeii, Jasci en Siemens, er in zijn geslaagd om hun workloads voor transactieverwerking op te nemen in de cloud.

Voor bedrijven zijn er twee verschillende systemen voor transactieverwerking: OLTP en OLAP.

OLTP versus OLAP

OLTP en OLAP klinken ongeveer hetzelfde en zijn allebei online dataverwerkingssystemen, maar er is een duidelijk verschil tussen de twee.

Met OLTP kunnen grote aantallen transacties realtime worden uitgevoerd door vele mensen, terwijl met OLAP (online analytical processing) meestal een query wordt uitgevoerd op deze transacties (ook wel records genoemd) in een database voor analytische doeleinden. Met OLAP kunnen bedrijven inzichten afleiden uit hun transactiedata en deze gebruiken om beter onderbouwde beslissingen te nemen.

In de onderstaande tabel worden OLTP- en OLAP-systemen met elkaar vergeleken.

OLTP-systemen

OLAP-systemen

Realtime uitvoering van grote aantallen databasetransacties door een groot aantal personen

Doorgaans opvraging van vele records (soms zelfs alle records) uit een database voor analytische doeleinden

Zeer snelle responstijden nodig

Responstijden die meerdere ordes van grootte langzamer zijn dan die voor OLTP

Regelmatig worden kleine hoeveelheden data gewijzigd; vaak evenwicht tussen lees- en schrijfbewerkingen

Er worden helemaal geen data gewijzigd; workloads zijn meestal leesintensief

Gebruiken geïndexeerde data om de responstijden te verbeteren

Slaan data op in kolommen, voor eenvoudige toegang tot grote aantallen records

Regelmatige of gelijktijdige databasaeback-ups nodig

Veel minder vaak databaseback-ups nodig

Relatief weinig opslagruimte nodig

Doorgaans aanzienlijke vereisten voor opslagruimte, omdat grote hoeveelheden historische data worden opgeslagen

Voeren vaak eenvoudige query's uit met slechts één of enkele records

Voeren complexe query's uit met grote aantallen records

OLTP is dus een online datawijzigingssysteem, terwijl OLAP een online historisch multidimensionaal dataopslagsysteem is dat wordt gebruikt om grote hoeveelheden data op te halen voor analytische doeleinden. Met OLAP worden vaak analyses uitgevoerd op data die zijn vastgelegd in een of meer OLTP-systemen.

Vereisten voor een OLTP-systeem

Voor een OLTP-systeem met transactionele data wordt meestal een architectuur gebruikt met drie lagen: een presentatielaag, een bedrijfslogicalaag en een dataopslaglaag. De presentatielaag is de frontend, waar een transactie door een menselijke interactie wordt veroorzaakt of door het systeem wordt gegenereerd. De logicalaag bestaat uit regels waarmee de transactie wordt geverifieerd en alle data die nodig zijn om de transactie te voltooien, beschikbaar worden gesteld. In de dataopslaglaag worden de transactie en alle bijbehorende data opgeslagen.

De belangrijkste kenmerken van een online transactieverwerkingssysteem zijn:

  • Compliance met ACID: in OLTP-systemen moet de volledige transactie op de juiste manier worden vastgelegd. Een transactie is meestal een uitvoering van een programma waarvoor meerdere stappen of bewerkingen moeten worden doorlopen. De transactie kan volledig zijn wanneer alle betrokken partijen de transactie bevestigen, wanneer het product of de service wordt geleverd of wanneer een bepaald aantal updates wordt aangebracht in de specifieke tabellen in de database. Een transactie wordt alleen correct vastgelegd als alle betrokken stappen worden uitgevoerd en vastgelegd. Als er een fout optreedt in een van de stappen, moet de volledige transactie worden afgebroken en moeten alle stappen uit het systeem worden verwijderd. OLTP-systemen moeten dus voldoen aan het ACID-principe van atomiciteit, consistentie, isolatie en duurzaamheid, om de nauwkeurigheid van de data in het systeem te waarborgen.
    • Atomiciteit: met atomiciteitscontroles wordt gegarandeerd dat alle stappen in een transactie met succes als een groep worden voltooid. Als er stappen tussen de transacties mislukken, moeten alle andere stappen ook mislukken of worden teruggedraaid. Een geslaagde voltooiing van een transactie wordt een 'commit' genoemd. Het mislukken van een transactie wordt een 'abort' genoemd.
    • Consistentie: in de transactie blijft de interne consistentie van de database behouden. Als u de transactie op zichzelf uitvoert in een database die aanvankelijk consistent is, moet de database weer consistent zijn wanneer de transactie volledig is uitgevoerd.
    • Isolatie: de transactie wordt uitgevoerd alsof deze op zichzelf staat, dus zonder andere transacties. Wanneer een set transacties wordt uitgevoerd, is het effect daarvan hetzelfde als wanneer de transacties één voor één worden uitgevoerd. Dit gedrag heet serialiseerbaarheid en wordt meestal geïmplementeerd door de specifieke rijen in de tabel te vergrendelen.
    • Duurzaamheid: de resultaten van de transactie gaan niet verloren bij een fout.
  • Concurrency: OLTP-systemen kunnen een enorm grote gebruikerspopulatie hebben, waarbij veel gebruikers tegelijkertijd toegang proberen te krijgen tot dezelfde data. Het systeem moet ervoor zorgen dat alle gebruikers die lees- of schrijfbewerkingen in het systeem willen uitvoeren, dit gelijktijdig kunnen doen. Met concurrencycontroles wordt gegarandeerd dat twee gebruikers die tegelijkertijd dezelfde data in het databasesysteem openen, die data niet kunnen wijzigen, of dat de ene gebruiker moet wachten tot de andere gebruiker klaar is met de verwerking voordat hij of zij die data kan wijzigen.
  • Schaalbaarheid: OLTP-systemen moeten direct kunnen worden opgeschaald en afgeschaald om het transactievolume realtime te beheren en tegelijkertijd transacties uit te voeren, ongeacht het aantal gebruikers dat toegang probeert te krijgen tot het systeem.
  • Beschikbaarheid: een OLTP-systeem moet altijd beschikbaar zijn en altijd gereed zijn om transacties te ontvangen. Als een transactie verloren gaat, kan dat tot verlies van inkomsten leiden of juridische gevolgen hebben. Omdat transacties overal ter wereld en op elk moment kunnen worden uitgevoerd, moet het systeem 24/7 beschikbaar zijn.
  • Hoge doorvoer en korte responstijd: voor OLTP-systemen zijn responstijden in de orde van een nanoseconde of zelfs nog korter nodig om de gebruikers van een bedrijf productief te houden en te voldoen aan de toenemende verwachtingen van klanten.
  • Betrouwbaarheid: met OLTP-systemen worden doorgaans zeer selectieve, kleine hoeveelheden data gelezen en gemanipuleerd. Het is van het grootste belang dat de data in de database ten alle tijde betrouwbaar zijn voor de gebruikers en applicaties die toegang hebben tot die data.
  • Beveiliging: omdat in deze systemen zeer gevoelige data van klanttransacties worden opgeslagen, is het van cruciaal belang dat de data goed worden beveiligd. Elke inbreuk op de beveiliging kan zeer kostbare gevolgen hebben voor het bedrijf.
  • Herstelbaarheid: OLTP-systemen moeten kunnen worden hersteld als er een hardware- of softwarefout is opgetreden.

Databases voor OLTP-workloads

Relationele databases werden speciaal voor transactieapplicaties gebouwd. Ze bevatten alle essentiële elementen die nodig zijn voor het opslaan en verwerken van grote hoeveelheden transacties, en worden voortdurend bijgewerkt met nieuwe functies en functionaliteit om meer waarde te onttrekken uit deze rijke transactiedata. Relationele databases worden initieel ontworpen om de hoogst mogelijke beschikbaarheid en snelste prestaties te leveren. Aan de vereisten voor concurrency en compliance met ACID is hierin voldaan, zodat de data nauwkeurig, altijd beschikbaar en eenvoudig toegankelijk zijn. De data worden in tabellen opgeslagen en er worden relaties tussen de data vastgelegd, zodat de data door alle applicaties kunnen worden gebruikt en er één centrale bron van waarheid is.

De evolutie van transactieverwerkingsdatabases

Naarmate transacties complexer werden en van elke bron en elk type apparaat overal ter wereld afkomstig konden zijn, bleken traditionele relationele databases niet meer geavanceerd genoeg voor moderne transactionele workflows. Er moest een evolutie plaatsvinden om de hedendaagse transacties, heterogene data en wereldwijde schaal aan te kunnen en, het belangrijkste aspect, gemengde workloads uit te kunnen voeren. Relationele databases werden omgezet in multimodale databases waarin niet alleen relationele data worden opgeslagen en verwerkt, maar ook alle andere soorten data, waaronder xml, html, JSON, Apache Avro en Parquet, en documenten in hun oorspronkelijke vorm, zonder veel transformatie. Er moest ook meer functionaliteit, zoals clustering en sharding, worden toegevoegd aan relationele databases, zodat deze wereldwijd konden worden verspreid en oneindig konden worden opgeschaald om steeds grotere hoeveelheden data op te slaan en te verwerken en gebruik te maken van goedkopere opslag in de cloud. De databases werden daarnaast uitgebreid met functies als geavanceerde in-memory analyse, visualisatie en wachtrijen voor transactiegebeurtenissen. Daardoor kunnen er nu meerdere workloads worden uitgevoerd, zoals het analyseren van transactiedata, het verwerken van streamingdata (Internet of Things, IoT) en het uitvoeren van ruimtelijke en grafiekanalyses.

In moderne relationele databases in de cloud zijn veel van de beheer- en operationele aspecten van de database geautomatiseerd, waardoor de provisioning en het gebruik van deze databases eenvoudiger is geworden. De provisioning, de beveiliging, het herstel, de back-up en de op- of afschaling zijn geautomatiseerd, waardoor databasebeheerders en IT-teams veel minder tijd hoeven te besteden aan het onderhoud van de databases. Er is ook intelligence geïntegreerd in de databases om de data automatisch af te stemmen en te indexeren, zodat de prestaties van databasequery's consistent zijn, ongeacht de hoeveelheid data, het aantal gelijktijdige gebruikers en de complexiteit van de query's. Deze clouddatabases bevatten ook selfservicefuncties en REST API's, zodat ontwikkelaars en analisten eenvoudig toegang kunnen krijgen tot de data en deze kunnen gebruiken. Hierdoor wordt de ontwikkeling van applicaties vereenvoudigd en kunnen ontwikkelaars gemakkelijker nieuwe functionaliteit en aanpassingen aanbrengen in hun applicaties. Ook het verrichten van analyses is eenvoudiger geworden, waardoor analisten en datawetenschappers gemakkelijker inzichten kunnen afleiden uit de data.

De juiste database selecteren voor uw OLTP-workload

Omdat het voor IT niet altijd eenvoudig is om gelijke tred te houden met de snelheid van het bedrijfsleven, is het belangrijk dat u bij het kiezen van een operationele database rekening houdt met uw onmiddellijke behoeften en vereisten op de lange termijn wat betreft de data. Voor het opslaan van transacties, het onderhouden van archiveringssystemen en contentbeheer hebt u een database nodig met een grote mate van concurrency, een hoge doorvoer, weinig latentie en bedrijfskritieke kenmerken zoals een hoge beschikbaarheid, databeveiliging en herstel na calamiteiten. Uw workload fluctueert waarschijnlijk gedurende de dag, de week en het jaar. U kunt dus veel kosten besparen door een database te kiezen met automatische schaalaanpassing. Misschien moet u ook bepalen of u een speciaal ontwikkelde database of een meer algemene database wilt gebruiken. Als u eisen stelt aan een bepaald type data, kan een speciaal voor u gebouwde database interessant zijn, maar alleen als daarbij geen concessies worden gedaan wat betreft de andere kenmerken die u nodig hebt. Het kan veel geld en resources kosten om die kenmerken later in de applicatielaag te laten opnemen. Als uw hoeveelheid data verder toeneemt en u de functionaliteit van uw applicatie wilt uitbreiden, heeft het toevoegen van single-purpose of fit-for-purpose databases slechts tot gevolg dat er datasilo's worden gecreëerd, en worden de problemen met het databeheer alleen maar groter. U moet ook rekening houden met andere functionaliteiten die misschien nodig zijn voor uw specifieke workload, bijvoorbeeld opnamevereisten, push-down computingvereisten en beperkingen wat betreft de omvang.

Selecteer een toekomstbestendige clouddatabaseservice met selfservicefuncties en volledig geautomatiseerd databeheer, zodat uw datagebruikers (ontwikkelaars, analisten, data-engineers, datawetenschappers en databasebeheerders) meer kunnen doen met de data en sneller applicaties kunnen ontwikkelen.

Kom meer te weten over Oracle Autonomous Transaction Processing Database, de meest gebruikte OLTP-databaseservice voor de cloud. Probeer het gratis uit.