Delen via

Online Transaction Processing (OLTP)

  • Artikel

Het beheer van transactionele gegevens met behulp van computersystemen wordt OLTP (Online Transaction Processing) genoemd. OLTP-systemen registreren zakelijke interacties wanneer ze plaatsvinden in de dagelijkse werking van de organisatie en ondersteunen het opvragen van deze gegevens om deducties te maken.

Transactionele gegevens

Transactionele gegevens zijn informatie die de interacties bijhoudt die betrekking hebben op de activiteiten van een organisatie. Deze interacties zijn doorgaans zakelijke transacties, zoals betalingen die zijn ontvangen van klanten, betalingen aan leveranciers, producten die worden verplaatst door voorraad, orders die zijn uitgevoerd of services geleverd. Transactionele gebeurtenissen, die de transacties zelf vertegenwoordigen, bevatten doorgaans een tijddimensie, enkele numerieke waarden en verwijzingen naar andere gegevens.

Transacties moeten doorgaans atomisch en consistent zijn. Atomiciteit betekent dat een volledige transactie altijd slaagt of mislukt als één werkeenheid en nooit in een half voltooide status wordt achtergelaten. Als een transactie niet kan worden voltooid, moet het databasesysteem alle stappen terugdraaien die al zijn uitgevoerd als onderdeel van die transactie. In een traditioneel relationeel databasebeheersysteem (RDBMS) vindt deze terugdraaibewerking automatisch plaats als een transactie niet kan worden voltooid. Consistentie betekent dat transacties de gegevens altijd in een geldige status achterlaten. (Dit zijn zeer informele beschrijvingen van atomiciteit en consistentie. Er zijn meer formele definities van deze eigenschappen, zoals ACID.)

Transactionele databases kunnen ondersteuning bieden voor sterke consistentie voor transacties met behulp van verschillende vergrendelingsstrategieën, zoals pessimistische vergrendeling, om ervoor te zorgen dat alle gegevens sterk consistent zijn binnen de context van de onderneming, voor alle gebruikers en processen.

De meest voorkomende implementatiearchitectuur die gebruikmaakt van transactionele gegevens is de gegevensopslaglaag in een architectuur met drie lagen. Een architectuur met drie lagen bestaat doorgaans uit een presentatielaag, een bedrijfslogicalaag en een gegevensopslaglaag. Een gerelateerde implementatiearchitectuur is de N-tier-architectuur , die mogelijk meerdere middelste lagen heeft die bedrijfslogica verwerken.

Typische kenmerken van transactionele gegevens

Transactionele gegevens hebben meestal de volgende kenmerken:

Vereiste Beschrijving
Normalisatie Zeer genormaliseerd
Schema Schema bij schrijven, sterk afgedwongen
Consistentie Sterke consistentie, ACID-garanties
Integriteit Hoge integriteit
Gebruikt transacties Ja
Vergrendelingsstrategie Pessimistisch of optimistisch
Kan worden bijgewerkt Ja
Toevoegbaar Ja
Workload Zware schrijfbewerkingen, gemiddelde leesbewerkingen
Indexeren Primaire en secundaire indexen
Datumgrootte Klein tot middelgroot
Modelleren Relationeel
Gegevensshape Tabellair
Queryflexiteit Zeer flexibel
Schaal wijzigen Klein (MB's) naar Groot (enkele TB's)

Wanneer u deze oplossing gebruikt

Kies OLTP wanneer u zakelijke transacties efficiënt moet verwerken en opslaan en deze onmiddellijk op een consistente manier beschikbaar wilt maken voor clienttoepassingen. Gebruik deze architectuur wanneer een tastbare vertraging in de verwerking een negatieve invloed zou hebben op de dagelijkse activiteiten van het bedrijf.

OLTP-systemen zijn ontworpen om transacties efficiënt te verwerken en op te slaan, evenals transactionele gegevens op te vragen. Het doel van het efficiënt verwerken en opslaan van afzonderlijke transacties door een OLTP-systeem wordt deels bereikt door gegevensnormalisatie, dat wil gezegd, waarbij de gegevens worden opgesplitst in kleinere segmenten die minder redundant zijn. Dit ondersteunt efficiëntie omdat het OLTP-systeem grote aantallen transacties onafhankelijk kan verwerken en extra verwerking voorkomt die nodig is om de gegevensintegriteit te behouden in aanwezigheid van redundante gegevens.

Uitdagingen

Het implementeren en gebruiken van een OLTP-systeem kan een aantal uitdagingen opleveren:

  • OLTP-systemen zijn niet altijd geschikt voor het verwerken van aggregaties over grote hoeveelheden gegevens, hoewel er uitzonderingen zijn, zoals een goed geplande oplossing op basis van SQL Server. Analyses op basis van de gegevens, die afhankelijk zijn van cumulatieve berekeningen ten opzichte van miljoenen afzonderlijke transacties, zijn zeer resource-intensief voor een OLTP-systeem. Ze kunnen traag worden uitgevoerd en kunnen een vertraging veroorzaken door andere transacties in de database te blokkeren.

  • Bij het uitvoeren van analyses en rapportage over gegevens die zeer genormaliseerd zijn, zijn de query's meestal complex, omdat de meeste query's de normalisering van de gegevens moeten ongedaan maken met behulp van joins. Ook zijn naamconventies voor databaseobjecten in OLTP-systemen meestal terse en beknopt. De verhoogde normalisatie in combinatie met terse-naamconventies maakt OLTP-systemen moeilijk voor zakelijke gebruikers om query's uit te voeren, zonder hulp van een DBA- of gegevensontwikkelaar.

  • Het opslaan van de geschiedenis van transacties voor onbepaalde tijd en het opslaan van te veel gegevens in een tabel kan leiden tot trage queryprestaties, afhankelijk van het aantal opgeslagen transacties. De algemene oplossing is het onderhouden van een relevant tijdvenster (zoals het huidige fiscale jaar) in het OLTP-systeem en het offloaden van historische gegevens naar andere systemen, zoals een datamart of datawarehouse.

OLTP in Azure

Toepassingen zoals websites die worden gehost in App Service Web Apps, REST API's die worden uitgevoerd in App Service, of mobiele of desktoptoepassingen communiceren met het OLTP-systeem, meestal via een REST API-intermediair.

In de praktijk zijn de meeste workloads niet uitsluitend OLTP. Er is meestal ook een analytisch onderdeel. Daarnaast is er steeds meer vraag naar realtime rapportage, zoals het uitvoeren van rapporten op basis van het operationele systeem. Dit wordt ook wel hybride transactionele/analytische verwerking (HTAP) genoemd (Hybrid Transactional and Analytical Processing). Zie OLAP (Online Analytical Processing) voor meer informatie.

In Azure voldoen alle volgende gegevensarchieven aan de kernvereisten voor OLTP en het beheer van transactiegegevens:

Criteria voor sleutelselectie

Om de keuzes te beperken, beantwoordt u eerst deze vragen:

  • Wilt u een beheerde service in plaats van uw eigen servers beheren?

  • Heeft uw oplossing specifieke afhankelijkheden voor compatibiliteit met Microsoft SQL Server, MySQL of PostgreSQL? Uw toepassing kan de gegevensarchieven beperken die u kunt kiezen op basis van de stuurprogramma's die worden ondersteund voor de communicatie met het gegevensarchief, of de veronderstellingen die worden gemaakt over welke database wordt gebruikt.

  • Zijn uw vereisten voor schrijfdoorvoer bijzonder hoog? Zo ja, kies een optie die tabellen in het geheugen biedt.

  • Is uw oplossing multitenant? Als dat het geval is, kunt u opties overwegen die capaciteitspools ondersteunen, waarbij meerdere database-exemplaren afkomstig zijn van een elastische pool met resources, in plaats van vaste resources per database. Hierdoor kunt u de capaciteit beter verdelen over alle database-exemplaren en kunt u uw oplossing rendabeler maken.

  • Moeten uw gegevens leesbaar zijn met lage latentie in meerdere regio's? Zo ja, kies dan een optie die leesbare secundaire replica's ondersteunt.

  • Moet uw database maximaal beschikbaar zijn in geografische grafische regio's? Zo ja, kies dan een optie die ondersteuning biedt voor geografische replicatie. Overweeg ook de opties die automatische failover van de primaire replica naar een secundaire replica ondersteunen.

  • Heeft uw database specifieke beveiligingsbehoeften? Zo ja, bekijk dan de opties die mogelijkheden bieden, zoals beveiliging op rijniveau, gegevensmaskering en transparante gegevensversleuteling.

Mogelijkheidsmatrix

De volgende tabellen bevatten een overzicht van de belangrijkste verschillen in mogelijkheden.

Algemene mogelijkheden

Mogelijkheid Azure SQL-database SQL Server op een virtuele machine van Azure Azure Database for MySQL Azure Database for PostgreSQL
Is beheerde service Ja No Ja Ja
Wordt uitgevoerd op platform N.v.t. Windows, Linux, Docker N.v.t. N.v.t.
Programmeerbaarheid 1 T-SQL, .NET, R T-SQL, .NET, R, Python SQL SQL, PL/pgSQL, PL/JavaScript (v8)

[1] Niet inclusief ondersteuning voor clientstuurprogramma's, waardoor veel programmeertalen verbinding kunnen maken met en het OLTP-gegevensarchief kunnen gebruiken.

Schaalbaarheidsmogelijkheden

Mogelijkheid Azure SQL-database SQL Server op een virtuele machine van Azure Azure Database for MySQL Azure Database for PostgreSQL
Maximale grootte van database-exemplaren 4 TB 256 TB 16 TB 16 TB
Ondersteunt capaciteitspools Ja Ja No Nr.
Ondersteunt uitschalen van clusters Nr. Ja No Nr.
Dynamische schaalbaarheid (omhoog schalen) Ja No Ja Ja

Mogelijkheden voor analyseworkloads

Mogelijkheid Azure SQL-database SQL Server op een virtuele machine van Azure Azure Database for MySQL Azure Database for PostgreSQL
Tijdelijke tabellen Ja Ja No Nr.
Tabellen in het geheugen (geoptimaliseerd voor geheugen) Ja Ja No Nr.
Ondersteuning voor Columnstore Ja Ja No Nr.
Verwerking van adaptieve query’s Ja Ja No Nr.

Beschikbaarheid

Mogelijkheid Azure SQL-database SQL Server op een virtuele machine van Azure Azure Database for MySQL Azure Database for PostgreSQL
Leesbare secundaire bestanden Ja Ja Ja Ja
Geografische replicatie Ja Ja Ja Ja
Automatische failover naar secundair Ja No Nee Nr.
Herstel naar een bepaald tijdstip Ja Ja Ja Ja

Beveiligingsmogelijkheden

Mogelijkheid Azure SQL-database SQL Server op een virtuele machine van Azure Azure Database for MySQL Azure Database for PostgreSQL
Beveiliging op rijniveau Ja Ja Ja Ja
Gegevensmaskering Ja Ja No Nr.
Transparent Data Encryption Ja Ja Ja Ja
Toegang tot specifieke IP-adressen beperken Ja Ja Ja Ja
Toegang beperken om alleen VNet-toegang toe te staan Ja Ja Ja Ja
Microsoft Entra-verificatie Ja No Ja Ja
Active Directory-authenticatie Nr. Ja No Nr.
Meervoudige verificatie Ja No Ja Ja
Biedt ondersteuning voor Always Encrypted Ja Ja No Nr.
Privé IP-adres Nr. Ja No Nr.

Volgende stappen