Online Transaction Processing (OLTP)

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. Konsekvens 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 konsekvens för transaktioner med hjälp av olika låsningsstrategier, till exempel pessimistisk låsning, för att säkerställa att alla data är starkt konsekventa inom företagets kontext, för alla användare och processer.

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:

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 köra och kan orsaka en långsammare körning 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:

• Azure SQL Database
• SQL Server på en virtuell Azure-dator
• Azure Database for MySQL
• Azure Database for PostgreSQL

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. Tänk också på de alternativ som stöder automatisk redundans 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

[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

Analysfunktioner för arbetsbelastning

Kapacitet för tillgänglighet

Säkerhetsfunktioner

Deltagare

Den här artikeln underhålls av Microsoft. Det har ursprungligen skrivits av följande medarbetare.

Huvudförfattare:

• Zoiner Tejada | VD och arkitekt

Nästa steg

• Introduktion till minnesoptimerade tabeller
• Minnesintern OLTP-översikt och användningsscenarier
• Optimera prestanda med hjälp av minnesintern teknik i Azure SQL Database och Azure SQL Managed Instance
• Distribuerade transaktioner över molndatabaser

Relaterade resurser

• Guide för Azure-dataarkitektur
• IBM z/OS online transaktionsbearbetning på Azure