Dela via

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 när en transaktion inte kan slutföras. Konsistens innebär att transaktioner alltid lämnar data i ett giltigt tillstånd. Dessa transaktioner är informella beskrivningar av atomaritet och konsekvens. Det finns mer formella definitioner av dessa egenskaper, till exempel atomiska, konsekventa, isolerade och varaktiga (ACID).

** Transaktionsdatabaser kan stödja stark konsistens för transaktioner genom att använda olika låsningsstrategier, till exempel pessimistisk låsning. Dessa strategier hjälper till att säkerställa att alla data förblir konsekventa inom ramen för arbetsbelastningen, för alla användare och processer.

Den vanligaste distributionsarkitekturen som använder transaktionsdata är datalagernivån i en arkitektur på tre nivåer. En arkitektur med tre 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, framtvingat
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
Frågeflexibilitet Mycket flexibel
Skala Små (MB) 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 har en negativ effekt på den dagliga driften i verksamheten.

OLTP-system är utformade för att effektivt bearbeta och lagra transaktioner och köra frågor mot transaktionsdata. Målet att effektivt bearbeta och lagra enskilda transaktioner av ett OLTP-system uppnås delvis genom datanormalisering, vilket delar upp data i mindre, mindre redundanta segment. Det här steget gör det möjligt för OLTP-systemet att bearbeta ett stort antal transaktioner oberoende av varandra. Det undviker också extra processer som krävs för att upprätthålla dataintegriteten i närvaro av redundanta data.

Utmaningar

Ett OLTP-system kan skapa några utmaningar:

  • När du kör analyser mot data som förlitar sig på aggregerade beräkningar över miljontals enskilda transaktioner är det mycket resursintensivt för ett OLTP-system. De kan köras långsamt och orsaka en fördröjning genom att blockera andra transaktioner i databasen. Därför är OLTP-system inte alltid idealiska för hantering av aggregeringar över stora mängder distribuerade data. Men det finns undantag, till exempel ett välplanerad schema.

  • 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. Den ökade normaliseringen kan göra det svårt för företagsanvändare att fråga utan hjälp av en databasadministratör (DBA) eller datautvecklare.

  • När du lagrar historiken för transaktioner på obestämd tid eller lagrar för mycket data i en tabell kan det leda till långsamma frågeprestanda, beroende på antalet transaktioner som du lagrar. 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 och mobil- eller skrivbordsprogram kommunicerar vanligtvis med OLTP-systemet via en REST API-mellanhand.

I praktiken är de flesta arbetsbelastningar inte helt OLTP. De innehåller ofta även en analyskomponent och kräver realtidsrapportering, till exempel att köra rapporter mot driftsystemet. Den här arbetsbelastningen kallas hybridtransaktions- och analysbearbetning (HTAP). Mer information finns i Online analytical processing (OLAP).

I Azure uppfyller följande datalager de grundläggande kraven för OLTP och hantering av transaktionsdata:

Kriterier för nyckelval

Om du vill 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 som görs om vilken databas som används.

  • Är dina krav på skrivdataflöde höga? Om ja väljer du ett alternativ som tillhandahåller minnesinterna tabeller eller globala distributionsfunktioner som Azure Cosmos DB.

  • Är din lösning multitenant? I så fall bör du överväga alternativ som stöder kapacitetspooler. Flera databasinstanser hämtas från en elastisk pool med resurser i stället för fasta resurser per databas. Elastiska pooler kan hjälpa dig att bättre distribuera kapacitet över alla databasinstanser och göra din lösning mer kostnadseffektiv. Azure Cosmos DB erbjuder flera isoleringsmodeller för scenarier med flera klientorganisationer.

  • 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 eller global distribution.

  • 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.

  • Kräver din arbetsbelastning garanterade ACID-transaktioner? Om du arbetar med icke-relationella data bör du överväga Azure Cosmos DB, som ger ACID-garantier via transaktionella batchåtgärder inom en logisk partition.

  • Har databasen specifika säkerhetsbehov? Om ja, granska alternativen som ger funktioner som säkerhet på radnivå, datamaskering och transparent datakryptering.

  • Kräver din lösning distribuerade transaktioner? Om ja kan du överväga elastiska transaktioner i Azure SQL Database och SQL Managed Instance. SQL Managed Instance stöder också traditionella anrop via Microsoft Distributed Transaction Coordinator (MSDTC).

Nästa steg