Wprowadzenie do tabel Memory-Optimized

Dotyczy:SQL ServerAzure SQL DatabaseAzure SQL Managed Instance

Tabele zoptymalizowane pod kątem pamięci są tworzone przy użyciu polecenia CREATE TABLE (Transact-SQL).

Tabele zoptymalizowane pod kątem pamięci są domyślnie w pełni trwałe, a transakcje na takich tabelach, podobnie jak transakcje na (tradycyjnych) tabelach opartych na dyskach, są w pełni niepodzielne, spójne, izolowane i trwałe (ACID). Tabele zoptymalizowane pod kątem pamięci i natywnie skompilowane procedury składowane obsługują tylko podzestaw funkcji Transact-SQL.

Począwszy od programu SQL Server 2016 i usługi Azure SQL Database, nie ma żadnych ograniczeń dotyczących sortowania ani stron kodu specyficznych dla In-Memory OLTP.

Podstawowym magazynem dla tabel zoptymalizowanych pod kątem pamięci jest pamięć główna. Wiersze w tabeli są odczytywane i zapisywane w pamięci. Druga kopia danych tabeli jest przechowywana na dysku, ale tylko w celach trwałości. Aby uzyskać więcej informacji na temat tabel trwałych, zobacz Tworzenie magazynu i zarządzanie nim dla obiektów Memory-Optimized . Dane w tabelach zoptymalizowanych pod kątem pamięci są odczytywane tylko z dysku podczas odzyskiwania bazy danych (na przykład po ponownym uruchomieniu serwera).

W celu zwiększenia wydajności In-Memory OLTP obsługuje trwałe tabele z opóźnioną trwałością transakcji. Opóźnione trwałe transakcje są zapisywane na dysku wkrótce po zatwierdzeniu transakcji i powrocie kontroli do klienta. W zamian za zwiększoną wydajność zatwierdzone transakcje, które nie są utrwalone na dysku, zostaną utracone w awarii serwera lub przełączeniu w tryb failover.

Oprócz domyślnych tabel zoptymalizowanych pod kątem pamięci program SQL Server obsługuje również nietrwałe tabele zoptymalizowane pod kątem pamięci, które nie są rejestrowane, a ich dane nie są utrwalane na dysku. Oznacza to, że transakcje w tych tabelach nie wymagają żadnych operacji we/wy dysku, ale dane zostaną utracone, jeśli wystąpi awaria serwera lub tryb failover.

In-Memory OLTP jest zintegrowana z programem SQL Server, aby zapewnić bezproblemowe środowisko we wszystkich obszarach, takich jak programowanie, wdrażanie, możliwości zarządzania i możliwości obsługi. Baza danych może zawierać obiekty w pamięci, a także obiekty oparte na dyskach.

Wiersze w tabelach zoptymalizowanych pod kątem pamięci są wersjonowane. Oznacza to, że każdy wiersz w tabeli może zawierać wiele wersji. Wszystkie wersje wierszy są przechowywane w tej samej strukturze danych tabeli. Przechowywanie wersji wierszy służy do zezwalania na współbieżne operacje odczytu i zapisu w tym samym wierszu. Aby uzyskać więcej informacji o równoczesnych odczytach i zapisach w tym samym wierszu, zobacz Transakcje z tabelami Memory-Optimized.

Na poniższej ilustracji przedstawiono wiele wersji. Na rysunku przedstawiono tabelę z trzema wierszami, a każdy wiersz ma różne wersje.

Tabela zawiera trzy wiersze: r1, r2 i r3. R1 ma trzy wersje, r2 ma dwie wersje, a r3 ma cztery wersje. Różne wersje tego samego wiersza nie muszą zajmować kolejnych lokalizacji pamięci. Różne wersje wierszy mogą być rozproszone w całej strukturze danych tabeli.

Struktura danych tabeli zoptymalizowana pod kątem pamięci może być postrzegana jako kolekcja wersji wierszy. Wiersze w tabelach dyskowych są uporządkowane według stron i zakresów, a poszczególne wiersze są adresowane za pomocą numeru strony i przesunięcia strony. Z kolei wersje wierszy w tabelach zoptymalizowanych pod kątem pamięci są adresowane przy użyciu 8-bajtowych wskaźników pamięci.

Dostęp do danych w tabelach zoptymalizowanych pod kątem pamięci można uzyskać na dwa sposoby:

• Za pomocą procedur przechowywanych skompilowanych natywnie.

• Za pomocą interpretowanego języka Transact-SQL poza natywnie skompilowaną procedurą składowaną. Te instrukcje Transact-SQL mogą znajdować się wewnątrz interpretowanych procedur składowanych lub mogą być instrukcjami ad hoc Transact-SQL.

Uzyskiwanie dostępu do danych w tabelach Memory-Optimized

Dostęp do tabel zoptymalizowanych pod kątem pamięci można uzyskać najwydajniej z natywnie skompilowanych procedur składowanych (natywnie skompilowanych procedur składowanych). Dostęp do tabel zoptymalizowanych pod kątem pamięci można również uzyskać za pomocą (tradycyjnego) interpretowanego języka Transact-SQL. Transact-SQL interpretowane odnosi się do uzyskiwania dostępu do tabel zoptymalizowanych pod kątem pamięci bez natywnie skompilowanej procedury składowanej. Niektóre przykłady interpretowanego dostępu Transact-SQL obejmują dostęp do tabeli zoptymalizowanej pod kątem pamięci z wyzwalacza DML, ad hoc Transact-SQL wsadowego, widoku i funkcji wartości tabeli.

Poniższa tabela zawiera podsumowanie natywnego i interpretowanego dostępu do Transact-SQL dla różnych obiektów.

Funkcja	Dostęp przy użyciu natywnie skompilowanej procedury składowanej	Interpretowany dostęp Transact-SQL	Dostęp CLR
Tabela zoptymalizowana pod kątem pamięci	Tak	Tak	Nr1
Typ tabeli zoptymalizowany pod kątem pamięci	Tak	Tak	Nie.
Natywnie skompilowana procedura składowana	Zagnieżdżanie natywnie skompilowanych procedur składowanych jest teraz obsługiwane. Składnię EXECUTE można użyć wewnątrz procedur składowanych, o ile procedura, do której odwołuje się odwołanie, jest również natywnie skompilowana.	Tak	Nie*

¹Nie można uzyskać dostępu do tabeli zoptymalizowanej pod kątem pamięci ani natywnie skompilowanej procedury składowanej z połączenia kontekstu (połączenia z programu SQL Server podczas wykonywania modułu CLR). Można jednak utworzyć i otworzyć inne połączenie, z którego można uzyskać dostęp do tabel zoptymalizowanych pod kątem pamięci i natywnie skompilowanych procedur składowanych.

Poufne dane w tabelach zoptymalizowanych pod kątem pamięci mogą być chronione przy użyciu funkcji Always Encrypted. Obowiązują następujące ograniczenia:

• W przypadku używania funkcji Always Encrypted z bezpiecznymi enklawami użycie kluczy z obsługą enklawy dla kolumn w tabelach zoptymalizowanych pod kątem pamięci nie jest obsługiwane. Oznacza to, że nie można używać szyfrowania w miejscu, a początkowe szyfrowanie jest wykonywane na kliencie.
• Funkcja Always Encrypted nie jest obsługiwana dla żadnej kolumny w tabeli zoptymalizowanej pod kątem pamięci, gdy tabela jest przywoływana w natywnie skompilowanym module.

Wydajność i skalowalność   

Następujące czynniki wpływają na wzrost wydajności, które można osiągnąć za pomocą In-Memory OLTP:

Komunikacja: Aplikacja korzystająca z wielu krótkich wywołań procedur składowanych może zobaczyć mniejszy wzrost wydajności w porównaniu z aplikacją z mniejszą liczbą wywołań i większą funkcjonalnością zaimplementowaną w każdej procedurze składowanej.

Transact-SQL Wykonywanie: In-Memory OLTP osiąga najlepszą wydajność podczas korzystania z natywnie skompilowanych procedur składowanych, a nie interpretowanych procedur składowanych lub wykonywania zapytań. Dostęp do tabel zoptymalizowanych pod kątem pamięci może być korzystny dla takich procedur składowanych.

Skanowanie zakresu a wyszukiwanie punktów: Indeksy nieklastrowane zoptymalizowane pod kątem pamięci obsługują skanowania zakresów i uporządkowane skanowania. W przypadku wyszukiwania punktów indeksy skrótów zoptymalizowane pod kątem pamięci mają lepszą wydajność niż indeksy nieklastrowane zoptymalizowane pod kątem pamięci. Indeksy nieklastrowane zoptymalizowane pod kątem pamięci mają lepszą wydajność niż indeksy oparte na dyskach.

• Począwszy od programu SQL Server 2016, plan zapytania dla tabeli zoptymalizowanej pod kątem pamięci może skanować tabelę równolegle. Zwiększa to wydajność zapytań analitycznych.
  • Również indeksy skrótów w programie SQL Server 2016 stały się możliwe do skanowania równolegle.
  • Indeksy nieklastrowane stały się również skanowane równolegle w programie SQL Server 2016.

Operacje indeksowania: Operacje indeksowania nie są rejestrowane i istnieją tylko w pamięci.

Współbieżność: Aplikacje, których wydajność jest zależna od współbieżności na poziomie silnika, takie jak konkurencja zasuwkowa lub blokowanie, znacznie się poprawiają, gdy aplikacja przechodzi do In-Memory OLTP.

W poniższej tabeli wymieniono problemy z wydajnością i skalowalnością, które często występują w relacyjnych bazach danych oraz o tym, jak In-Memory OLTP może poprawić wydajność.

Problematyka	In-Memory wpływ systemu OLTP
Wydajność Wysokie użycie zasobów (procesora CPU, operacji we/wy, sieci lub pamięci).	Procesor Natywnie skompilowane procedury składowane mogą znacznie obniżyć użycie procesora CPU, ponieważ wymagają one mniejszej liczby instrukcji do wykonania instrukcji Transact-SQL w porównaniu do interpretowanych procedur składowanych. In-Memory OLTP może pomóc zmniejszyć nakłady na sprzęt przy obciążeniach skalowanych poziomo, ponieważ jeden serwer może potencjalnie osiągnąć wydajność równą wielu serwerom. Wejście/Wyjście Jeśli napotkasz wąskie gardło I/O przy przetwarzaniu danych lub stron indeksowych, In-Memory OLTP może zredukować to wąskie gardło. Ponadto tworzenie punktów kontrolnych In-Memory obiektów OLTP jest ciągłe i nie prowadzi do nagłego wzrostu liczby operacji I/O. Jeśli jednak zestaw roboczy tabel o krytycznym znaczeniu dla wydajności nie mieści się w pamięci, In-Memory olTP nie ma zastosowania, ponieważ wymaga, aby dane miały miejsce w pamięci. Jeśli wystąpi wąskie gardło we/wy w rejestrowaniu, In-Memory OLTP może zmniejszyć to wąskie gardło, ponieważ rejestruje mniej danych. Jeśli co najmniej jedna tabela zoptymalizowana pod kątem pamięci jest skonfigurowana jako tabele nietrwałe, można wyeliminować rejestrowanie danych. Pamięć In-Memory OLTP nie oferuje żadnych korzyści z wydajności. In-Memory OLTP może wywierać dodatkową presję na pamięć, ponieważ obiekty muszą być rezydentami pamięci. Sieć In-Memory OLTP nie oferuje żadnych korzyści z wydajności. Dane muszą być przekazywane z warstwy danych do warstwy aplikacji.
Skalowalność Większość problemów ze skalowaniem w aplikacjach programu SQL Server jest spowodowana problemami współbieżności, takimi jak rywalizacja w blokadach, zatrzaskach i spinlockach.	Zawody o blokadę zapadki Typowy scenariusz polega na rywalizacji na ostatniej stronie indeksu podczas jednoczesnego wstawiania wierszy w porządku kluczy. Ponieważ In-Memory OLTP nie wymaga zatrzasków przy dostępie do danych, problemy ze skalowalnością związane z konfliktami o zatrzaski są w pełni usuwane. Rywalizacja Spinlock Ponieważ In-Memory OLTP nie ma zatrzasków podczas uzyskiwania dostępu do danych, problemy ze skalowalnością związane z rywalizacjami spinlock są w pełni usuwane. Blokowanie powiązanej rywalizacji Jeśli aplikacja bazy danych napotka problemy blokujące między operacjami odczytu i zapisu, In-Memory OLTP usuwa problemy blokujące, ponieważ używa nowej formy optymistycznej kontrolki współbieżności w celu zaimplementowania wszystkich poziomów izolacji transakcji. In-Memory OLTP nie używa bazy danych TempDB do przechowywania wersji wierszy. Jeśli problem ze skalowaniem jest spowodowany konfliktem między dwiema operacjami zapisu, takimi jak dwie współbieżne transakcje próbujące zaktualizować ten sam wiersz, In-Memory OLTP umożliwia pomyślne wykonanie jednej transakcji i niepowodzenie drugiej transakcji. Transakcja, która zakończyła się niepowodzeniem, musi zostać złożona ponownie, jawnie lub niejawnie. W obu przypadkach należy wprowadzić zmiany w aplikacji. Jeśli twoja aplikacja napotyka częste konflikty między dwiema operacjami zapisu, skuteczność optymistycznej blokady zostaje zmniejszona. Aplikacja nie jest odpowiednia dla In-Memory OLTP. Większość aplikacji OLTP nie ma konfliktów zapisu, chyba że konflikt jest wynikiem eskalacji blokad.

zabezpieczenia Row-Level w tabelach Memory-Optimized

Row-Level Zabezpieczenia są obsługiwane w tabelach zoptymalizowanych pod kątem pamięci. Zastosowanie zasad zabezpieczeń Row-Level do tabel zoptymalizowanych pod kątem pamięci jest zasadniczo takie samo jak tabele oparte na dyskach, z tą różnicą, że wbudowane funkcje tabeli używane jako predykaty zabezpieczeń muszą być natywnie skompilowane (utworzone przy użyciu opcji WITH NATIVE_COMPILATION). Aby uzyskać szczegółowe informacje, zobacz sekcję Zgodność między funkcjami w temacie zabezpieczeniaRow-Level .

Różne wbudowane funkcje zabezpieczeń, które są niezbędne do zabezpieczeń na poziomie wiersza, są dostępne dla tabel zoptymalizowanych pod kątem pamięci. Aby uzyskać szczegółowe informacje, zobacz Wbudowane funkcje w modułach skompilowanych natywnie.

EXECUTE AS CALLER — wszystkie moduły natywne obsługują teraz funkcję EXECUTE AS CALLER domyślnie, nawet jeśli nie określono wskazówki. Jest to spowodowane tym, że oczekuje się, że wszystkie funkcje predykatu zabezpieczeń na poziomie wiersza używają funkcji EXECUTE AS CALLER, aby funkcja i wszystkie wbudowane funkcje używane w nim były oceniane w kontekście wywołującego użytkownika.
Funkcja EXECUTE AS CALLER ma niewielki (około 10%) wpływ na wydajność spowodowany kontrolami uprawnień wywołującego. Jeśli moduł jawnie określa EXECUTE AS OWNER lub EXECUTE AS SELF, te kontrole uprawnień i związane z nimi koszty wydajności są unikane. Jednak użycie jednej z tych opcji wraz ze wspomnianymi wbudowanymi funkcjami powoduje zwiększenie wydajności z powodu niezbędnego przełączania kontekstu.

Scenariusze

Aby zapoznać się z krótkim omówieniem typowych scenariuszy, w których In-Memory OLTP może poprawić wydajność, zobacz In-Memory OLTP.

Zobacz też

In-Memory OLTP (optymalizacjaIn-Memory)