OLTP (Online Transaction Processing) to sposób pracy bazy danych zoptymalizowany pod dużą liczbę krótkich, szybkich transakcji wykonywanych na bieżąco przez wielu użytkowników naraz. Mówiąc po ludzku: to tryb, w którym Twoja baza obsługuje zamówienia w sklepie, przelewy w banku, dodawanie produktu do koszyka czy rezerwację biletu — operacje, które dotykają kilku wierszy, muszą się wykonać w milisekundach i zdarzają się tysiące razy na minutę.
Jak to działa i do czego służy
Systemy OLTP są projektowane wokół pojęcia transakcji — niepodzielnej paczki operacji, która albo wykonuje się w całości, albo wcale. Pilnują tego właściwości ACID (Atomicity, Consistency, Isolation, Durability), żeby przy 500 osobach kupujących ten sam ostatni bilet nie sprzedać go dwa razy. Dane trzyma się zwykle w postaci silnie znormalizowanej (mało powtórzeń, dużo tabel połączonych kluczami), bo celem jest szybki zapis i punktowe odczyty pojedynczych rekordów, a nie liczenie sum z milionów wierszy.
To właśnie odróżnia OLTP od OLAP (Online Analytical Processing). OLTP odpowiada na pytanie „dodaj to zamówienie i zaktualizuj stan magazynu”, a OLAP na „ile sprzedaliśmy butów w Q3 w podziale na regiony”. Pierwsze ma być błyskawiczne i częste, drugie potrafi mielić dane minutami i działa na hurtowni danych.
Przykład z praktyki
Załóżmy, że stawiasz sklep na PostgreSQL. Złożenie zamówienia to klasyczna transakcja OLTP — w jednej paczce zdejmujesz stan magazynowy i tworzysz rekord zamówienia:
BEGIN;UPDATE products SET stock = stock - 1 WHERE id = 42 AND stock > 0;INSERT INTO orders (user_id, product_id) VALUES (7, 42);COMMIT;
Jeśli cokolwiek pójdzie nie tak między BEGIN a COMMIT, robisz ROLLBACK i baza wraca do stanu sprzed operacji. Klient nie zobaczy zamówienia na produkt, którego już nie ma.
Częste błędy i mity
Najpopularniejsza wpadka juniora to puszczanie ciężkich raportów analitycznych (GROUP BY po całych tabelach, joiny po milionach wierszy) bezpośrednio na produkcyjnej bazie OLTP. Efekt: blokady, wydłużone transakcje i sklep, który nagle zwisi w godzinach szczytu. Od tego są repliki do odczytu albo osobna hurtownia (OLAP). Drugi mit: że „baza to baza”. To ten sam silnik (np. PostgreSQL czy MySQL) potrafi pracować w obu trybach, ale schemat, indeksy i strojenie pod OLTP i OLAP wyglądają zupełnie inaczej.
Pojęcia powiązane
OLAP, transakcja, ACID, normalizacja, indeks bazodanowy, hurtownia danych (data warehouse), ETL, replika do odczytu.