Materialized view: ce este, când o folosești, costul de refresh

O materialized view este un obiect de bază de date care stochează pe disc rezultatul unui query SQL, spre deosebire de un view obișnuit care re-execută query-ul la fiecare accesare. Rezultatul este disponibil ca o tabelă normală, cu indecși proprii, fără costul recalculării la fiecare cerere.

Postgres a introdus suport nativ pentru materialized views în versiunea 9.3. De atunci, comanda REFRESH MATERIALIZED VIEW a devenit instrumentul standard pentru actualizarea datelor stocate. Principala tensiune operațională este între prospețimea datelor (freshness) și costul de refresh: cu cât materializezi mai agresiv, cu atât plătești mai mult în compute și, potențial, în lock-uri pe tabelele sursă.

Ce este o materialized view mai exact?

O materialized view este un query salvat al cărui rezultat este scris fizic pe disc, ca o tabelă independentă. Spre deosebire de un view obișnuit, care este doar o definiție SQL re-executată la fiecare SELECT, materialized view-ul răspunde la interogări din datele stocate, fără să acceseze tabelele sursă în timp real.

Crearea este similară unui view clasic:

CREATE MATERIALIZED VIEW vanzari_lunare AS
  SELECT
    DATE_TRUNC('month', data_comanda) AS luna,
    SUM(valoare_totala) AS total
  FROM comenzi
  GROUP BY 1;

Odată creată, interogarea SELECT * FROM vanzari_lunare nu mai atinge tabela comenzi. Actualizarea datelor se face explicit:

REFRESH MATERIALIZED VIEW vanzari_lunare;
-- sau, fără blocare a lecturilor:
REFRESH MATERIALIZED VIEW CONCURRENTLY vanzari_lunare;

Pe materialized view-uri se pot crea indecși ca pe orice tabelă, ceea ce le face utile pentru query-uri analitice cu filtre frecvente pe coloane specifice.

Care e diferența față de un view obișnuit?

Un view obișnuit este o rețetă SQL re-executată la fiecare cerere. Dacă query-ul sursă face join pe cinci tabele și calculează agregări pe milioane de rânduri, fiecare SELECT pe acel view parcurge tot lanțul. View-ul este întotdeauna proaspăt, dar costul se plătește la fiecare interogare.

O materialized view este rezultatul acelei rețete, stocat pe disc. Interogarea este rapidă pentru că nu mai recalculează nimic: datele sunt deja acolo, cu eventualii indecși construiți deasupra. Prețul plătit este că datele pot fi stale: reflectă starea tabelelor sursă la momentul ultimului REFRESH, nu starea curentă.

• View obișnuit. Proaspăt întotdeauna, dar re-execută query-ul la fiecare accesare. Potrivit pentru query-uri simple sau pentru date accesate rar.
• Materialized view. Rapidă la citire, dar stale între refresh-uri. Potrivită pentru query-uri costisitoare accesate des, unde o fereastră de staleness este acceptabilă.
• Tabelă cu populare manuală. Control maxim, complexitate maximă: tu scrii logica de actualizare. Util când ai nevoie de refresh parțial sau de logică de transformare complexă pe care un REFRESH standard nu o acoperă.

Alegerea nu este permanentă: o materialized view poate deveni o tabelă normală dacă pattern-ul de actualizare devine prea complex, sau poate fi înlocuită cu un data warehouse dedicat când volumul depășește ce poate ține un singur Postgres.

Ce strategii de refresh există (full, incremental, concurrent)?

Postgres standard oferă un singur mod de refresh complet (full refresh): recalculează tot query-ul sursă și înlocuiește conținutul materialized view-ului. Simplu de implementat, dar costisitor la tabele mari, și cu două variante de blocare:

• REFRESH standard. Pune un lock exclusiv pe materialized view pe durata recalculării. SELECT-urile pe view sunt blocate complet. Acceptabil pentru refresh-uri nocturne sau pentru view-uri accesate rar, inacceptabil pentru date servite în timp real.
• REFRESH CONCURRENTLY. Permite SELECT-urile să continue în timp ce refreshul rulează. Necesită un UNIQUE INDEX pe materialized view (fără el comanda eșuează). Durează mai mult decât refresh-ul standard, pentru că Postgres compară intern versiunea veche cu cea nouă și aplică doar diferențele.

Refresh-ul incremental, care actualizează doar rândurile modificate față de ultimul refresh, nu există nativ în Postgres. Există mai multe abordări manuale:

• Triggers pe tabelele sursă. La fiecare INSERT, UPDATE sau DELETE, un trigger actualizează un tabel de diferențe (delta). Un proces separat aplică delta-ul periodic. Complex de menținut când query-ul sursă are join-uri sau agregări.
• Append-only. Dacă tabela sursă crește doar prin inserturi, adaugi la materialized view doar rândurile noi, bazat pe un câmp timestamp sau ID monoton. Potrivit pentru tabele de evenimente.
• Change Data Capture. Folosind change data capture, captezi evenimentele din WAL-ul Postgres și le aplici pe un strat analitic separat, fără triggers.

Când are sens să materializăm date în loc să interogăm la fiecare cerere?

Materializarea are sens atunci când costul re-executării query-ului la fiecare cerere devine mai mare decât costul menținerii unei copii stale și al refresh-ului periodic. Câteva indicii practice:

• Query-ul face GROUP BY sau JOIN pe milioane de rânduri și durează secunde, nu milisecunde.
• Datele sunt citite mult mai des decât sunt actualizate, iar o fereastră de staleness (ore sau zile) este acceptabilă.
• Query-urile analitice concurează cu query-urile operaționale pe aceleași tabele și degradează latența tranzacțiilor normale.

Materializarea disciplinată este una dintre tehnicile prin care Postgres rămâne suficient pentru workload-uri OLAP la volume medii, fără să fie nevoie de un data warehouse separat. Aceasta este perspectiva descrisă în intrarea despre OLAP vs OLTP, unde separăm workload-urile analitice de cele operaționale pe RestoInsights, care gestionează peste 24 de milioane de înregistrări reîmprospătate noapte de noapte.¹ Decizia de a adăuga un layer analitic separat se ia cu dovezi din monitorizare, nu preventiv.

Materializarea nu rezolvă toate problemele de performanță. Dacă query-ul sursă este scris greșit (lipsesc indecși, join-uri carteziene accidentale), refresh-ul va fi lent indiferent de strategie. Optimizezi mai întâi query-ul sursă, materializezi după ce confirmi că query-ul în sine este eficient.

Care sunt capcanele operaționale (lock-uri, freshness, cost de storage)?

Problemele operaționale ale materialized views sunt mai puțin evidente decât cele ale tabelelor obișnuite, dar apar constant în producție:

• Lock-uri la refresh fără CONCURRENTLY. Un REFRESH MATERIALIZED VIEW standard blochează tot accesul la view pe durata recalculării. La tabele sursă mari sau la query-uri complexe, refresh-ul poate dura minute. Dacă view-ul este accesat de o aplicație în timp real, lock-ul devine un incident. Soluția imediată este adăugarea unui UNIQUE INDEX și trecerea la CONCURRENTLY.
• Staleness nedetectat. Dacă refresh-ul eșuează în tăcere (cron care pică, conexiune resetată), aplicația servește date vechi fără avertizare. Adaugă un câmp refreshed_at și alertează prin stack-ul de observabilitate când data depășește fereastra acceptată.
• Storage dublu neplanificat. Fiecare materialized view stochează o copie completă a datelor, plus indecsii. La join-uri care expandează volumul sursă, o materialized view poate fi mai mare decât tabelele sursă combinate. Estimează dimensiunea înainte să creezi în producție.
• Dependențe în cascadă. O materialized view bazată pe altă materialized view (MV pe MV) creează o ierarhie de refresh-uri care trebuie executate în ordine. Dacă ierarhia este implicită, o schimbare de schemă la sursă poate sparge în tăcere o parte din lanț. Documentează explicit ordinea refresh-urilor și gestionează schema cu Liquibase pentru a forța vizibilitatea dependențelor.
• Index-uri uitate după DROP și recreare. Dacă ștergi și recreezi o materialized view (pentru a schimba query-ul sursă), indecsii se pierd. Orice script de recreare trebuie să includă și comenzile CREATE INDEX. Un materialized view fără indecsii care erau așteptați produce query-uri de patru-cinci ori mai lente, greu de diagnosticat fără un distributed tracing sau slow query log activ.

Capcanele de mai sus nu sunt motive să eviți materialized views: sunt motive să le instrumentezi corect de la început, cu refresh monitorizat, indecși documentați și dependențe explicite. Ca orice optimizare de baze de date, beneficiul vine cu responsabilitate operațională.

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