In memory OLTP poajwiło się w SQL server wraz z SQL 2014. Ogólnie rzecz biorąc przebudowano zasady przechowywania wierszy ze znanych nam drzew na ciagi dacych umieszczone w pamięci, a co za tym idzie również zupełnie zmieniono niepodważalne do tej pory święte zasady pracy z danymi, jak np. blokowanie rekordów, które tutaj nie występuje, Ładnie opisuje to cały cykl artykułów na MS SQL Tips:
https://www.mssqltips.com/sqlservertip/3121/getting-started-with-sql-server-2014-inmemory-oltp/
https://www.mssqltips.com/sqlservertip/3106/sql-server-2014-inmemory-oltp-architecture-and-data-storage/
Dwie rzeczy (co najmniej) były tu jednak niepokojące:
1. Czy dane umieszczone w RAM nie uciekną po wyłączeniu SQL?
2. Wiele znanych konstrukcji SQL i elementów SQL nie mogło być używanych z In memory OLTP.
Odpowiedź na pierwsze pytanie stanowi opcja DURABILITY. Ustawienie jej na SCHEMA_AND_DATA powoduje, że transakcje przechodzą w standardowy sposób przez log transakcyjny, a dane i struktura tabeli jest na stałe zapisywana na dysk.
Z drugim problemem było znacznie gorzej. Masz tabelę ale zapomnij o kluczach obcych, indeksie unikalnym, zapytaniach z UNION, OUTER JOIN itp. I oto pojawił się SQL 2016, a wraz z nim:
- Maksymalny rozmiar tabeli 2 TB (poprzednio 250 GB)
- Row Level Security
- ALTER PROCEDURE działajaće dla procedur skompilowanych do kodu natywnego
- ALTER TABLE zadziała blokując jednak na chwilę altywność użytkowników zmienianej tabeli
- TDE
- FOREIGN KEY / CHECK / UNIQUE / NULL w kolumnach klucza / NVARCHAR(MAX)
- UNION / OUTER JOIN / SELECT DISTINCT / OR / NOT / EXISTS / TVF (Table Valued Functions) / Triggery …
Dodatkowo poprawiono też Garbage Collector. Odzyzkiwanie pamięci rozpoczyna się już na etapie pojedynczej transakcji, a co minutę specjalny proces dodatkowo zwalnia to, co nie jest już potrzebne.
Podsumowując – chyba w SQL 2014 trochę się pośpieszono z wypuszczeniem „pół produktu”. In memory OLTP w SQL 2016 wygląda na dość normalną w użyciu technologię.
