Online Transaction Processing (OLTP)

2025-04-17

Hantering av transaktionsdata med hjälp av datorsystem kallas för onlinetransaktionsbearbetning (OLTP). OLTP-system registrerar affärsinteraktioner när de sker i den dagliga driften av organisationen och stöder frågor om dessa data för att göra slutsatsdragningar.

Transaktionsdata

Transaktionsdata är information som spårar interaktioner relaterade till en organisations aktiviteter. Dessa interaktioner är vanligtvis affärstransaktioner, till exempel betalningar som tas emot från kunder, betalningar som görs till leverantörer, produkter som rör sig genom inventering, beställningar som tagits eller tjänster som levererats. Transaktionshändelser, som representerar själva transaktionerna, innehåller vanligtvis en tidsdimension, vissa numeriska värden och referenser till andra data.

Transaktioner måste vanligtvis vara atomiska och konsekventa. Atomicitet innebär att en hel transaktion alltid lyckas eller misslyckas som en arbetsenhet och aldrig lämnas i ett halvt slutfört tillstånd. Om en transaktion inte kan slutföras måste databassystemet återställa alla steg som redan har utförts som en del av transaktionen. I ett traditionellt hanteringssystem för relationsdatabaser (RDBMS) sker den här återställningen automatiskt om en transaktion inte kan slutföras. Konsistens innebär att transaktioner alltid lämnar data i ett giltigt tillstånd. (Detta är mycket informella beskrivningar av atomitet och konsekvens. Det finns mer formella definitioner av dessa egenskaper, till exempel ACID.)

Transaktionsdatabaser kan stödja stark konsistens för transaktioner med hjälp av olika låsningsstrategier, till exempel pessimistisk låsning, för att säkerställa att all data är starkt konsistent inom företagets ramar, för alla processer och användare.

Den vanligaste distributionsarkitekturen som använder transaktionsdata är datalagernivån i en arkitektur på 3 nivåer. En arkitektur på 3 nivåer består vanligtvis av en presentationsnivå, affärslogiknivå och datalagernivå. En relaterad distributionsarkitektur är N-nivåarkitekturen, som kan ha flera mellannivåer som hanterar affärslogik.

Typiska egenskaper hos transaktionsdata

Transaktionsdata tenderar att ha följande egenskaper:

Krav	Beskrivning
Normalisering	Mycket normaliserad
Schemat	Schema vid skrivning, strikt genomfört
Konsekvens	Stark konsistens, ACID-garantier
Integritet	Hög integritet
Använder transaktioner	Ja
Strategi för låsning	Pessimistisk eller optimistisk
Uppdateringsbar	Ja
Tilläggsbart	Ja
Arbetsbelastning	Tunga skrivningar, måttliga läsningar
Indexering	Primära och sekundära index
Datumstorlek	Liten till medelstor
Modell	Relation
Datakontur	Tabell
Frågeflexibilitet	Mycket flexibel
Skala	Små (MB) till Stora (flera TB)

När du ska använda den här lösningen

Välj OLTP när du effektivt behöver bearbeta och lagra affärstransaktioner och omedelbart göra dem tillgängliga för klientprogram på ett konsekvent sätt. Använd den här arkitekturen när en påtaglig fördröjning i bearbetningen skulle ha en negativ inverkan på den dagliga driften i verksamheten.

OLTP-system är utformade för att effektivt bearbeta och lagra transaktioner samt fråga transaktionsdata. Målet att effektivt bearbeta och lagra enskilda transaktioner av ett OLTP-system uppnås delvis genom datanormalisering– det vill säga att dela upp data i mindre segment som är mindre redundanta. Detta stöder effektivitet eftersom det gör det möjligt för OLTP-systemet att bearbeta ett stort antal transaktioner oberoende av varandra och undviker extra bearbetning som krävs för att upprätthålla dataintegriteten i närvaro av redundanta data.

Utmaningar

Att implementera och använda ett OLTP-system kan skapa några utmaningar:

OLTP-system är inte alltid bra för att hantera aggregeringar över stora mängder data, även om det finns undantag, till exempel en välplanerad SQL Server-baserad lösning. Analys mot data, som förlitar sig på aggregerade beräkningar över miljontals enskilda transaktioner, är mycket resursintensiva för ett OLTP-system. De kan vara långsamma att utföra och kan orsaka en fördröjning genom att blockera andra transaktioner i databasen.
När du utför analys och rapportering av data som är mycket normaliserade tenderar frågorna att vara komplexa, eftersom de flesta frågor måste avnormalisera data med hjälp av kopplingar. Namngivningskonventioner för databasobjekt i OLTP-system tenderar också att vara terse och kortfattade. Den ökade normaliseringen i kombination med terse-namngivningskonventioner gör OLTP-system svåra för företagsanvändare att fråga, utan hjälp av en DBA eller datautvecklare.
Att lagra historiken för transaktioner på obestämd tid och lagra för mycket data i en tabell kan leda till långsamma frågeprestanda, beroende på hur många transaktioner som lagras. Den vanliga lösningen är att upprätthålla en relevant tidsperiod (till exempel det aktuella räkenskapsåret) i OLTP-systemet och avlasta historiska data till andra system, till exempel ett datalager eller ett informationslager.

OLTP i Azure

Program som webbplatser som finns i App Service Web Apps, REST-API:er som körs i App Service eller mobila program eller skrivbordsprogram kommunicerar med OLTP-systemet, vanligtvis via en REST API-mellanhand.

I praktiken är de flesta arbetsbelastningar inte enbart OLTP. Det tenderar också att finnas en analytisk komponent. Dessutom finns det en ökande efterfrågan på realtidsrapportering, till exempel att köra rapporter mot driftsystemet. Detta kallas även hybridtransaktions-/analysbearbetning (HTAP) (hybridtransaktions- och analysbearbetning). Mer information finns i Online Analytical Processing (OLAP).

I Azure uppfyller alla följande datalager huvudkraven för OLTP och hantering av transaktionsdata:

Kriterier för nyckelval

För att begränsa alternativen börjar du med att svara på följande frågor:

Vill du ha en hanterad tjänst i stället för att hantera dina egna servrar?
Har din lösning specifika beroenden för Microsoft SQL Server-, MySQL- eller PostgreSQL-kompatibilitet? Ditt program kan begränsa de datalager som du kan välja baserat på de drivrutiner som det stöder för kommunikation med datalagret, eller de antaganden det gör om vilken databas som används.
Är dina krav på skrivdataflöde särskilt höga? Om ja väljer du ett alternativ som innehåller minnesinterna tabeller.
Är din lösning multitenant? I så fall bör du överväga alternativ som stöder kapacitetspooler, där flera databasinstanser drar från en elastisk pool med resurser, i stället för fasta resurser per databas. Detta kan hjälpa dig att bättre distribuera kapacitet över alla databasinstanser och göra din lösning mer kostnadseffektiv.
Behöver dina data vara läsbara med låg svarstid i flera regioner? Om ja väljer du ett alternativ som stöder läsbara sekundära repliker.
Måste databasen vara mycket tillgänglig i geo-grafiska regioner? Om ja väljer du ett alternativ som stöder geografisk replikering. Överväg också alternativen som stöder automatisk övergång från den primära repliken till en sekundär replik.
Har databasen specifika säkerhetsbehov? Om ja, granska alternativen som ger funktioner som säkerhet på radnivå, datamaskering och transparent datakryptering.

Kapacitetsmatris

I följande tabeller sammanfattas de viktigaste skillnaderna i funktioner.

Allmänna funktioner

Kapacitet	Azure SQL Database	SQL Server på en virtuell Azure-dator	Microsoft Azure-databas för MySQL	Azure-databasen för PostgreSQL
Är hanterad tjänst	Ja	Nej	Ja	Ja
Körs på plattform	Ej tillämpligt	Windows, Linux, Docker	Ej tillämpligt	Ej tillämpligt
Programmerbarhet ¹	T-SQL, .NET, R	T-SQL, .NET, R, Python	SQL	SQL, PL / pgSQL, PL / JavaScript (v8)

[1] Omfattar inte stöd för klientdrivrutiner, vilket gör att många programmeringsspråk kan ansluta till och använda OLTP-datalagret.

Skalbarhetsfunktioner

Kapacitet	Azure SQL Database	SQL Server på en virtuell Azure-dator	Microsoft Azure-databas för MySQL	Azure-databasen för PostgreSQL
Maximal databasinstansstorlek	4 TB	256 TB	16 TB	16 TB
Stödjer kapacitetspooler	Ja	Ja	Nej	Nej
Stöd för utskalning av kluster	Nej	Ja	Nej	Nej
Dynamisk skalbarhet (skala upp)	Ja	Nej	Ja	Ja

Kapacitet för analytiska arbetslaster

Kapacitet	Azure SQL Database	SQL Server på en virtuell Azure-dator	Microsoft Azure-databas för MySQL	Azure-databasen för PostgreSQL
Temporala tabeller	Ja	Ja	Nej	Nej
Minnesinterna tabeller (minnesoptimerade)	Ja	Ja	Nej	Nej
Stöd för Columnstore	Ja	Ja	Nej	Nej
Anpassningsbar frågebearbetning	Ja	Ja	Nej	Nej

Kapacitet för tillgänglighet

Kapacitet	Azure SQL Database	SQL Server på en virtuell Azure-dator	Microsoft Azure-databas för MySQL	Azure-databasen för PostgreSQL
Läsbara sekundärfiler	Ja	Ja	Ja	Ja
Geografisk replikering	Ja	Ja	Ja	Ja
Automatisk växling till sekundär system	Ja	Nej	Nej	Nej
Återställning till en specifik tidpunkt	Ja	Ja	Ja	Ja

Säkerhetsfunktioner

Kapacitet	Azure SQL Database	SQL Server på en virtuell Azure-dator	Microsoft Azure-databas för MySQL	Azure-databasen för PostgreSQL
Säkerhet på radnivå	Ja	Ja	Ja	Ja
Datamaskning	Ja	Ja	Nej	Nej
Transparent datakryptering	Ja	Ja	Ja	Ja
Begränsa åtkomsten till specifika IP-adresser	Ja	Ja	Ja	Ja
Begränsa åtkomsten så att endast VNet-åtkomst tillåts	Ja	Ja	Ja	Ja
Microsoft Entra-autentisering	Ja	Nej	Ja	Ja
Active Directory-autentisering	Nej	Ja	Nej	Nej
Multifaktorautentisering	Ja	Nej	Ja	Ja
Stödjer Always Encrypted	Ja	Ja	Nej	Nej
Privat IP-adress	Nej	Ja	Nej	Nej