Online Transaction Processing (OLTP)

  • Artikel

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 en traditionell 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:

Krav Beskrivning
Normalisering Mycket normaliserad
Schema Schema vid skrivning, starkt framtvingat
Konsekvens Stark konsekvens, ACID-garantier
Integritet Hög integritet
Använder transaktioner Ja
Strategi för låsning Pessimistisk eller optimistisk
Uppdaterbar Ja
Tilläggsbart Ja
Arbetsbelastning Tunga skrivningar, måttliga läsningar
Indexering Primära och sekundära index
Datumstorlek Liten till medelstor
Modell Relation
Dataform Tabell
Frågeflexflexitet Mycket flexibel
Skala Små (MBs) till Stora (några 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 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 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. 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

Kapacitet Azure SQL Database SQL Server på en virtuell Azure-dator Azure Database for MySQL Azure Database for PostgreSQL
Är hanterad tjänst Ja No Ja Ja
Körs på plattform Ej tillämpligt Windows, Linux, Docker Saknas Saknas
Programmering 1 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 Azure Database for MySQL Azure Database for PostgreSQL
Maximal databasinstansstorlek 4 TB 256 TB 16 TB 16 TB
Stöder kapacitetspooler Ja Ja No Nej
Stöd för utskalning av kluster Nej Ja No Nej
Dynamisk skalbarhet (skala upp) Ja No Ja Ja

Analysfunktioner för arbetsbelastning

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

Kapacitet för tillgänglighet

Kapacitet Azure SQL Database SQL Server på en virtuell Azure-dator Azure Database for MySQL Azure Database for PostgreSQL
Läsbara sekundärfiler Ja Ja Ja Ja
Geografisk replikering Ja Ja Ja Ja
Automatisk redundans till sekundär Ja No No Nej
Återställning till tidpunkt Ja Ja Ja Ja

Säkerhetsfunktioner

Kapacitet Azure SQL Database SQL Server på en virtuell Azure-dator Azure Database for MySQL Azure Database for PostgreSQL
Säkerhet på radnivå Ja Ja Ja Ja
Datamaskning Ja Ja No 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 No Ja Ja
Active Directory-autentisering Nej Ja No Nej
Multifaktorautentisering Ja No Ja Ja
Stöder Always Encrypted Ja Ja No Nej
Privat IP Nej Ja No Nej

Deltagare

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

Huvudförfattare:

Nästa steg