Dela via

In-Memory OLTP-översikt och användningsscenarier

gäller för:SQL ServerAzure SQL DatabaseAzure SQL Managed Instance

In-Memory OLTP är den främsta tekniken i SQL Server och SQL Database för att optimera prestanda för transaktionsbearbetning, datainmatning, datainläsning och tillfälliga datascenarier. Den här artikeln innehåller en översikt över tekniken och beskriver användningsscenarier för In-Memory OLTP. Använd den här informationen för att avgöra om In-Memory OLTP är rätt för ditt program. Artikeln avslutas med ett exempel som visar In-Memory OLTP-objekt, referens till en perf-demo och referenser till resurser som du kan använda för nästa steg.

översikt över In-Memory OLTP

In-Memory OLTP kan ge stora prestandavinster för rätt arbetsbelastningar. Kunderna har sett upp till 30X prestanda i vissa fall, men hur mycket vinst du ser beror på arbetsbelastningen.

Var kommer den här prestandavinsten ifrån? I grund och botten In-Memory OLTP förbättrar prestandan för transaktionsbearbetning genom att göra dataåtkomst och transaktionskörning mer effektiva, och genom att ta bort lås- och låsspärrkonkurration mellan transaktioner som körs samtidigt. In-Memory OLTP är inte snabb eftersom det är minnesinternt. det är snabbt på grund av optimering kring minnesintern data. Algoritmer för datalagring, åtkomst och bearbetning har gjorts om från grunden för att dra nytta av de senaste förbättringarna inom minnesintern och databehandling med hög samtidighet.

Bara för att data lever i minnet betyder det inte att du förlorar dem när det uppstår ett fel. Som standard är alla transaktioner helt varaktiga, vilket innebär att du har samma hållbarhetsgarantier som du får för alla andra tabeller i SQL Server: som en del av transaktionsöverföringen skrivs alla ändringar till transaktionsloggen på disken. Om det uppstår ett fel när som helst efter att transaktionen checkas in finns dina data där när databasen är online igen. Dessutom fungerar In-Memory OLTP med alla funktioner för hög tillgänglighet och haveriberedskap i SQL Server, till exempel tillgänglighetsgrupper, redundansklusterinstanser, säkerhetskopiering/återställning och så vidare.

Om du vill använda In-Memory OLTP i databasen använder du en eller flera av följande typer av objekt:

  • Minnesoptimerade tabeller används för att lagra användardata. Du deklarerar att en tabell ska vara minnesoptimerad vid skapandetillfället.
  • Icke-varaktiga tabeller används för tillfälliga data, antingen för cachelagring eller för mellanliggande resultatuppsättningar (ersätter traditionella temporära tabeller). En icke-varaktig tabell är en minnesoptimerad tabell som deklareras med DURABILITY=SCHEMA_ONLY, vilket innebär att ändringar i dessa tabeller inte medför någon I/O. Detta undviker att använda logg-I/O-resurser i fall där hållbarhet inte är ett problem.
  • Minnesoptimerade tabelltyper används för tabellvärdesparametrar (TVP:er) och mellanliggande resultatuppsättningar i lagrade procedurer. Minnesoptimerade tabelltyper kan användas i stället för traditionella tabelltyper. Tabellvariabler och TVP:er som deklareras med en minnesoptimerad tabelltyp ärver fördelarna med icke-hållbara minnesoptimerade tabeller: effektiv dataåtkomst och ingen I/O.
  • Internt kompilerade T-SQL-moduler används för att ytterligare minska den tid det tar för en enskild transaktion genom att minska cpu-cyklerna som krävs för att bearbeta åtgärderna. Du deklarerar en Transact-SQL modul som ska kompileras internt vid skapandetillfället. För närvarande kan följande T-SQL-moduler kompileras internt: lagrade procedurer, utlösare och skalära användardefinierade funktioner.

In-Memory OLTP är inbyggt i SQL Server och SQL Database. Eftersom dessa objekt fungerar på ett liknande sätt som deras traditionella motsvarigheter kan du ofta få prestandafördelar samtidigt som du bara gör minimala ändringar i databasen och programmet. Dessutom kan du ha både minnesoptimerade och traditionella diskbaserade tabeller i samma databas och köra frågor mellan de två. Se exempelskriptet Transact-SQL för var och en av dessa typer av objekt senare i den här artikeln.

Användningsscenarier för In-Memory OLTP

In-Memory OLTP är inte en magisk snabbknapp och är inte lämplig för alla arbetsbelastningar. Minnesoptimerade tabeller minskar till exempel inte processoranvändningen om de flesta frågorna utför aggregeringar över stora dataintervall. Kolumnlagringsindex hjälper dig med det scenariot.

Försiktighet

Känt problem: För databaser med minnesoptimerade tabeller kan säkerhetskopiering av transaktionsloggar utan återställning och senare en återställning av transaktionsloggen med återställning resultera i en återställningsprocess som inte svarar. Det här problemet kan också påverka funktionen för loggleverans. För att undvika det här problemet kan SQL Server-instansen startas om innan återställningsprocessen initieras.

Här är en lista över scenarier och programmönster där vi har sett kunder lyckas med In-Memory OLTP.

Transaktionsbearbetning med högt dataflöde och låg latens

Det här är kärnscenariot som vi skapade In-Memory OLTP för: stöder stora volymer av transaktioner, med konsekvent låg svarstid för enskilda transaktioner.

Vanliga arbetsbelastningsscenarier är: handel med finansiella instrument, sportspel, mobilspel och annonsleverans. Ett annat vanligt mönster är en "katalog" som ofta läses och/eller uppdateras. Ett exempel är när du har stora filer, var och en distribuerad över flera klusternoder, och du katalogiserar platsen för varje shard för varje fil i en minnesoptimerad tabell.

Implementeringöverväganden

Använd minnesoptimerade tabeller för dina kärntransaktionstabeller, dvs. tabellerna med de mest prestandakritiska transaktionerna. Använd internt kompilerade lagrade procedurer för att optimera körningen av logiken som är associerad med affärstransaktionen. Ju mer av logiken du kan överföra till lagrade procedurer i databasen, desto mer nytta ser du av In-Memory OLTP.

Så här kommer du igång i ett befintligt program:

  1. Använd rapporten för transaktionsprestandaanalys för att identifiera de objekt som du vill migrera.
  2. Använd Memory Optimization Advisor och Native Compilation Advisor för att hjälpa till med migrering.

Datainmatning, inklusive IoT (Sakernas Internet)

In-Memory OLTP är bra på att mata in stora mängder data från många olika källor samtidigt. Och det är ofta fördelaktigt att mata in data i en SQL Server-databas jämfört med andra mål, eftersom SQL Server gör att köra frågor mot data snabbt och gör att du kan få insikter i realtid.

Vanliga programmönster är:

  • Mata in sensoravläsningar och händelser, samt tillåta meddelanden samt historisk analys.
  • Hantera batchuppdateringar, även från flera källor, samtidigt som påverkan på den samtidiga läsarbetsbelastningen minimeras.

Implementeringöverväganden

Använd en minnesoptimerad tabell för datainmatning. Om inmatningen huvudsakligen består av infogningar (i stället för uppdateringar) och In-Memory OLTP-lagringsfotavtryck för data är ett problem, antingen

  • Använd ett jobb för att regelbundet batchavlasta data till en diskbaserad tabell med ett grupperat columnstore-index, med hjälp av ett jobb som gör ; INSERT INTO <disk-based table> SELECT FROM <memory-optimized table>eller
  • Använd en tidsoptimerad minnesoptimerad tabell för att hantera historiska data – i det här läget hanteras historiska data på disken och dataförflyttning av systemet.

SQL Server-exempellagringsplatsen innehåller ett smart grid-program som använder en tidsoptimerad minnesoptimerad tabell, en minnesoptimerad tabelltyp och en inbyggt kompilerad lagrad procedur för att påskynda datainmatningen, samtidigt som du hanterar In-Memory OLTP-lagringsfotavtryck för sensordata:

Cachelagring och sessionstillstånd

Den In-Memory OLTP-tekniken gör databasmotorn i SQL Server- eller Azure SQL-databaser till en attraktiv plattform för att upprätthålla sessionstillstånd (till exempel för ett ASP.NET-program) och för cachelagring.

ASP.NET sessionstillstånd är ett lyckat användningsfall för In-Memory OLTP. Med SQL Server var en kund på väg att uppnå 1,2 miljoner begäranden per sekund. Under tiden har de börjat använda In-Memory OLTP för cachelagringsbehoven för alla mellannivåprogram i företaget. Information: Hur bwin använder SQL Server 2016 (13.x) In-Memory OLTP för att uppnå oöverträffad prestanda och skalning

Implementeringöverväganden

Du kan använda icke-hållbara minnesoptimerade tabeller som ett enkelt nyckelvärdeslager genom att lagra en BLOB i en kolumn med varbinary(max). Du kan också implementera en halvstrukturerad cache med JSON-stöd i SQL Server och SQL Database. Slutligen kan du skapa en fullständig relationscache via icke-varaktiga tabeller med ett fullständigt relationsschema, inklusive olika datatyper och begränsningar.

Kom igång med minnesoptimering ASP.NET sessionstillstånd med hjälp av skripten som publicerats på GitHub för att ersätta de objekt som skapats av den inbyggda SQL Server-sessionstillståndsprovidern: aspnet-session-state

Kundfallsstudie

tempdb-objektbyte

Använd icke-varaktiga tabeller och minnesoptimerade tabelltyper för att ersätta dina traditionella tempdb baserade strukturer, till exempel temporära tabeller, tabellvariabler och tabellvärdesparametrar (TVP:er).

Minnesoptimerade tabellvariabler och icke-hållbara tabeller minskar vanligtvis processorkraften och tar bort logg-I/O helt jämfört med traditionella tabellvariabler och #temp tabell.

Implementeringöverväganden

Så här kommer du igång: Förbättra prestanda för temporär tabell och tabellvariabel med hjälp av minnesoptimering.

Kundfallsstudie

ETL (Extrahera transformeringsbelastning)

ETL-arbetsflöden omfattar ofta databelastning i en mellanlagringstabell, omvandlingar av data och inläsning i de sista tabellerna.

Använd icke-varaktiga minnesoptimerade tabeller för mellanlagring av data. De tar bort all I/O helt och gör dataåtkomsten mer effektiv.

Implementeringöverväganden

Om du utför transformeringar i mellanlagringstabellen som en del av arbetsflödet kan du använda inbyggda kompilerade lagrade procedurer för att påskynda dessa transformeringar. Om du kan utföra dessa transformeringar parallellt får du ytterligare skalningsfördelar med minnesoptimeringen.

Exempelskript

Innan du kan börja använda In-Memory OLTP måste du skapa en MEMORY_OPTIMIZED_DATA filgrupp. Dessutom rekommenderar vi att du använder databaskompatibilitetsnivå 130 (eller senare) och anger databasalternativet MEMORY_OPTIMIZED_ELEVATE_TO_SNAPSHOT till PÅ.

Du kan använda skriptet på följande plats för att skapa filgruppen i standarddatamappen och konfigurera de rekommenderade inställningarna:

Följande exempelskript illustrerar In-Memory OLTP-objekt som du kan skapa i databasen.

Börja med att konfigurera databasen för In-Memory OLTP.

-- configure recommended DB option
ALTER DATABASE CURRENT SET MEMORY_OPTIMIZED_ELEVATE_TO_SNAPSHOT=ON;
GO

Du kan skapa tabeller med olika hållbarhet:

-- memory-optimized table
CREATE TABLE dbo.table1
( c1 INT IDENTITY PRIMARY KEY NONCLUSTERED,
  c2 NVARCHAR(MAX))
WITH (MEMORY_OPTIMIZED=ON);
GO
-- non-durable table
CREATE TABLE dbo.temp_table1
( c1 INT IDENTITY PRIMARY KEY NONCLUSTERED,
  c2 NVARCHAR(MAX))
WITH (MEMORY_OPTIMIZED=ON,
      DURABILITY=SCHEMA_ONLY);
GO

Du kan skapa en tabelltyp som en minnesintern tabell.

-- memory-optimized table type
CREATE TYPE dbo.tt_table1 AS TABLE
( c1 INT IDENTITY,
  c2 NVARCHAR(MAX),
  is_transient BIT NOT NULL DEFAULT (0),
  INDEX ix_c1 HASH (c1) WITH (BUCKET_COUNT=1024))
WITH (MEMORY_OPTIMIZED=ON);
GO

Du kan skapa en internt kompilerad lagrad procedur. Mer information finns i Anropa internt kompilerade lagrade procedurer från dataåtkomstprogram.

-- natively compiled stored procedure
CREATE PROCEDURE dbo.usp_ingest_table1
  @table1 dbo.tt_table1 READONLY
WITH NATIVE_COMPILATION, SCHEMABINDING
AS
BEGIN ATOMIC
    WITH (TRANSACTION ISOLATION LEVEL=SNAPSHOT,
          LANGUAGE=N'us_english')

  DECLARE @i INT = 1

  WHILE @i > 0
  BEGIN
    INSERT dbo.table1
    SELECT c2
    FROM @table1
    WHERE c1 = @i AND is_transient=0

    IF @@ROWCOUNT > 0
      SET @i += 1
    ELSE
    BEGIN
      INSERT dbo.temp_table1
      SELECT c2
      FROM @table1
      WHERE c1 = @i AND is_transient=1

      IF @@ROWCOUNT > 0
        SET @i += 1
      ELSE
        SET @i = 0
    END
  END

END
GO
-- sample execution of the proc
DECLARE @table1 dbo.tt_table1;
INSERT @table1 (c2, is_transient) VALUES (N'sample durable', 0);
INSERT @table1 (c2, is_transient) VALUES (N'sample non-durable', 1);
EXECUTE dbo.usp_ingest_table1 @table1=@table1;
SELECT c1, c2 from dbo.table1;
SELECT c1, c2 from dbo.temp_table1;
GO

Relaterat innehåll