In-Memory OLTP (Hekaton)

📖 Zašto In-Memory?

Standardne tabele (disk-based) pate od latencije diska i "lock contention-a" (zaključavanja redova dok ih drugi procesi čitaju). Kod ekstremnih zahtjeva (stotine hiljada transakcija po sekundi), standardna arhitektura dostiže limit. In-Memory OLTP uvodi potpuno novi Lock-free engine koji podatke drži isključivo u RAM-u, koristeći optimistični concurrency control.

🏗️ Arhitektura bez zaključavanja

Za razliku od standardnih tabela, In-Memory tabele:

• Nemaju Latch-eve i Lock-ove: Čitaoci nikada ne blokiraju pisce, i obrnuto.
• Native Compilation: Stored procedure se kompajliraju direktno u C kod (DLL), izbjegavajući T-SQL interpreter.
• Novi Storage: Podaci se na disk zapisuju u vidu "Append-only" log fajlova (Checkpoint files), a ne u standardne 8KB stranice.

📊 Tipovi In-Memory Tabela

-- Prvo nam treba Filegroup za In-Memory podatke
ALTER DATABASE MyDatabase ADD FILEGROUP IM_FG CONTAINS MEMORY_OPTIMIZED_DATA;
GO

CREATE TABLE Web.UserSession (
    SessionID UNIQUEIDENTIFIER PRIMARY KEY NONCLUSTERED,
    UserID INT NOT NULL,
    LoginTime DATETIME2 NOT NULL
) 
WITH (MEMORY_OPTIMIZED = ON, DURABILITY = SCHEMA_ONLY);
GO

⚡ Nativno Kompajlirane Stored Procedure

To su procedure kreirane sa klauzulom NATIVE_COMPILATION. One su do 100x brže od običnih procedura jer se kompajliraju direktno u mašinski kod (C kod) umjesto da se interpretiraju kroz T-SQL engine.

Kako Native Compilation Radi?

Kada kreirate nativno kompajliranu stored procedure:

1. Kompajliranje: SQL Server kompajlira procedure u DLL (Dynamic Link Library) fajl
2. Optimizacija: Kod se optimizuje na najnižem nivou - direktno mašinski kod
3. Učitavanje: DLL se učitava u memoriju SQL Server procesa
4. Izvršavanje: Procedure se izvršava direktno bez T-SQL interpretacije

CREATE PROCEDURE Web.usp_AddSession
    @SessionID UNIQUEIDENTIFIER, 
    @UserID INT
WITH NATIVE_COMPILATION, SCHEMABINDING
AS 
BEGIN ATOMIC WITH (
    TRANSACTION ISOLATION LEVEL = SNAPSHOT, 
    LANGUAGE = N'us_english'
)
    INSERT INTO Web.UserSession (SessionID, UserID, LoginTime)
    VALUES (@SessionID, @UserID, SYSDATETIME());
END;
GO

-- Napomena: 
-- - NATIVE_COMPILATION: Kompajlira u mašinski kod
-- - SCHEMABINDING: Obavezno za native procedure
-- - BEGIN ATOMIC: Sve mora biti u atomic bloku
-- - SNAPSHOT isolation: Obavezno za In-Memory tabele

Prednosti Native Compilation

• Brzina: 10-100x brže od običnih stored procedura
• Nema interpretacije: Direktno izvršavanje mašinskog koda
• Optimizacija: Kompajler optimizuje kod na najnižem nivou
• Memorija: Kod se učitava jednom i ostaje u memoriji

Nedostaci Native Compilation

• Ograničenja: Ne možete koristiti sve T-SQL konstrukte
• Kompleksnost: Zahtijeva striktnu sintaksu
• Debugging: Teže je debug-ovati native procedure
• Fleksibilnost: Manje fleksibilne od običnih procedura

🎯 Praktična Vježba: Uništavanje uskih grla

CREATE TABLE dbo.HighSpeedLogs (
    LogID INT IDENTITY(1,1) PRIMARY KEY NONCLUSTERED,
    LogMsg NVARCHAR(100) NOT NULL,
    LogDate DATETIME2 NOT NULL INDEX IX_LogDate HASH WITH (BUCKET_COUNT = 100000)
) WITH (MEMORY_OPTIMIZED = ON);
GO

-- BUCKET_COUNT je ključan za performanse Hash indeksa (treba biti cca 2x broj redova).

✅ Zaključak

In-Memory OLTP nije za sve podatke, već za uska grla:

• ✅ SCHEMA_ONLY tabele su brže od bilo kojeg Redis cache-a u istom serveru.
• ✅ Native SP eliminiraju overhead interpretacije SQL-a.
• ✅ Hash indeksi omogućavaju O(1) brzinu pretrage (direktan skok na podatak).