Optymalizowanie wydajności przy użyciu technologii w pamięci w usłudze Azure SQL Database

Dotyczy:Azure SQL Database

Technologie w pamięci umożliwiają zwiększenie wydajności aplikacji i potencjalnie obniżenie kosztów bazy danych.

Kiedy należy używać technologii w pamięci

Korzystając z technologii w pamięci, można osiągnąć ulepszenia wydajności przy użyciu różnych obciążeń:

  • Transakcyjne (przetwarzanie transakcyjne online (OLTP)), w którym większość żądań odczytuje lub aktualizuje mniejszy zestaw danych, na przykład operacje tworzenia/odczytu/aktualizacji/usuwania (CRUD).
  • Analityczne (przetwarzanie analityczne online (OLAP)), w których większość zapytań ma złożone obliczenia na potrzeby raportowania, a także regularnie zaplanowane procesy, które wykonują operacje ładowania (lub ładowania zbiorczego) i/lub zapisują zmiany danych w istniejących tabelach. Często obciążenia OLAP są okresowo aktualizowane z obciążeń OLTP.
  • Mieszane (hybrydowe przetwarzanie transakcji/analizy (HTAP)), w których zapytania OLTP i OLAP są wykonywane na tym samym zestawie danych.

Technologie w pamięci mogą zwiększyć wydajność tych obciążeń, zachowując dane, które powinny być przetwarzane w pamięci, przy użyciu natywnej kompilacji zapytań lub zaawansowanego przetwarzania, takiego jak przetwarzanie wsadowe i instrukcje SIMD dostępne na podstawowym sprzęcie.

Omówienie

Usługa Azure SQL Database obsługuje następujące technologie w pamięci:

  • Funkcja OLTP w pamięci zwiększa liczbę transakcji na sekundę i zmniejsza opóźnienie przetwarzania transakcji. Scenariusze, które korzystają z przetwarzania OLTP w pamięci, to: przetwarzanie transakcji o wysokiej przepływności, takie jak handel i gry, pozyskiwanie danych ze zdarzeń lub urządzeń IoT, buforowanie, ładowanie danych oraz scenariusze zmiennych tabeli i tabeli tymczasowej.
  • Klastrowane indeksy magazynu kolumn zmniejszają rozmiar magazynu (do 10 razy) i zwiększają wydajność zapytań raportowania i analizy. Można jej używać z tabelami faktów w składnicach danych, aby dopasować więcej danych do bazy danych i zwiększyć wydajność. Ponadto można używać ich z danymi historycznymi w operacyjnej bazie danych do archiwizowania i wykonywania zapytań o maksymalnie 10 razy więcej danych.
  • Nieklastrowane indeksy magazynu kolumn dla protokołu HTAP ułatwiają uzyskiwanie wglądu w działalność biznesową w czasie rzeczywistym za pomocą bezpośredniego wykonywania zapytań względem operacyjnej bazy danych bez konieczności uruchamiania kosztownego procesu wyodrębniania, przekształcania i ładowania (ETL) i oczekiwania na wypełnienie magazynu danych. Nieklastrowane indeksy magazynu kolumn umożliwiają szybkie wykonywanie zapytań analitycznych w bazie danych OLTP przy jednoczesnym zmniejszeniu wpływu na obciążenie operacyjne.
  • Zoptymalizowane pod kątem pamięci klastrowane indeksy magazynu kolumn dla protokołu HTAP umożliwiają szybkie przetwarzanie transakcji i jednoczesne uruchamianie zapytań analitycznych bardzo szybko na tych samych danych.

Indeksy magazynu kolumn i olTP w pamięci zostały wprowadzone odpowiednio do programu SQL Server w 2012 i 2014 r. Usługi Azure SQL Database, Azure SQL Managed Instance i SQL Server współużytkuje tę samą implementację technologii w pamięci.

Uwaga

Aby zapoznać się ze szczegółowym samouczkiem krok po kroku, aby zademonstrować zalety wydajności technologii OLTP w pamięci przy użyciu AdventureWorksLT przykładowej bazy danych i ostress.exe, zobacz Przykład w pamięci w usłudze Azure SQL Database.

Zalety technologii w pamięci

Ze względu na bardziej wydajne przetwarzanie zapytań i transakcji technologie w pamięci pomagają również zmniejszyć koszty. Zazwyczaj nie trzeba uaktualniać warstwy cenowej bazy danych, aby osiągnąć wzrost wydajności. W niektórych przypadkach można nawet zmniejszyć warstwę cenową, jednocześnie zauważając poprawę wydajności za pomocą technologii w pamięci.

Korzystając z olTP w pamięci, rozwiązania biznesowe kworum były w stanie podwoić swoje obciążenie, jednocześnie poprawiając jednostki DTU o 70%. Aby uzyskać więcej informacji, zobacz OlTP w pamięci w usłudze Azure SQL Database.

Uwaga

Technologie w pamięci są dostępne w warstwach Premium i Krytyczne dla działania firmy usługi Azure SQL Database.

W tym artykule opisano aspekty indeksów OLTP i magazynu kolumn w pamięci, które są specyficzne dla usługi Azure SQL Database, a także przykłady:

  • Zobaczysz wpływ tych technologii na limity magazynowania i rozmiaru danych.
  • Zobaczysz, jak zarządzać przenoszeniem baz danych korzystających z tych technologii między różnymi warstwami cenowymi.
  • Zobaczysz dwa przykłady ilustrujące użycie olTP w pamięci, a także indeksy magazynu kolumn.

Aby uzyskać więcej informacji o pamięci w programie SQL Server, zobacz:

Przetwarzanie OLTP danych w pamięci

Technologia OLTP w pamięci zapewnia niezwykle szybkie operacje dostępu do danych dzięki przechowywaniu wszystkich danych w pamięci. Używa również wyspecjalizowanych indeksów, natywnej kompilacji zapytań i dostępu do danych bez zatrzaśnięć w celu zwiększenia wydajności obciążenia OLTP. Istnieją dwa sposoby organizowania danych OLTP w pamięci:

  • Format magazynu wierszy zoptymalizowany pod kątem pamięci, w którym każdy wiersz jest oddzielnym obiektem pamięci. Jest to klasyczny format OLTP w pamięci zoptymalizowany pod kątem obciążeń OLTP o wysokiej wydajności. Istnieją dwa typy tabel zoptymalizowanych pod kątem pamięci, które mogą być używane w formacie magazynu wierszy zoptymalizowanym pod kątem pamięci:

    • Trwałe tabele (SCHEMA_AND_DATA), w których wiersze umieszczone w pamięci są zachowywane po ponownym uruchomieniu serwera. Ten typ tabel zachowuje się jak tradycyjna tabela magazynu wierszy z dodatkowymi zaletami optymalizacji w pamięci.
    • Tabele niezwiązane (SCHEMA_ONLY), w których wiersze nie są zachowywane po ponownym uruchomieniu. Ten typ tabeli jest przeznaczony dla danych tymczasowych (na przykład zamiany tabel tymczasowych) lub tabel, w których należy szybko załadować dane przed przeniesieniem ich do utrwalonej tabeli (tzw. tabel przejściowych).
  • Format magazynu kolumn zoptymalizowany pod kątem pamięci, w którym dane są zorganizowane w formacie kolumnowym. Ta struktura jest przeznaczona dla scenariuszy HTAP, w których należy uruchamiać zapytania analityczne w tej samej strukturze danych, w której działa obciążenie OLTP.

Uwaga

Technologia OLTP w pamięci jest przeznaczona dla struktur danych, które mogą w pełni znajdować się w pamięci. Ponieważ nie można odciążyć danych w pamięci na dysku, upewnij się, że używasz bazy danych, która ma wystarczającą ilość pamięci. Aby uzyskać więcej informacji, zobacz Rozmiar danych i limit magazynu dla olTP w pamięci.

Rozmiar danych i limit magazynu dla olTP w pamięci

Funkcja OLTP w pamięci zawiera tabele zoptymalizowane pod kątem pamięci, które są używane do przechowywania danych użytkownika. Te tabele są wymagane do dopasowania do pamięci. Ponieważ zarządzasz pamięcią bezpośrednio w usłudze SQL Database, mamy pojęcie limitu przydziału danych użytkownika. Ten pomysł jest określany jako magazyn OLTP w pamięci.

Każda obsługiwana pojedyncza warstwa cenowa bazy danych i każda warstwa cenowa elastycznej puli zawiera pewną ilość magazynu OLTP w pamięci.

Następujące elementy są liczone do limitu magazynu OLTP w pamięci:

  • Aktywne wiersze danych użytkownika w tabelach zoptymalizowanych pod kątem pamięci i zmiennych tabeli. Stare wersje wierszy nie są liczone w kierunku limitu.
  • Indeksy w tabelach zoptymalizowanych pod kątem pamięci.
  • Obciążenie operacyjne operacji ALTER TABLE.

W przypadku przekroczenia limitu zostanie wyświetlony błąd przekroczenia limitu przydziału i nie możesz już wstawiać ani aktualizować danych. Aby wyeliminować ten błąd, usuń dane lub zwiększ warstwę cenową bazy danych lub puli.

Aby uzyskać szczegółowe informacje na temat monitorowania użycia magazynu OLTP w pamięci i konfigurowania alertów po osiągnięciu limitu, zobacz Monitorowanie magazynu w pamięci.

Informacje o pulach elastycznych

W przypadku elastycznych pul magazyn OLTP w pamięci jest współużytkowany we wszystkich bazach danych w puli. W związku z tym użycie w jednej bazie danych może potencjalnie mieć wpływ na inne bazy danych. Istnieją dwa środki zaradcze:

  • Skonfiguruj pulę Max-eDTU lub MaxvCore dla baz danych, które są niższe niż liczba jednostek eDTU lub rdzeni wirtualnych dla całej puli. To maksymalne ograniczenie wykorzystania magazynu OLTP w pamięci w dowolnej bazie danych w puli do rozmiaru odpowiadającego liczbie jednostek eDTU.
  • Skonfiguruj wartość Min-eDTU lub MinvCore większą niż 0. To minimum gwarantuje, że każda baza danych w puli ma dostępną ilość dostępnego magazynu OLTP w pamięci, który odpowiada skonfigurowanej konfiguracji Min-eDTU lub vCore.

Zmienianie warstw usług baz danych korzystających z technologii OLTP w pamięci

Zawsze możesz uaktualnić bazę danych do wyższej warstwy, na przykład z warstwy Ogólnego przeznaczenia (rdzenia wirtualnego) do warstwy Krytyczne dla działania firmy lub Standardowa (DTU) do warstwy Premium. Dostępne funkcje i zasoby zwiększają się tylko.

Jednak obniżenie warstwy może negatywnie wpłynąć na bazę danych. Wpływ jest szczególnie widoczny podczas obniżania z Krytyczne dla działania firmy do ogólnego przeznaczenia (lub Premium do warstwy Standardowa lub Podstawowa), gdy baza danych zawiera obiekty OLTP w pamięci. Obiekty w pamięci można łatwo znaleźć w bazie danych.

Tabele zoptymalizowane pod kątem pamięci są niedostępne po obniżeniu poziomu (nawet jeśli pozostają widoczne). Te same zagadnienia mają zastosowanie w przypadku obniżenia warstwy cenowej elastycznej puli lub przeniesienia bazy danych z technologiami w pamięci do elastycznej puli ogólnego przeznaczenia, standardowej lub podstawowej.

Ważne

Funkcja OLTP w pamięci nie jest obsługiwana w warstwach Ogólnego przeznaczenia, Standardowa lub Podstawowa jednostka DTU usługi Azure SQL Database. W związku z tym nie można przenieść bazy danych z żadnymi obiektami OLTP w pamięci do jednej z tych warstw. Przed obniżeniem poziomu bazy danych usuń wszystkie tabele i typy tabel zoptymalizowane pod kątem pamięci, a także wszystkie natywnie skompilowane moduły języka T-SQL lub przekonwertuj je na obiekty oparte na wierszach.

Skalowanie zasobów w dół w warstwie Krytyczne dla działania firmy: dane w tabelach zoptymalizowanych pod kątem pamięci muszą mieścić się w magazynie OLTP w pamięci skojarzonym z warstwą bazy danych lub jest dostępna w elastycznej puli. Jeśli spróbujesz przeskalować warstwę w dół lub przenieść bazę danych do puli, która nie ma wystarczającej ilości dostępnego magazynu OLTP w pamięci, operacja zakończy się niepowodzeniem.

Określanie, czy istnieją obiekty w pamięci

Istnieje programowy sposób zrozumienia, czy dana baza danych obsługuje olTP w pamięci. Możesz wykonać następujące zapytanie Języka Transact-SQL:

SELECT DatabasePropertyEx(DB_NAME(), 'IsXTPSupported');

Jeśli zapytanie zwróci 1wartość , w tej bazie danych jest obsługiwana funkcja OLTP w pamięci.

Następujące zapytania identyfikują wszystkie obiekty, które należy usunąć, zanim baza danych będzie mogła zostać obniżona do warstwy Ogólnego przeznaczenia, Standardowa lub Podstawowa:

SELECT * FROM sys.tables WHERE is_memory_optimized=1
SELECT * FROM sys.table_types WHERE is_memory_optimized=1
SELECT * FROM sys.sql_modules WHERE uses_native_compilation=1

Magazyn kolumn w pamięci

Technologia magazynu kolumn w pamięci umożliwia przechowywanie i wykonywanie zapytań dotyczących dużej ilości danych w tabelach. Technologia magazynu kolumn używa formatu magazynu danych opartych na kolumnach i przetwarzania zapytań wsadowych, aby uzyskać do 10 razy wydajność zapytań w obciążeniach OLAP w przypadku tradycyjnego magazynu zorientowanego na wiersz. Można również uzyskać do 10-krotnej kompresji danych w porównaniu z rozmiarem danych nieskompresowanych.

Istnieją dwa typy modeli magazynu kolumn, których można użyć do organizowania danych:

  • Klastrowany magazyn kolumn, w którym wszystkie dane w tabeli są zorganizowane w formacie kolumnowym. W tym modelu wszystkie wiersze w tabeli są umieszczane w formacie kolumnowym, który bardzo kompresuje dane i umożliwia wykonywanie szybkich zapytań analitycznych i raportów w tabeli. W zależności od charakteru danych rozmiar danych może być zmniejszony o 10x-100x. Model klastrowanego magazynu kolumn umożliwia również szybkie pozyskiwanie dużych ilości danych (zbiorcze ładowanie), ponieważ duże partie danych większe niż 100 000 wierszy są kompresowane przed ich zapisaniem na dysku. Ten model jest dobrym wyborem dla klasycznych scenariuszy magazynu danych.
  • Nieklarowany magazyn kolumn, w którym dane są przechowywane w tradycyjnej tabeli magazynu wierszy i istnieje indeks w formacie magazynu kolumn, który jest używany dla zapytań analitycznych. Ten model umożliwia hybrydowe przetwarzanie transakcyjne i analityczne (HTAP): możliwość uruchamiania wydajnej analizy w czasie rzeczywistym na obciążeniu transakcyjnym. Zapytania OLTP są wykonywane w tabeli rowstore, która jest zoptymalizowana pod kątem uzyskiwania dostępu do małego zestawu wierszy, podczas gdy zapytania OLAP są wykonywane w indeksie magazynu kolumn, który jest lepszym wyborem do skanowania i analizy. Optymalizator zapytań dynamicznie wybiera format magazynu wierszy lub magazynu kolumn na podstawie zapytania. Indeksy nieklastrowanego magazynu kolumn nie zmniejszają rozmiaru danych, ponieważ oryginalny zestaw danych jest przechowywany w oryginalnej tabeli magazynu wierszy bez żadnych zmian. Jednak rozmiar dodatkowego indeksu magazynu kolumn powinien być o wielkości mniejszy niż równoważny indeks drzewa B.

Uwaga

Technologia magazynu kolumn w pamięci przechowuje tylko dane potrzebne do przetworzenia w pamięci, podczas gdy dane, które nie mieszczą się w pamięci, są przechowywane na dysku. W związku z tym ilość danych w strukturach magazynu kolumn w pamięci może przekraczać ilość dostępnej pamięci.

Rozmiar danych i magazyn indeksów magazynu kolumn

Indeksy magazynu kolumn nie są wymagane do dopasowania do pamięci. W związku z tym jedynym limitem rozmiaru indeksów jest maksymalny całkowity rozmiar bazy danych, który jest udokumentowany w artykule Model zakupów oparty na jednostkach DTU i model zakupów oparty na rdzeniach wirtualnych.

W przypadku korzystania z klastrowanych indeksów magazynu kolumn kompresja kolumn jest używana dla podstawowego magazynu tabel. Ta kompresja może znacznie zmniejszyć ilość miejsca w magazynie danych użytkownika, co oznacza, że można zmieścić więcej danych w bazie danych. Kompresję można dodatkowo zwiększyć za pomocą kompresji archiwalnej kolumny. Ilość kompresji, którą można osiągnąć, zależy od charakteru danych, ale 10 razy kompresja nie jest rzadkością.

Jeśli na przykład masz bazę danych o maksymalnym rozmiarze 1 terabajta (TB) i 10 razy kompresję przy użyciu indeksów magazynu kolumn, możesz zmieścić łącznie 10 TB danych użytkownika w bazie danych.

W przypadku używania indeksów magazynu kolumn nieklastrowanych tabela podstawowa jest nadal przechowywana w tradycyjnym formacie magazynu wierszy. W związku z tym oszczędności magazynu nie są tak znaczące, jak w przypadku klastrowanych indeksów magazynu kolumn. Jeśli jednak zastępujesz wiele tradycyjnych indeksów nieklastrowanych pojedynczym indeksem magazynu kolumn, nadal możesz zobaczyć ogólne oszczędności w rozmiarze magazynu dla tabeli.

Zmienianie warstw usług baz danych zawierających indeksy magazynu kolumn

Obniżenie poziomu pojedynczej bazy danych do warstwy Podstawowa lub Standardowa może nie być możliwe, jeśli warstwa docelowa jest niższa niż S3. Indeksy magazynu kolumn są obsługiwane tylko w warstwie cenowej Krytyczne dla działania firmy/Premium oraz w warstwie Standardowa, S3 lub nowszej, a nie w warstwie Podstawowa. Po obniżeniu poziomu bazy danych na nieobsługiwaną warstwę lub poziom indeks magazynu kolumn stanie się niedostępny. System utrzymuje indeks magazynu kolumn, ale nigdy nie używa indeksu. W przypadku późniejszego uaktualnienia do obsługiwanej warstwy lub poziomu indeks magazynu kolumn jest natychmiast gotowy do ponownego użycia.

Jeśli masz indeks klastrowanego magazynu kolumn, cała tabela stanie się niedostępna po obniżeniu poziomu. Przed obniżeniem poziomu bazy danych do nieobsługiwanej warstwy lub poziomu usuń wszystkie klastrowane indeksy magazynu kolumn (i zastąp je indeksami klastrowanych magazynów wierszy).