Udostępnij za pomocą

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 kolumnowego zmniejszają rozmiar magazynu (do 10 razy) i poprawiają wydajność zapytań dotyczących raportowania i analizy. Można go używać z tabelami faktów w składnicach danych, aby umieścić więcej danych w bazie danych i zwiększyć wydajność. Ponadto można używać tego z danymi historycznymi w bazie danych operacyjnych, aby archiwizować i móc zapytać o 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 magazynujące kolumny i OLTP w pamięci zostały wprowadzone w SQL Server w latach 2012 i 2014, odpowiednio. Usługi Azure SQL Database, Azure SQL Managed Instance i SQL Server korzystają z tej samej implementacji technologii in-memory.

Uwaga

Aby zapoznać się z dokładnym, krok po kroku samouczkiem demonstrującym zalety wydajności technologii In-Memory OLTP przy użyciu przykładowej bazy danych AdventureWorksLT 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 In-Memory OLTP, Quorum Business Solutions było w stanie podwoić swoje obciążenie, jednocześnie poprawiając wydajność DTU o 70%. Aby uzyskać więcej informacji, zobacz In-Memory OLTP w usłudze Azure SQL Database.

Uwaga

Funkcja In-Memory OLTP jest dostępna w warstwach usług Premium (DTU) i Business Critical (vCore) usługi Azure SQL Database. Warstwa usługi Hiperskala obsługuje podzestaw obiektów In-Memory OLTP. Aby uzyskać więcej informacji, zobacz Ograniczenia hiperskali.

Indeksy magazynu kolumn są dostępne we wszystkich warstwach usług, z wyjątkiem warstwy Podstawowa oraz warstwy Standardowa, jeżeli cel usługi jest niższy od S3. Aby uzyskać więcej informacji, zobacz Zmienianie poziomów usług baz danych zawierających indeksy magazynu kolumnowego.

W tym artykule opisano aspekty Indeksów In-Memory OLTP i indeksów kolumnowych, które są specyficzne dla usługi Azure SQL Database, a także zamieszczono przykłady, które pozwalają zobaczyć:

  • Wpływ tych technologii na limity magazynowania i rozmiaru danych.
  • Jak zarządzać przenoszeniem baz danych korzystających z tych technologii między różnymi warstwami cenowymi.
  • Ilustracyjne użycie In-Memory OLTP, a także indeksów columnstore.

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

Przetwarzanie OLTP 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 wierszy zoptymalizowany pod kątem pamięci, w którym każdy wiersz stanowi oddzielny obiekt 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:

    • umieszczone w pamięci są zachowywane po ponownym uruchomieniu serwera. Ten typ tabel zachowuje się jak tradycyjna tabela w formacie wierszowym z dodatkowymi korzyściami uzyskanymi dzięki optymalizacji w pamięci.
    • 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 kolumn magazynu 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 In-Memory OLTP.

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 muszą zmieścić się w pamięci. Każdy cel usługi ma przydział pamięci lub limit dla tabel zoptymalizowanych pod kątem pamięci, znanych jako magazyn OLTP w pamięci.

Każdy obsługiwany parametr operacyjny usługi pojedynczej bazy danych oraz każdy parametr operacyjny usługi elastycznej puli obejmuje pewną ilość pamięci OLTP:

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ą wliczane do 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 cel usługi bazy danych lub elastycznej 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 OLTP w pamięci.

Informacje o pulach elastycznych

Dzięki elastycznym pulom pamięć OLTP jest dzielona między wszystkie bazy 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 Max eDTU lub Max vCore dla baz danych, które są mniejsze niż liczba jednostek eDTU lub rdzeni wirtualnych dla całej puli. To maksimum ogranicza również proporcjonalnie wykorzystanie pamięci OLTP w każdej bazie danych w puli.
  • Skonfiguruj wartość Min eDTU lub Min vCore większą niż 0. To minimum gwarantuje, że każda baza danych w puli ma ilość pamięci OLTP dostępnej w bazie danych, która odpowiada konfiguracji Min eDTU lub Min vCore.

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

In-Memory OLTP nie jest obsługiwane w warstwach Usługi Azure SQL Database: Ogólnego przeznaczenia, Standardowa i Podstawowa. W związku z tym nie można skalować ani przywrócić bazy danych zawierającej jakiekolwiek obiekty OLTP In-Memory do jednej z tych warstw. Jeśli chcesz skalować bazę danych do jednej z tych warstw usług, 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 dyskach i zwykłe moduły języka T-SQL.

Podczas zmniejszania skali bazy danych Business Critical lub Premium, dane w tabelach zoptymalizowanych pod kątem pamięci muszą mieścić się w pamięci maszyn OLTP dostępnej w docelowym celu usługowym bazy danych lub elastycznej puli. Jeśli spróbujesz zmniejszyć skalę bazy danych lub elastycznej puli albo przenieść bazę danych do elastycznej puli i docelowy parametr usługi nie ma wystarczającej ilości dostępnej pamięciowej pamięci OLTP, operacja zakończy się niepowodzeniem.

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

Istnieje programowy sposób znajdowania, 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 1, w tej bazie danych jest obsługiwana funkcja In-Memory OLTP.

Następujące zapytania identyfikują wszystkie obiekty, które należy usunąć przed skalowaniem bazy danych do warstwy usługi Hiperskala, 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;

Przywracanie bazy danych za pomocą obiektów OLTP In-Memory

Jeśli w bazie danych utworzono obiekty OLTPIn-Memory OLTP i chcesz przywrócić bazę danych, musisz użyć warstw usługi Krytyczne dla działania firmy lub Premium dla przywróconej bazy danych. Ma to zastosowanie nawet w przypadku usunięcia wszystkich obiektów OLTP In-Memory przed punktem przywrócenia do określonego momentu w czasie.

Aby umożliwić automatyczne tworzenie kopii zapasowych bazy danych w innych warstwach usług po usunięciu wszystkich obiektów OLTP In-Memory, wykonaj następującą procedurę:

  1. Przeprowadź skalowanie bazy danych do warstw usługi: Ogólnego przeznaczenia, Standardowej lub Podstawowej.
  2. W razie potrzeby przeprowadź skalowanie bazy danych z powrotem do poziomu usługi Business Critical lub Premium, albo do poziomu usługi Hiperskala.

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 kolumnowa używa formatu magazynu danych opartych na kolumnach i przetwarzania zapytań wsadowych, aby zwiększyć wydajność zapytań nawet do 10 razy przy obciążeniach OLAP w porównaniu do tradycyjnej, wierszowo zorientowanej struktury danych. Można również uzyskać do 10-krotnej kompresji danych w porównaniu z rozmiarem danych nieskompresowanych.

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

  • Klastrowany magazyn kolumnowy, gdzie wszystkie dane w tabeli są zorganizowane w formacie kolumnowym. W tym typie indeksu 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. Klastrowane indeksy magazynu kolumn umożliwiają 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 typ indeksu jest dobrym wyborem dla klasycznych scenariuszy magazynu danych.
  • Nieklaterowany magazyn kolumn, w którym dane są przechowywane w tradycyjnej tabeli magazynu wierszy i istnieje dodatkowy indeks w formacie magazynu kolumn używanym do zapytań analitycznych. Ten typ indeksu umożliwia hybrydowe przetwarzanie transakcyjne (HTAP): możliwość szybkiego uruchamiania analiz 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 nieklastrowanych columnstore nie zmniejszają rozmiaru danych, ponieważ oryginalny zestaw danych jest przechowywany w oryginalnej tabeli rowstore bez żadnych zmian. Jednak rozmiar dodatkowego indeksu kolumnowego jest o rzędy wielkości mniejszy niż równoważnego indeksu drzewa B.

Uwaga

Technologia magazynu kolumn w pamięci przechowuje tylko dane potrzebne do przetwarzania 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 może przekraczać ilość dostępnej pamięci.

Rozmiar danych i przestrzeń magazynowa dla indeksów kolumnowych

Indeksy kolumnowe nie muszą się w całości mieścić w pamięci. W związku z tym jedynym limitem rozmiaru indeksów jest maksymalny całkowity rozmiar bazy danych, co jest udokumentowane w artykułach dotyczących modelu zakupu opartego na jednostkach DTU i modelu zakupu opartego 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. Współczynnik kompresji można dodatkowo zwiększyć przy użyciu archiwalnej kompresji kolumnowej. 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 uzyskasz 10-krotną kompresję dzięki użyciu indeksów columnstore, możesz zmieścić łącznie 10 TB danych użytkownika w bazie danych.

W przypadku używania indeksów kolumnowych nieklastrowanych, tabela podstawowa jest nadal przechowywana w tradycyjnym formacie magazynu wierszowego. W związku z tym oszczędności pamięci nie są tak znaczące, jak w przypadku klastrowanych indeksów magazynu kolumnowego. Jeśli jednak zastępujesz wiele tradycyjnych indeksów nieklastrowanych jednym indeksem kolumnowym, nadal możesz doświadczyć ogólnych oszczędności w zajętości pamięci dla tabeli. Możesz również użyć kompresji danych typu rowstore dla tabeli podstawowej.

Zmiana poziomów usług baz danych zawierających indeksy kolumnowe

Jeśli używasz modelu zakupu DTU, a baza danych zawiera indeksy columnstore, aplikacja może przestać działać, jeśli skalujesz bazę danych poniżej obiektu usługi S3. Indeksy kolumnowe są obsługiwane tylko w warstwach Hyperscale, Business Critical i Premium, a także w warstwie Standard, jeśli korzysta się z S3 i nowszych. Indeksy Columnstore nie są obsługiwane w Podstawowej warstwie usługi. W przypadku skalowania bazy danych do nieobsługiwanej warstwy usługi lub celu usługi indeks magazynu kolumn staje się niedostępny. System utrzymuje indeks podczas wykonywania instrukcji DML, ale nigdy nie używa indeksu. Jeśli później powrócisz do obsługiwanej warstwy usługi lub obiektu usługi, indeks magazynu kolumn będzie natychmiast gotowy do ponownego użycia.

Jeśli masz indeks klastrowanego magazynu kolumn, cała tabela stanie się niedostępna, jeśli baza danych jest skalowana do nieobsługiwanej warstwy usługi lub celu usługi. Upuść wszystkie kolumnowe indeksy klastrowane, zastępując je indeksami klastrowanymi magazynu wierszy lub stertami, przed operacją skalowania.

Powiązana zawartość

  • Last updated on