OLAP vs OLTP: două workload-uri diferite, două scheme diferite

OLTP (online transaction processing) și OLAP (online analytical processing) nu sunt tehnologii diferite, ci două moduri fundamental diferite de a folosi o bază de date. OLTP este optimizat pentru tranzacții scurte, frecvente și consistente: comenzi, plăți, actualizări de stoc. OLAP este optimizat pentru query-uri lungi și agregări: dashboard-uri, rapoarte săptămânale, analize pe istoricul complet al datelor.

Confuzia apare pentru că amândouă trăiesc frecvent în același Postgres și arată similar din exterior. Diferența se vede în schemă, în tipul de indecși, și în ce se strică când le amesteci necontrolat.

Ce este OLTP (online transaction processing) mai exact?

OLTP înseamnă un sistem proiectat pentru tranzacții scurte, izolate și frecvente. Fiecare tranzacție afectează un număr mic de rânduri, trebuie să fie rapidă (sub câteva sute de milisecunde), și trebuie să garanteze consistența datelor chiar dacă mai mulți utilizatori scriu simultan.

Caracteristicile unui sistem OLTP:

• Scrieri frecvente. INSERT, UPDATE și DELETE sunt operații de zi cu zi, nu excepții. Schema este normalizată pentru a face aceste scrieri eficiente și consistente.
• Tranzacții scurte. O tranzacție durează milisecunde, nu minute. Postgres garantează ACID per tranzacție; dacă ceva eșuează la mijloc, rollback-ul aduce baza de date înapoi la starea consistentă.
• Multe cereri concurente. Sute sau mii de utilizatori pot scrie simultan. Blocările (locks) trebuie să fie scurte și granulare; un lock pe tabel întreg omoară performanța OLTP.
• Schema normalizată. Fiecare informație există o singură dată. Dacă schimbi prețul unui produs, îl schimbi într-un singur rând, nu în mii de comenzi.

Exemple tipice de sisteme OLTP: un magazin online (comenzi, plăți, stocuri), o aplicație de rezervări (disponibilitate, rezervări, anulări), o aplicație SaaS cu conturi de utilizatori.

Ce este OLAP (online analytical processing) și prin ce diferă?

OLAP înseamnă un sistem proiectat pentru query-uri analitice: agregări pe milioane de rânduri, filtre pe intervale de timp, grupări pe dimensiuni multiple. O interogare OLAP tipică poate scana zeci de milioane de rânduri și poate dura secunde sau minute.

Prin ce diferă față de OLTP:

• Citiri masive, scrieri rare. Query-urile OLAP scanează volume mari de date. Scrierile sunt de obicei batch-uri nocturne sau periodice, nu tranzacții continue.
• Latență acceptabilă. Un raport săptămânal care durează 10 secunde este acceptabil. Un query de checkout care durează 10 secunde nu.
• Schema denormalizată (star sau snowflake). Pentru a evita JOIN-uri multiple la citire, OLAP folosește scheme plate cu redundanță controlată. O tabelă centrală de fapte (comenzi, evenimente, sesiuni) este legată direct la tabele de dimensiuni (produse, clienți, perioade).
• Agregări și grupări. SUM, AVG, COUNT, GROUP BY sunt operații centrale. OLAP este despre rezumate, nu despre rânduri individuale.

Exemple tipice de sisteme OLAP: un pipeline de date care alimentează dashboard-uri de business intelligence, un raport de vânzări pe regiuni și categorii, analiza comportamentului utilizatorilor pe o perioadă lungă.

Care sunt diferențele de schemă (normalizat vs star/snowflake)?

Schema este cel mai vizibil punct de divergență între OLTP și OLAP. Același set de date despre comenzi arată diferit în funcție de workload-ul țintă.

În OLTP, schema este normalizată: tabela de comenzi conține un product_id și un customer_id ca chei străine. Dacă vrei numele produsului sau adresa clientului, faci JOIN. Avantajul: scrierile sunt simple și consistente. Dezavantajul: query-urile analitice cer JOIN-uri multiple care devin lente la milioane de rânduri.

În OLAP, schema tip star schema denormalizează intenționat: tabela centrală de fapte conține direct product_name, product_category, customer_city și alte atribute care în OLTP ar fi în tabele separate. Structura arată ca o stea: tabela de fapte în centru, tabelele de dimensiuni legate radial.

Snowflake schema este o variantă a star schema unde tabelele de dimensiuni sunt normalizate mai departe. De exemplu, categoria produsului are propria tabelă, nu e un câmp direct în tabela de dimensiuni a produselor. Reducerea redundanței vine cu JOIN-uri suplimentare la citire.

• Star schema: JOIN-uri simple (fapte la dimensiuni), query-uri analitice rapide, redundanță mai mare în date.
• Snowflake schema: redundanță redusă, dar JOIN-uri mai complexe și query-uri mai lente pentru cazul analitic tipic.
• Normalizat (3NF): ideal pentru OLTP, greu de interogat analitic la volum mare.

Schimbările de schemă în sisteme de producție sunt gestionate prin instrumente de migrare controlată ca Liquibase, care aplică modificările incremental și trackează versiunea schemei în baza de date.

Cum împărțim workload-urile pe RestoInsights?

RestoInsights gestionează peste 24 de milioane de înregistrări reîmprospătate noapte de noapte¹. La acest volum, amestecarea necontrolată a workload-urilor OLTP și OLAP în aceleași tabele devine rapid o problemă.

Separarea naturală: partea operațională (inserturi și update-uri zilnice) rămâne pe calea normalizată a sistemului OLTP. Partea analitică (rapoarte săptămânale, dashboard-uri de tendințe, agregări pe perioade lungi) operează pe date materializate, astfel încât query-urile grele nu blochează inserțiile operaționale.

Disciplina pe care o aplicăm la decizia despre un data warehouse dedicat este aceeași: nu adăugăm unul înainte să avem dovezi că Postgres cu materializare nu mai ține. Monitorizarea timpilor de răspuns prin stack-ul de observabilitate ne spune când a sosit momentul. Pentru orchestrarea automatizărilor și a alertelor folosim n8n, iar pasul de la o separare logică OLTP/OLAP la un layer analitic separat fizic îl facem cu dovezi din monitorizare, nu preventiv.

Care este capcana cea mai frecventă când le confunzi?

Cele mai comune probleme apar când un query analitic greoi rulează direct pe baza de date operațională, sau când o schemă OLAP suportă scrieri OLTP frecvente. Ambele situații degradează performanța, dar în moduri diferite și greu de diagnosticat rapid.

• Query OLAP pe baza operațională. Un raport care face SELECT COUNT(*), SUM(valoare) FROM comenzi GROUP BY luna pe tabela operațională activă blochează sau îngreunează inserțiile și update-urile normale. La volume mari, un singur query de raport poate crește latența operațiunilor de zi cu zi cu sute de milisecunde. Soluția: materializezi datele analitice periodic (noapte sau orar) sau le replici pe un nod de citire dedicat.
• Scrieri OLTP frecvente în schema OLAP. Dacă ai construit un star schema și încerci să faci insert pentru fiecare eveniment operațional în timp real, denormalizarea devine o problemă: actualizezi redundant date în zeci de locuri simultan. Schema OLAP nu este concepută pentru scrieri concurente frecvente.
• Indecși greșiți pentru workload. OLTP vrea indecși pe coloanele de căutare punctuală (ID-uri, chei externe); OLAP vrea indecși parțiali sau columnar storage. Un tabel cu toți indecșii de OLTP aplicați pe un workload OLAP are scrierile lente și câștigă puțin la citire.
• Absența rate limiting pe query-uri analitice. Un utilizator care declanșează manual rapoarte grele pe baza operațională poate consuma toată capacitatea de I/O. Chiar dacă sistemul nu are un strat OLAP separat, query-urile analitice ar trebui să aibă un canal separat sau un mecanism de throttling.
• Migrarea schemei fără să planifici pentru ambele workload-uri. O migrare care adaugă coloane sau indecși pentru analize poate bloca tabelele OLTP la volume mari. Rulezi migrările în ferestre de mentenanță sau cu tehnici de migrare non-blocantă; Liquibase gestionează ordinea și tranzacționalitatea schimbărilor, dar decizia de timing îți aparține.

Capcana rădăcină este că performanța pare acceptabilă pe volume mici. Cele două workload-uri coexistă fără probleme pe câteva mii de rânduri; la câteva milioane, divergența devine inacceptabilă. Momentul sepării nu este "de la început" sau "niciodată", ci "când monitorizarea arată că ai o problemă reală".

1. RestoInsights gestionează 24 de milioane+ de înregistrări, cu refresh nocturn din pipeline-urile de date. [resto.records_count]