Jedna baza danych, dwa obciążenia, wiele problemów: OLTP kontra OLAP, str. 1

Do transakcji w czasie rzeczywistym potrzebujesz jednego rodzaju systemu — OLTP (Online Transaction Processing). Do analiz potrzebujesz innego — OLAP (Online Analytical Processing). OLTP jest jak Sonic z kreskówek: zawsze w ruchu, pędzi do przodu z pełną prędkością, reaguje natychmiast na przeszkody i zbiera pierścienie po drodze. OLTP przetwarza każdą transakcję szybko i przewidywalnie. OLAP natomiast jest bardziej jak Kirby — wciąga wszystko na swojej drodze: sterty obiektów, wrogów, całe światy. Systemy OLAP pochłaniają ogromne ilości danych — miliony i miliardy wierszy — aby później je przetworzyć i przekształcić w coś sensownego, np. raport.

A ponieważ przypadki użycia są tak różne, logiczne jest, że różnią się również architektura serwerów, systemy przechowywania danych, a nawet silniki baz danych.

Tutaj przechodzimy do sedna. W tym długim artykule omówimy OLAP, OLTP i sprzęt, który je obsługuje.

OLAP i OLTP: czym są i dlaczego istnieją

Zagłębmy się nieco w technologię.

OLAP i OLTP mają zupełnie różne cele i architektury. Dlatego dla większości firm prawdziwe pytanie nie brzmi „wybrać jedno czy drugie”, ale „jak właściwie je połączyć w jednej infrastrukturze”.

OLAP to narzędzie do skomplikowanej analizy dużych wolumenów danych. To sposób, w jaki firmy uzyskują znaczące informacje analityczne. Weźmy na przykład handel detaliczny artykułami spożywczymi: zespół analityczny zbiera wszystkie dane sprzedażowe za dany okres z wielu źródeł — baz operacyjnych, usług zewnętrznych i innych systemów. Wszystkie te dane są następnie ładowane do specjalistycznego systemu przechowywania — hurtowni danych — zoptymalizowanej pod kątem analizy wielowymiarowej.

Następnie analitycy uruchamiają zapytanie:
„Ile masła i chleba sprzedano w czerwcu 2024 we wszystkich sklepach w danym regionie, jak te liczby zmieniły się w czerwcu 2025 i jaki jest związek między tymi produktami?”

Odpowiedź na takie pytanie wymaga agregowania milionów wierszy, filtrowania danych według regionów, kategorii i dat, a następnie obliczania korelacji, zmian i prognoz. Takie zapytania mogą trwać długo — w granicach rozsądku — i jest to całkowicie normalne, ponieważ wyniki są wykorzystywane do podejmowania decyzji biznesowych i określania strategii długoterminowej.

W OLAP ważniejsza jest kompletność i dokładność niż natychmiastowy czas odpowiedzi. Dlatego strategiczne analizy — roczne raporty lub prognozy długoterminowe — mogą trwać godzinę lub dwie. Inaczej wygląda sytuacja, gdy operacyjne analizy do codziennych decyzji, np. zmiany cen, zajmują godziny — to zwykle znak nieodpowiedniej infrastruktury.

W rdzeniu OLAP znajdują się wielowymiarowe struktury danych (kostki), które pozwalają oglądać dane z różnych perspektyw — według czasu, regionu, produktu, klienta i dziesiątek innych wymiarów. To czyni OLAP idealnym narzędziem do analiz strategicznych. W przeciwieństwie np. do systemów CRM, których głównym celem jest operacyjne zarządzanie klientem i transakcjami, a nie skomplikowane zapytania na terabajtach historycznych danych sprzedażowych.

Klasyczne narzędzia OLAP to ClickHouse, Greenplum, Hadoop/Spark i Amazon Redshift. Są zaprojektowane do przetwarzania na dużą skalę i równoległości.

OLTP natomiast jest zaprojektowany pod kątem szybkości przetwarzania pojedynczych operacji. Na kasie w supermarkecie każda transakcja — zeskanowanie produktu, przyjęcie płatności, zapisanie rekordu — musi odbywać się natychmiast. Każde opóźnienie oznacza rosnące kolejki i opuszczających klientów. Nikt nie będzie czekał trzy minuty, żeby kupić masło i chleb.

Systemy OLTP są zoptymalizowane właśnie pod szybkie, częste, operacje w czasie rzeczywistym. Używanie ich do analiz strategicznych jest niemal bezcelowe — skomplikowane zapytania na ogromnych zbiorach danych po prostu nie są ich domeną.

Typowe bazy OLTP to PostgreSQL, MySQL/InnoDB, Oracle Database i Microsoft SQL Server.

Istnieją też rozwiązania hybrydowe — HTAP (Hybrid Transactional/Analytical Processing) — które próbują połączyć transakcje i analitykę w jednym systemie, np. TiDB, SAP HANA czy YugabyteDB. W praktyce jednak większość firm nadal rozdziela obciążenia: jedna baza obsługuje szybkie operacje, druga analitykę. Wygoda systemów hybrydowych wiąże się z większą złożonością infrastruktury i wyższymi wymaganiami sprzętowymi.

I tutaj zaczynają się pytania ze strony architektów IT, administratorów lub innych odpowiedzialnych osób. Który serwer powinien być użyty do OLAP, a który do OLTP? Czy powinny to być osobne serwery? Maszyny wirtualne? Klaster? A może węzły obliczeniowe w połączeniu z osobnym przechowywaniem? Ile systemów przechowywania jest potrzebnych? Jeśli kilka, to aktywne-aktywne czy aktywne-pasywne? I to dopiero początek — są dziesiątki, jeśli nie setki, podobnych szczegółów.

A te szczegóły bezpośrednio wpływają na biznes.

Nie dam rady odpowiedzieć na każde możliwe pytanie — każde obciążenie jest inne — ale postaram się podać przydatne punkty odniesienia. Jak zawsze, komentarze są otwarte.

Jak wybrać serwery i pamięć dla OLTP i OLAP

Dobór serwerów dla OLTP i OLAP to dwa zupełnie różne zadania, a błędy są kosztowne. Umieść wolne dyski pod OLTP, a otrzymasz kolejki zapytań i niezadowolonych klientów. Uruchom OLAP na nieodpowiednich serwerach, a zapytania będą się wykonywać tygodniami. Oszczędzanie na redundancji danych i komponentów… wiadomo, jak to się skończy.

W systemach baz danych o dużym obciążeniu wydajność i niezawodność zależą bezpośrednio od architektury i sprzętu. Ale przed zakupem sprzętu najpierw przychodzą decyzje architektoniczne. Zaczniemy od OLTP.

Architektura OLTP: prędkość i przewidywalność

Systemy OLTP są frontem biznesu. Bankowość internetowa, bramki płatności i platformy e-commerce działają na nich. Te systemy mają jasno określone wymagania: dziesiątki lub setki tysięcy transakcji na sekundę, ścisłe SLA opóźnień mierzone w milisekundach i integralność danych — utrata pojedynczego rekordu transakcji jest równoznaczna z utratą pieniędzy.

Każdy system transakcyjny jest budowany wokół wymagań ACID (Atomicity, Consistency, Isolation, Durability). W prostych słowach:

• Transakcja jest wykonywana w całości lub wcale (Atomicity),

• Dane pozostają w spójnym stanie (Consistency),

• Operacje równoległe nie zakłócają się nawzajem (Isolation),

• Dane nie są tracone nawet w przypadku awarii (Durability).

Patrząc na taki system, architekt IT nie zaczyna od myślenia o sprzęcie. Główne kwestie to: jak znormalizować dane, aby transakcje były szybkie i spójne; jak rozłożyć obciążenie w klastrach przy użyciu shardingu i replikacji; jak zaprojektować odporność na awarie, aby awaria jednego — a nawet kilku — węzłów nie zatrzymała całego systemu.

Wnioski:
Jeśli liczy się prostota i przewidywane obciążenie jest umiarkowane, optymalny jest zestaw replikacji i cache — np. PostgreSQL lub MySQL z Redis. Gdy wolumen danych rośnie i obciążenie wzrasta liniowo, a ścisła globalna spójność nie jest krytyczna, lepiej sprawdzają się architektury shared-nothing z shardingiem. Jeśli priorytetem jest ścisła spójność — i budżet na to pozwala — lepsze są rozwiązania shared-disk, jak Oracle RAC. Dla systemów wymagających ekstremalnej prędkości przetwarzania lub analityki w czasie rzeczywistym warto rozważyć bazy danych in-memory.

Poniżej podsumowałem główne podejścia architektoniczne stosowane przy projektowaniu systemów OLTP.

Wniosek jest prosty. Jeśli zoptymalizujesz OLTP jak OLAP, zabijesz opóźnienia. Jeśli uruchomisz OLAP na infrastrukturze OLTP, analitycy będą patrzeć na paski postępu zamiast na pulpity. Błędy architektoniczne nie pojawiają się w benchmarkach — pojawiają się w utraconych przychodach, naruszonych SLA i bardzo niekomfortowych spotkaniach.