Omówienie technologii OLTP w pamięci i scenariusze użycia

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ł kończy się przykładem pokazującym obiekty In-Memory OLTP, odniesieniem do demonstracji wydajności oraz odwołaniami do zasobów, z których można skorzystać w kolejnych krokach.

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, usprawniając dostęp do danych i wykonywanie transakcji oraz eliminując rywalizację o blokady i zatrzaski między współbieżnie wykonywanymi transakcjami. In-Memory OLTP nie jest szybkie dlatego, że działa w pamięci; jest szybkie dzięki optymalizacji przetwarzania 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 funkcja In-Memory OLTP współpracuje ze wszystkimi funkcjami wysokiej dostępności i odzyskiwania po awarii w programie SQL Server, takimi jak grupy dostępności, wystąpienia klastra przełączania awaryjnego, tworzenie kopii zapasowych i 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. Podczas tworzenia deklarujesz, że tabela ma być zoptymalizowana pod kątem pamięci.
  • Tabele nietrwałe służą do obsługi danych przejściowych, zarówno do buforowania, jak i do przechowywania pośrednich zestawów wyników (zastępując tradycyjne tabele tymczasowe). Tabela nietrwała to tabela zoptymalizowana pod kątem pamięci, zadeklarowana z atrybutem DURABILITY=SCHEMA_ONLY, co oznacza, że zmiany w takiej tabeli nie wiążą się z żadnymi operacjami we/wy. Pozwala to uniknąć zużywania zasobów operacji wejścia/wyjścia dziennika w przypadkach, gdy trwałość nie ma znaczenia.
  • 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 tabelaryczne i parametry o wartościach tabelarycznych (TVP) zadeklarowane z użyciem typu tabeli zoptymalizowanego pod kątem pamięci dziedziczą zalety nietrwałych tabel zoptymalizowanych pod kątem pamięci: 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 rozwiązaniem, które wszystko przyspiesza, i nie nadaje się do wszystkich obciążeń roboczych. 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 kolumnowe 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, można ponownie uruchomić instancję programu SQL Server przed rozpoczęciem 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ą. Im więcej logiki można przenieść do procedur składowanych w bazie danych, tym większe korzyści przynosi 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 radzi sobie z przyjmowaniem dużych ilości danych z wielu różnych źródeł jednocześnie. 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:

  • Pobieranie odczytów i zdarzeń z czujników oraz umożliwianie powiadomień i analizy danych historycznych.
  • Zarządzanie aktualizacjami wsadowymi, nawet z wielu źródeł, przy jednoczesnym minimalizowaniu wpływu na współbieżne obciążenie operacjami odczytu.

Uwagi dotyczące implementacji

Użyj tabeli zoptymalizowanej pod kątem pamięci na potrzeby pozyskiwania danych. Jeśli ładowanie danych składa się głównie z operacji INSERT (a nie aktualizacji), a rozmiar pamięci zajmowanej przez dane w magazynie In-Memory OLTP stanowi problem, to either

Repozytorium przykładów SQL Server zawiera aplikację inteligentnej sieci energetycznej, która wykorzystuje czasową tabelę zoptymalizowaną pod kątem pamięci, typ tabeli zoptymalizowanej pod kątem pamięci oraz natywnie kompilowaną procedurę składowaną, aby przyspieszyć pozyskiwanie danych, a jednocześnie zarządzać wykorzystaniem magazynu In-Memory OLTP przez dane z czujników:

Buforowanie i stan sesji

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

Stan sesji ASP.NET to udany przykład zastosowania technologii 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

Nietrwałych tabel zoptymalizowanych pod kątem pamięci można używać jako prostego magazynu typu klucz-wartość, przechowując obiekt BLOB w kolumnie typu 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.

Rozpocznij pracę ze stanem sesji ASP.NET zoptymalizowanym pod kątem pamięci, używając skryptów opublikowanych w serwisie GitHub w celu zastąpienia obiektów utworzonych przez wbudowanego dostawcę stanu sesji 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 tabelaryczne zoptymalizowane pod kątem pamięci oraz tabele nietrwałe zwykle zmniejszają obciążenie procesora i całkowicie eliminują operacje wejścia/wyjścia dziennika transakcji w porównaniu z tradycyjnymi zmiennymi tabelarycznymi i tabelami #temp.

Uwagi dotyczące implementacji

Na początek: Poprawa wydajności tabeli tymczasowej i zmiennej tabelowej za pomocą optymalizacji pamięci.

Analiza przypadku klienta

ETL (Ekstrakcja, transformacja, ładowanie)

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 eliminują wszystkie operacje wejścia/wyjścia i sprawiają, że dostęp do danych jest wydajniejszy.

Uwagi dotyczące implementacji

Jeśli przeprowadzasz 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 wyższego) oraz ustawienie opcji bazy danych MEMORY_OPTIMIZED_ELEVATE_TO_SNAPSHOT na ON.

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 obiekty In-Memory 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