Udostępnij za pomocą

In-Memory scenariuszy użycia i przeglądu OLTP

Dotyczy:SQL ServerAzure SQL DatabaseAzure SQL Managed Instance

In-Memory OLTP jest pierwszą technologią dostępną w programach SQL Server i SQL Database w celu optymalizacji wydajności przetwarzania transakcji, pozyskiwania danych, ładowania danych i przejściowych scenariuszy danych. Ten artykuł zawiera omówienie technologii i opis scenariuszy użycia dla In-Memory OLTP. Użyj tych informacji, aby określić, czy In-Memory OLTP jest odpowiednia dla twojej aplikacji. Artykuł zawiera przykład pokazujący In-Memory obiektów OLTP, odwołanie do pokazu wydajności i odwołania do zasobów, których można użyć do następnych kroków.

Omówienie usługi OLTP In-Memory

In-Memory OLTP może zapewnić znaczne wzrosty wydajności dla odpowiednich obciążeń. Chociaż w niektórych przypadkach klienci zauważyli do 30-krotny wzrost wydajności, to jak duży zysk jest zależny od obciążenia.

Skąd wynika ta wydajność? W istocie In-Memory OLTP poprawia wydajność przetwarzania transakcji poprzez zwiększenie wydajności dostępu do danych i wykonywania transakcji, a także usunięcie rywalizacji o blokadę i zatrzaśnięcie między współbieżnie wykonujących transakcje. In-Memory OLTP nie jest szybka, ponieważ jest w pamięci; jest to szybkie ze względu na optymalizację danych w pamięci. Algorytmy magazynowania, dostępu i przetwarzania danych zostały przeprojektowane od podstaw, aby skorzystać z najnowszych ulepszeń w pamięci i obliczeń o wysokiej współbieżności.

Teraz tylko dlatego, że dane znajdują się w pamięci, nie oznaczają utraty ich w przypadku awarii. Domyślnie wszystkie transakcje są w pełni trwałe, co oznacza, że masz takie same gwarancje trwałości, jakie otrzymujesz dla każdej innej tabeli w programie SQL Server: w ramach zatwierdzenia transakcji wszystkie zmiany są zapisywane w dzienniku transakcji na dysku. Jeśli wystąpi błąd w dowolnym momencie po zatwierdzeniu transakcji, dane są tam, gdy baza danych wróci do trybu online. Ponadto In-Memory OLTP współdziała ze wszystkimi funkcjami wysokiej dostępności i odzyskiwania po awarii programu SQL Server, takimi jak grupy dostępności, wystąpienia klastra trybu failover, tworzenie kopii zapasowej/przywracanie itd.

Aby użyć In-Memory OLTP w bazie danych, należy użyć co najmniej jednego z następujących typów obiektów:

  • Tabele zoptymalizowane pod kątem pamięci są używane do przechowywania danych użytkownika. W czasie tworzenia należy zadeklarować tabelę zoptymalizowaną pod kątem pamięci.
  • Tabele nietrwałe są używane w przypadku danych przejściowych w przypadku buforowania lub zestawu wyników pośrednich (zastępując tradycyjne tabele tymczasowe). Tabela nietrwała jest tabelą zoptymalizowaną pod kątem pamięci zadeklarowaną przy użyciu właściwości DURABILITY=SCHEMA_ONLY, co oznacza, że zmiany w tych tabelach nie powodują żadnych operacji we/wy. Pozwala to uniknąć korzystania z zasobów we/wy dziennika w przypadkach, gdy trwałość nie jest problemem.
  • Typy tabel zoptymalizowane pod kątem pamięci są używane dla parametrów o wartości tabeli (TVP) i zestawów wyników pośrednich w procedurach składowanych. Typy tabel zoptymalizowane pod kątem pamięci mogą być używane zamiast tradycyjnych typów tabel. Zmienne tabeli i programy TVP zadeklarowane przy użyciu typu tabeli zoptymalizowanego pod kątem pamięci dziedziczą zalety tabel zoptymalizowanych pod kątem pamięci nietrwałych: wydajny dostęp do danych i brak operacji we/wy.
  • Natywnie skompilowane moduły języka T-SQL są używane do dalszego skrócenia czasu potrzebnego na poszczególne transakcje przez zmniejszenie liczby cykli procesora CPU wymaganych do przetwarzania operacji. Deklarujesz moduł Transact-SQL, który zostanie skompilowany natywnie w czasie tworzenia. W tej chwili następujące moduły języka T-SQL można natywnie skompilować: procedury składowane, wyzwalacze i funkcje zdefiniowane przez użytkownika skalarne.

In-Memory OLTP jest wbudowany w program SQL Server i usługę SQL Database. Ponieważ te obiekty zachowują się w podobny sposób do tradycyjnych odpowiedników, często można uzyskać korzyści z wydajności, wprowadzając tylko minimalne zmiany w bazie danych i aplikacji. Ponadto można mieć zarówno tabele zoptymalizowane pod kątem pamięci, jak i tradycyjne tabele oparte na dyskach w tej samej bazie danych i uruchamiać zapytania w obu tych tabelach. Zobacz przykładowy skrypt Transact-SQL dla każdego z tych typów obiektów w dalszej części tego artykułu.

Scenariusze użycia dla In-Memory OLTP

In-Memory OLTP nie jest magicznym przyciskiem i nie jest odpowiedni dla wszystkich obciążeń. Na przykład tabele zoptymalizowane pod kątem pamięci nie obniżają użycia procesora CPU, jeśli większość zapytań wykonuje agregację w dużych zakresach danych. Indeksy magazynu kolumn pomagają w tym scenariuszu.

Ostrzeżenie

Znany problem: W przypadku baz danych z tabelami zoptymalizowanymi pod kątem pamięci wykonywanie kopii zapasowej dziennika transakcyjnego bez odzyskiwania, a później wykonywanie przywracania dziennika transakcji z odzyskiwaniem może spowodować brak odpowiedzi procesu przywracania bazy danych. Ten problem może również mieć wpływ na funkcjonalność wysyłania dziennika. Aby obejść ten problem, wystąpienie programu SQL Server można uruchomić ponownie przed zainicjowanie procesu przywracania.

Oto lista scenariuszy i wzorców aplikacji, w których zaobserwowaliśmy, że klienci odniosą sukces w In-Memory OLTP.

Przetwarzanie transakcji o wysokiej przepływności i małych opóźnieniach

Jest to podstawowy scenariusz, dla którego utworzyliśmy In-Memory OLTP: obsługuje duże ilości transakcji z spójnym małym opóźnieniem dla poszczególnych transakcji.

Typowe scenariusze obciążeń to: handel instrumentami finansowymi, zakładami sportowymi, grami mobilnymi i dostarczaniem reklam. Innym typowym wzorcem jest "wykaz", który jest często odczytywany i/lub aktualizowany. Jednym z przykładów jest sytuacja, w której masz duże pliki, z których każda jest dystrybuowana przez wiele węzłów klastra, i katalogujesz lokalizację każdego fragmentu każdego pliku w tabeli zoptymalizowanej pod kątem pamięci.

Uwagi dotyczące implementacji

Użyj tabel zoptymalizowanych pod kątem pamięci dla podstawowych tabel transakcji, czyli tabel z najbardziej krytycznymi dla wydajności transakcji. Użyj natywnie skompilowanych procedur składowanych, aby zoptymalizować wykonywanie logiki skojarzonej z transakcją biznesową. Więcej logiki, którą można wypchnąć do procedur składowanych w bazie danych, tym większa korzyść wynika z In-Memory OLTP.

Aby rozpocząć pracę w istniejącej aplikacji:

  1. Użyj raportu analizy wydajności transakcji , aby zidentyfikować obiekty, które chcesz migrować.
  2. Użyj doradcy optymalizacji pamięci i natywnego doradcy kompilacji , aby ułatwić migrację.

Pozyskiwanie danych, w tym IoT (Internet rzeczy)

In-Memory OLTP dobrze jest pozyskiwać duże ilości danych z wielu różnych źródeł w tym samym czasie. Często korzystne jest pozyskiwanie danych do bazy danych programu SQL Server w porównaniu z innymi miejscami docelowymi, ponieważ program SQL Server szybko uruchamia zapytania względem danych i umożliwia uzyskiwanie szczegółowych informacji w czasie rzeczywistym.

Typowe wzorce aplikacji to:

  • Pozyskiwanie odczytów czujników i zdarzeń oraz zezwalanie na powiadomienia oraz analizę historyczną.
  • Zarządzanie aktualizacjami wsadowymi, nawet z wielu źródeł, jednocześnie minimalizując wpływ na współbieżne obciążenie odczytu.

Uwagi dotyczące implementacji

Użyj tabeli zoptymalizowanej pod kątem pamięci na potrzeby pozyskiwania danych. Jeśli pozyskiwanie składa się głównie z wstawiania (a nie aktualizacji) i In-Memory ślad magazynu OLTP danych jest problemem albo

Repozytorium przykładów programu SQL Server zawiera aplikację inteligentnej siatki korzystającą z tabeli zoptymalizowanej pod kątem pamięci czasowej, typu tabeli zoptymalizowanej pod kątem pamięci i natywnie skompilowanej procedury składowanej w celu przyspieszenia pozyskiwania danych, a jednocześnie zarządzania In-Memory śladem magazynu OLTP danych czujnika:

Buforowanie i stan sesji

Technologia In-Memory OLTP sprawia, że aparat bazy danych w bazach danych SQL Server lub Azure SQL Database jest atrakcyjną platformą do utrzymania stanu sesji (na przykład dla aplikacji ASP.NET) i buforowania.

ASP.NET stan sesji to pomyślny przypadek użycia In-Memory OLTP. W przypadku programu SQL Server jeden klient miał osiągnąć 1,2 miliona żądań na sekundę. W międzyczasie zaczęli używać In-Memory OLTP na potrzeby buforowania wszystkich aplikacji warstwy średniej w przedsiębiorstwie. Szczegóły: Jak bwin używa programu SQL Server 2016 (13.x) In-Memory OLTP w celu osiągnięcia bezprecedensowej wydajności i skali

Uwagi dotyczące implementacji

Tabele zoptymalizowane pod kątem pamięci nietrwałe można używać jako prostego magazynu wartości klucz-wartość, przechowując obiekt BLOB w kolumnie varbinary(max). Alternatywnie można zaimplementować częściowo ustrukturyzowaną pamięć podręczną z obsługą formatu JSON w programach SQL Server i SQL Database. Na koniec można utworzyć pełną pamięć podręczną relacyjną za pomocą tabel nietrwałych z pełnym schematem relacyjnym, w tym różnymi typami danych i ograniczeniami.

Wprowadzenie do optymalizacji pamięci ASP.NET stanu sesji przy użyciu skryptów opublikowanych w usłudze GitHub w celu zastąpienia obiektów utworzonych przez wbudowanego dostawcę stanu sesji programu SQL Server: aspnet-session-state

Analiza przypadku klienta

zastępowanie obiektu tempdb

Użyj nietrwałych tabel i typów tabel zoptymalizowanych pod kątem pamięci, aby zastąpić tradycyjne tempdb struktury, takie jak tabele tymczasowe, zmienne tabeli i parametry wartości tabeli (TVP).

Zmienne tabeli zoptymalizowane pod kątem pamięci i tabele nietrwałe zwykle zmniejszają użycie procesora CPU i całkowicie usuwają operacje we/wy dziennika w porównaniu z tradycyjnymi zmiennymi tabeli i tabelą #temp.

Uwagi dotyczące implementacji

Aby rozpocząć: poprawa wydajności tabeli tymczasowej i zmiennej tabeli przy użyciu optymalizacji pamięci.

Analiza przypadku klienta

ETL (Wyodrębnianie obciążenia transformacji)

Przepływy pracy ETL często obejmują ładowanie danych do tabeli przejściowej, przekształcenia danych i ładowanie ich do końcowych tabel.

Użyj nietrwałych tabel zoptymalizowanych pod kątem pamięci na potrzeby przemieszczania danych. Całkowicie usuwają wszystkie we/wy i zapewniają wydajniejszy dostęp do danych.

Uwagi dotyczące implementacji

Jeśli wykonasz przekształcenia w tabeli przejściowej w ramach przepływu pracy, możesz użyć natywnie skompilowanych procedur składowanych, aby przyspieszyć te przekształcenia. Jeśli te przekształcenia można wykonać równolegle, możesz uzyskać dodatkowe korzyści ze skalowania z optymalizacji pamięci.

Przykładowy skrypt

Przed rozpoczęciem korzystania z In-Memory OLTP należy utworzyć grupę plików MEMORY_OPTIMIZED_DATA. Ponadto zalecamy użycie poziomu zgodności bazy danych 130 (lub nowszego) i ustawienie opcji bazy danych MEMORY_OPTIMIZED_ELEVATE_TO_SNAPSHOT na WARTOŚĆ WŁĄCZONE.

Skrypt można użyć w następującej lokalizacji, aby utworzyć grupę plików w domyślnym folderze danych i skonfigurować zalecane ustawienia:

Poniższy przykładowy skrypt ilustruje In-Memory obiektów OLTP, które można utworzyć w bazie danych.

Najpierw zacznij od skonfigurowania bazy danych dla In-Memory OLTP.

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

Tabele można tworzyć z różnymi trwałościami:

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

Możesz utworzyć typ tabeli jako tabelę w pamięci.

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

Można utworzyć natywnie skompilowaną procedurę składowaną. Aby uzyskać więcej informacji, zobacz Wywoływanie natywnie skompilowanych procedur składowanych z aplikacji dostępu do danych.

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

Treści powiązane

  • Last updated on