Wydajność OLTP In-Memory

Wydajność OLTP In-Memory jest znacząco wyższa niż tabel dyskowych, kosztem ograniczeń funkcjonalnych.

Na czym polega In-Memory OLTP w SQL Server

Wydajność OLTP In-Memory to mechanizm silnika Microsoft SQL Server przeznaczony do przyspieszania przetwarzania transakcji online. Dane tabel zoptymalizowanych pod kątem pamięci są przechowywane w strukturach zaprojektowanych do pracy bez klasycznego bufora stron, z którego korzystają zwykłe tabele dyskowe. SQL Server może dzięki temu ograniczyć koszt operacji wejścia-wyjścia, blokowania i zarządzania stronami danych. Nie oznacza to jednak, że każda tabela przeniesiona do pamięci automatycznie przyspieszy cały system. Efekt zależy od profilu obciążenia, liczby konfliktów transakcji, projektu indeksów, wielkości danych oraz dostępnej pamięci operacyjnej.

In-Memory OLTP obejmuje przede wszystkim memory-optimized tables oraz procedury składowane oznaczone jako natively compiled. Tabela zoptymalizowana pod kątem pamięci musi mieć określony sposób trwałości danych: DURABILITY = SCHEMA_AND_DATA zachowuje dane po ponownym uruchomieniu SQL Server, natomiast DURABILITY = SCHEMA_ONLY zachowuje definicję tabeli, ale po restarcie pozostawia ją pustą. Drugi wariant bywa używany dla danych tymczasowych, kolejek roboczych lub tabel przejściowych, gdy odtworzenie zawartości nie jest wymagane.

Skąd wynika krótszy czas obsługi transakcji

Memory-optimized tables korzystają z wersjonowania wierszy i optymistycznego modelu kontroli współbieżności. Transakcja odczytuje określoną wersję danych, a SQL Server sprawdza przy zatwierdzaniu, czy w międzyczasie nie wystąpił konflikt naruszający izolację transakcji. W typowym scenariuszu zmniejsza to oczekiwanie na blokady i ogranicza wzajemne zatrzymywanie się sesji wykonujących krótkie operacje OLTP. Przy dużej liczbie równoległych zapisów konflikty nadal mogą występować, dlatego sama obecność danych w pamięci nie eliminuje potrzeby analizy transakcji.

Drugim elementem jest możliwość użycia procedur natively compiled. SQL Server kompiluje ich obsługiwany kod do natywnej postaci wykonywanej przez procesor, co może zmniejszyć narzut interpretacji instrukcji i planowania powtarzalnych operacji. Procedura taka musi przestrzegać ograniczeń funkcji i składni wspieranych przez konkretną wersję SQL Server. W praktyce największe korzyści pojawiają się przy krótkich, często wykonywanych transakcjach, które mają przewidywalny przebieg i operują na tabelach zoptymalizowanych pod kątem pamięci.

Indeksy, trwałość i ograniczenia rozwiązania

Tabela memory-optimized wymaga co najmniej jednego indeksu. SQL Server obsługuje dla niej między innymi indeksy HASH oraz indeksy nonclustered oparte na strukturze Bw-tree. Indeks HASH jest przydatny przy wyszukiwaniu po dokładnej wartości klucza, ale jego skuteczność zależy od prawidłowego doboru liczby bucketów oraz rozkładu danych. Nie jest odpowiednim zamiennikiem indeksu zakresowego dla zapytań używających operatorów takich jak >, < lub BETWEEN. Indeks nonclustered lepiej pasuje do wyszukiwania zakresowego i porządkowania wyników.

W tabelach trwałych SQL Server zapisuje zmiany do plików kontenera FILESTREAM przeznaczonych dla danych zoptymalizowanych pod kątem pamięci. Przywracanie bazy, odzyskiwanie po awarii i kontrola wolnego miejsca wymagają więc uwzględnienia nie tylko rozmiaru tabel dyskowych, lecz także pamięci oraz plików używanych przez In-Memory OLTP. Rozwiązanie ma również ograniczenia funkcjonalne. Nie wszystkie typy danych, konstrukcje języka T-SQL, operacje DDL, wyzwalacze, klucze obce i funkcje dostępne dla tabel dyskowych są obsługiwane identycznie przez tabele memory-optimized. Zakres wsparcia należy sprawdzić dla używanej edycji i wersji SQL Server.

Ocena przed wdrożeniem i diagnostyka

Przed migracją trzeba zmierzyć rzeczywisty profil obciążenia: czas trwania transakcji, liczbę operacji odczytu i zapisu, oczekiwania na blokady, zużycie procesora, przepustowość logu transakcyjnego oraz dostępność pamięci. Warto także sprawdzić, czy aplikacja korzysta z zapytań zakresowych, dynamicznego SQL, funkcji nieobsługiwanych przez procedury natively compiled albo mechanizmów wymagających tabel dyskowych. Migracja pojedynczej tabeli może wymagać zmian w procedurach, indeksach, transakcjach i procesie wdrażania schematu.

Podczas eksploatacji należy monitorować pamięć wykorzystaną przez obiekty In-Memory OLTP, konflikty transakcji, czas kompilacji i wykonania procedur oraz wzrost plików kontenera. Błąd polegający na przekroczeniu dostępnej pamięci może przerwać zapis, mimo że system nadal ma wolne miejsce na dysku. Z tego powodu In-Memory OLTP nie jest uniwersalnym trybem pracy dla całej bazy. Jest wyspecjalizowanym mechanizmem SQL Server, który daje wymierne korzyści wtedy, gdy obciążenie pasuje do jego modelu współbieżności, ograniczeń składniowych i wymagań pamięciowych.