Delen via

Online Transaction Processing (OLTP)

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 wanneer een transactie niet kan worden voltooid. Consistentie betekent dat transacties de gegevens altijd in een geldige status achterlaten. Deze transacties zijn informele beschrijvingen van atomiciteit en consistentie. Er zijn meer formele definities van deze eigenschappen, zoals atomisch, consistent, geïsoleerd en duurzaam (ACID).

Transactionele databases kunnen sterke consistentie voor transacties ondersteunen met behulp van verschillende vergrendelingsstrategieën, zoals pessimistische vergrendeling. Deze strategieën helpen ervoor te zorgen dat alle gegevens consistent blijven binnen de context van de workload, voor alle gebruikers en processen.

De meest voorkomende implementatiearchitectuur die gebruikmaakt van transactionele gegevens is de gegevensarchieflaag 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 meerdere middelste lagen kan hebben die bedrijfslogica verwerken.

Typische kenmerken van transactionele gegevens

Transactionele gegevens hebben meestal de volgende kenmerken.

Vereiste Beschrijving
Normalisatie Zeer genormaliseerd
Schema Schema bij schrijven, afgedwongen
Consistentie Sterke consistentie, ACID-garanties
Integriteit Hoge integriteit
Gebruikt transacties Ja
Vergrendelingsstrategie Pessimistisch of optimistisch
Kan worden bijgewerkt Ja
Toevoegbaar Ja
werkbelasting Zware schrijfbewerkingen, gemiddelde leesbewerkingen
Indexeren Primaire en secundaire indexen
Datumgrootte Klein tot middelgroot
Flexibiliteit van query's Zeer flexibel
Schaal Klein (MBs) tot groot (enkele TBs)

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 negatief effect heeft op de dagelijkse activiteiten van het bedrijf.

OLTP-systemen zijn ontworpen om transacties efficiënt te verwerken en op te slaan en 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, waardoor de gegevens worden opgesplitst in kleinere, minder redundante segmenten. Met deze stap kan het OLTP-systeem grote aantallen transacties onafhankelijk verwerken. Er worden ook extra processen vermeden die nodig zijn om de gegevensintegriteit te behouden in aanwezigheid van redundante gegevens.

Uitdagingen

Een OLTP-systeem kan een aantal uitdagingen opleveren:

  • Wanneer u analyses uitvoert op de gegevens die afhankelijk zijn van cumulatieve berekeningen ten opzichte van miljoenen afzonderlijke transacties, is het zeer resource-intensief voor een OLTP-systeem. Ze kunnen traag worden uitgevoerd en leiden tot een vertraging door andere transacties in de database te blokkeren. Als gevolg hiervan zijn OLTP-systemen niet altijd ideaal voor het verwerken van aggregaties over grote hoeveelheden gedistribueerde gegevens. Maar er zijn uitzonderingen, zoals een goed gepland schema.

  • Wanneer u analyses uitvoert en rapporteert over gegevens die zeer genormaliseerd is, zijn de query's meestal complex, omdat de meeste query's de gegevens denormaliseren door middel van join-operaties. Door de toegenomen normalisatie kunnen zakelijke gebruikers moeilijk query's uitvoeren zonder de hulp van een databasebeheerder (DBA) of gegevensontwikkelaar.

  • Wanneer u de geschiedenis van transacties voor onbepaalde tijd opslaat of te veel gegevens opslaat in een tabel, kan dit leiden tot trage queryprestaties, afhankelijk van het aantal transacties dat u opslaat. 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 en mobiele of desktoptoepassingen communiceren doorgaans met het OLTP-systeem via een REST API-intermediair.

In de praktijk zijn de meeste workloads niet helemaal OLTP. Ze bevatten vaak ook een analytische component en vereisen realtime rapportage, zoals het uitvoeren van rapporten op basis van het operationele systeem. Deze workload wordt hybride transactionele en analytische verwerking (HTAP) genoemd. Zie OLAP (Online Analytical Processing) voor meer informatie.

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

Criteria voor sleutelselectie

Om de keuzes te beperken, beantwoordt u eerst de volgende 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 hoog? Zo ja, kies dan een optie die in-memory tabellen of wereldwijde distributiemogelijkheden biedt, zoals Azure Cosmos DB.

  • Is uw oplossing multitenant? Zo ja, overweeg dan opties die capaciteitspools ondersteunen. Meerdere database-exemplaren zijn afkomstig uit een elastische pool met resources, in plaats van vaste resources per database. Elastische pools kunnen u helpen om de capaciteit beter over alle database-exemplaren te verdelen en uw oplossing rendabeler te maken. Azure Cosmos DB biedt meerdere isolatiemodellen voor scenario's met meerdere tenants.

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

  • Moet uw database hoog beschikbaar zijn in geografische 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.

  • Vereist uw workload gegarandeerde ACID-transacties? Als u met niet-relationele gegevens werkt, kunt u Azure Cosmos DB overwegen. Dit biedt ACID-garanties via transactionele batchbewerkingen binnen een logische partitie.

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

  • Vereist uw oplossing gedistribueerde transacties? Zo ja, overweeg dan elastische transacties in Azure SQL Database en SQL Managed Instance. SQL Managed Instance biedt ook ondersteuning voor traditionele aanroepen via de Microsoft Distributed Transaction Coordinator (MSDTC).

Volgende stappen

  • Last updated on