Memory-Optimized Table

Memory-Optimized Table to tabela przechowywana w pamięci operacyjnej, obsługiwana bez klasycznych blokad.

Memory-Optimized Table w SQL Server

Memory-Optimized Table to konkretny mechanizm silnika Microsoft SQL Server dostępny w technologii In-Memory OLTP. Wiersze takiej tabeli są przechowywane w pamięci operacyjnej, a silnik stosuje specjalne struktury danych i indeksy zamiast klasycznego układu stron danych używanego przez zwykłe tabele dyskowe. Tabela nie jest jednak wyłącznie nietrwałym buforem. W zależności od ustawienia może również zapisywać dane w plikach kontrolowanych przez SQL Server, aby odtworzyć zawartość po ponownym uruchomieniu usługi.

Tabelę tworzy się w konkretnej bazie SQL Server, używając klauzuli WITH (MEMORY_OPTIMIZED = ON). Przykładowa definicja może wyglądać następująco: CREATE TABLE dbo.Zamowienia (Id bigint NOT NULL PRIMARY KEY NONCLUSTERED, Status int NOT NULL) WITH (MEMORY_OPTIMIZED = ON, DURABILITY = SCHEMA_AND_DATA);. Sama obecność klauzuli nie oznacza automatycznej poprawy każdego zapytania. Zysk zależy między innymi od rodzaju obciążenia, liczby operacji współbieżnych, konstrukcji indeksów, rozmiaru danych i tego, czy aplikacja rzeczywiście korzysta z operacji dobrze obsługiwanych przez In-Memory OLTP.

Trwałość danych i wymagania bazy

Parametr DURABILITY określa sposób zachowania danych. Wartość SCHEMA_AND_DATA oznacza, że zarówno definicja tabeli, jak i jej wiersze są utrwalane. Po restarcie SQL Server dane mogą zostać odtworzone z plików checkpoint kontenera przeznaczonych dla tabel zoptymalizowanych pod kątem pamięci. Wartość SCHEMA_ONLY utrwala definicję tabeli, ale po ponownym uruchomieniu instancji nie zachowuje jej wierszy. Ten wariant nadaje się do danych tymczasowych, buforów lub tabel pośrednich, lecz nie do informacji, które muszą przetrwać awarię procesu albo restart systemu.

Memory-Optimized Table wymaga skonfigurowanej grupy plików zoptymalizowanej pod kątem pamięci. Przykładowo bazę można rozszerzyć o plik z opcją CONTAINS MEMORY_OPTIMIZED_DATA, a dopiero potem utworzyć tabelę korzystającą z trwałości danych. Należy także sprawdzić edycję i wersję używanego SQL Server, ponieważ obsługiwane możliwości, limity oraz zgodność poszczególnych konstrukcji języka T-SQL zależą od wydania silnika. Zmiana zwykłej tabeli na tabelę zoptymalizowaną pod kątem pamięci nie jest prostą zmianą jednej właściwości; zwykle wymaga utworzenia nowej tabeli, przeniesienia danych i dostosowania zależności.

Współbieżność, indeksy i ograniczenia T-SQL

Mechanizm In-Memory OLTP ogranicza użycie tradycyjnych blokad w czasie dostępu do wierszy, wykorzystując kontrolę współbieżności opartą na wersjonowaniu i optymistycznym rozwiązywaniu konfliktów. Nie należy jednak opisywać tego jako całkowitego braku blokad. Nadal mogą wystąpić konflikty transakcji, oczekiwanie na zatwierdzenie oraz blokady dotyczące metadanych lub schematu. Przy konflikcie aktualizacji transakcja może zakończyć się błędem i wymagać ponowienia przez aplikację. Projekt rozwiązania powinien więc uwzględniać obsługę błędów transakcyjnych, a nie tylko przenieść dane do pamięci.

Indeksy definiuje się już podczas tworzenia tabeli albo zgodnie z możliwościami konkretnej wersji SQL Server. Indeks HASH jest przeznaczony przede wszystkim do wyszukiwania po pełnym kluczu równościowym. W jego definicji podaje się między innymi BUCKET_COUNT, czyli liczbę kubełków tablicy mieszającej. Zbyt mała wartość zwiększa liczbę kolizji i może pogorszyć wydajność. Indeks NONCLUSTERED obsługuje szerszy zakres predykatów, w tym wyszukiwanie zakresowe, ale również wymaga właściwego doboru klucza. Część konstrukcji znanych ze zwykłych tabel może być niedostępna albo mieć inne ograniczenia, dlatego przed migracją trzeba sprawdzić zgodność kluczy, typów danych, wyzwalaczy, kluczy obcych, zapytań i procedur.

Diagnostyka wydajności i bezpieczne użycie

Ocena Memory-Optimized Table powinna obejmować rzeczywiste obciążenie, a nie tylko czas pojedynczego zapytania uruchomionego testowo. W SQL Server można analizować metadane tabel i indeksów, plany wykonywania oraz statystyki oczekiwań i konfliktów transakcyjnych. Warto porównać liczbę operacji odczytu i zapisu, rozkład wartości klucza, częstotliwość aktualizacji tych samych wierszy oraz zużycie pamięci przez bazę. Szczególnie istotne jest sprawdzenie, czy indeks odpowiada predykatom używanym przez aplikację. Tabela trzymana w pamięci może działać gorzej od tabeli dyskowej, jeżeli ma niewłaściwy indeks, niekorzystny rozmiar kubełków albo otrzymuje zapytania wymagające nieobsługiwanych przekształceń.

Przed zastosowaniem tego mechanizmu należy oszacować ilość pamięci potrzebnej na wiersze, indeksy oraz wersje danych powstające podczas współbieżnych transakcji. Trwała tabela wymaga również poprawnie skonfigurowanej grupy plików i procedur kopii zapasowych obejmujących bazę SQL Server. Diagnostyka problemu powinna rozdzielać błędy definicji obiektu, brak zasobów pamięci, konflikty transakcji, niezgodność zapytania z ograniczeniami In-Memory OLTP oraz zwykłe problemy aplikacji, takie jak nieprawidłowe parametry lub zbyt długie transakcje. Przy każdej zmianie wskazane jest wykonanie testu odtworzeniowego i porównanie zachowania z poprzednią tabelą dyskową.