Gematerialiseerde view (materialized view)

Wat is een gematerialiseerde view?

Een gematerialiseerde view is een query waarvan het resultaat vooraf berekend en opgeslagen wordt, zodat je het niet telkens opnieuw hoeft te berekenen. De databank bewaart de uitkomst als een echte tabel op schijf. Vraag je de view op, dan lees je gewoon dat opgeslagen resultaat.

Het contrast met een gewone view maakt het duidelijk. Een gewone view is enkel een opgeslagen query: elke keer je ze bevraagt, draait die query opnieuw op de onderliggende tabellen. Handig om een ingewikkelde query een naam te geven, maar qua werk verandert er niets. Een gematerialiseerde view draait de query één keer en bewaart de uitkomst. Lezen wordt daardoor veel sneller, maar de data is een momentopname: ze klopt zoals bij de laatste berekening, niet noodzakelijk zoals nu.

Vergelijk het met een rapport dat je maandelijks uitdraait en op je bureau legt. Wie een cijfer nodig heeft, pakt het blad en heeft meteen antwoord. Het blad is alleen zo vers als de dag dat je het uitdraaide.

Wanneer gebruik je een gematerialiseerde view?

De typische aanleiding is een zware aggregatie of join die traag is en die veel mensen bevragen, meestal de query achter een dashboard.

Een voorbeeld. Je toont de omzet per regio per dag, en dat cijfer wordt honderd keer per dag opgevraagd door verschillende collega's. Bereken je het telkens opnieuw, dan draait dezelfde optelling over miljoenen rijen honderd keer. Met een gematerialiseerde view reken je het één keer uit, en die honderd bevragingen lezen allemaal hetzelfde opgeslagen resultaat. Zolang een cijfer van vanmorgen volstaat, is dat pure winst.

De afweging zit in versheid tegenover snelheid. Je ruilt actualiteit in voor leessnelheid en wat extra opslag. Voor cijfers die niet elke seconde hoeven te kloppen, zoals dag- of weekrapportering, is dat bijna altijd een goede ruil. Voor data die live moet zijn, is het net geen optie.

Gematerialiseerde view versus verwante aanpakken

Een gematerialiseerde view is niet de enige manier om lezen te versnellen. Het helpt om te weten waar ze verschilt van de buren.

Tegenover een gewone view

Een gewone view bewaart alleen de query en geeft altijd de actuele data, want ze rekent elke keer opnieuw. Een gematerialiseerde view bewaart de uitkomst: sneller te lezen, maar verouderd tot de volgende verversing. De keuze gaat dus recht over de vraag of je verse cijfers of snelle cijfers wil.

Tegenover een index

Een index versnelt het opzoeken binnen een tabel, maar berekent niets vooraf: de databank moet de som of de join nog altijd zelf maken, alleen vindt ze de juiste rijen sneller. Een gematerialiseerde view slaat het rekenwerk zelf op. Voor een zware aggregatie die telkens hetzelfde antwoord geeft, wint de gematerialiseerde view; voor het gericht terugvinden van enkele rijen is een index de juiste keuze. Het zijn allebei manieren om lezen te versnellen ten koste van iets anders.

Tegenover een tabel in je pijplijn wegschrijven

Je kan het resultaat ook zelf berekenen en als tabel wegschrijven in je datapijplijn. Het effect is hetzelfde: een opgeslagen uitkomst. Het verschil zit in wie het beheert. Bij een gematerialiseerde view regelt de databank de verversing en weet ze dat de tabel van een query afgeleid is. Een tabel die je zelf wegschrijft, moet je zelf onderhouden en op tijd verversen.

Waar kom je gematerialiseerde views tegen?

Je komt het idee in meerdere databases en lakehouse-platformen tegen, maar de naam en de manier van verversen verschillen sterk.

PostgreSQL heeft echte materialized views. Je maakt ze aan en ververst ze zelf met een expliciet commando. Tot dat commando draait, blijft de data een momentopname. Dit is de zuiverste vorm: jij bepaalt wanneer ze bijgewerkt wordt.

SQL Server heeft indexed views. Zodra je een unieke clustered index op een view zet, wordt het resultaat fysiek opgeslagen en mee onderhouden bij wijzigingen aan de brontabellen. Dat maakt lezen sneller, maar schrijven kan duurder worden. De query-optimizer kan zo'n indexed view in bepaalde gevallen zelfs gebruiken zonder dat je ze rechtstreeks aanspreekt.

In de analytische wereld zie je hetzelfde patroon. Microsoft Fabric heeft materialized lake views die resultaten opslaan als lakehouse-tabellen en automatisch verversen volgens hun lineage. Databricks kent materialized views die je handmatig of gepland kan verversen, met incrementele refresh wanneer de query en brondata dat toelaten. En op modelniveau doet de Import-modus van Power BI iets verwants: de data wordt vooraf ingeladen en gecomprimeerd bewaard in VertiPaq, zodat rapporten snel lezen in plaats van live te berekenen.

Omdat het gedrag per systeem verschilt, vooral rond hoe en wanneer de view ververst wordt, loont het om de documentatie van jouw databank er even bij te nemen.

Waar moet je op letten bij het gebruik van een gematerialiseerde view

• Versheid tegenover snelheid. Zolang je de view niet ververst, lees je oude cijfers. Bij de soort die je zelf moet verversen is dat het grootste risico: een dashboard dat vlot oogt maar stiekem gisteren toont. Spreek expliciet af hoe vers de cijfers moeten zijn.

• De verversing kost tijd en rekenkracht. Ververs je een zware view elk uur, dan draait die zware berekening ook elk uur. Bij grote volumes helpt incrementeel verversen, waarbij enkel de gewijzigde data bijgewerkt wordt, maar niet elk systeem of elke query kan dat.

• Ze neemt opslag in. Je bewaart een tweede kopie van het resultaat. Voor één aggregatie is dat verwaarloosbaar, voor tientallen brede views telt het op.

• Automatisch bijgewerkt betekent tragere schrijfacties. Bij systemen die de view live bijhouden, zoals een indexed view in SQL Server, betaal je bij elke wijziging aan de brontabellen. Op een druk transactioneel systeem is dat een echte afweging.

FAQ over gematerialiseerde views

1. Wat is het verschil met een gewone view?
Een gewone view bewaart alleen de query en rekent elke keer opnieuw, dus ze is altijd actueel. Een gematerialiseerde view bewaart de uitkomst als tabel: sneller te lezen, maar verouderd tot ze ververst wordt.

2. Is de data altijd up-to-date?
Dat hangt van het systeem af. In PostgreSQL moet je zelf verversen, en tot dan is de data een momentopname. Een indexed view in SQL Server wordt mee onderhouden bij schrijfacties. Fabric en Databricks hangen af van hun refreshmechanisme, planning en queryvorm. Verifieer het altijd bij de documentatie van jouw platform.

3. Wanneer krijg ik hier als KMO mee te maken?
Vaak zonder dat je het beseft. Een gematerialiseerde view is dikwijls de oplossing die je datapartner voorstelt voor een rapport dat te traag geworden is: het zware rekenwerk wordt één keer gedaan in plaats van bij elke opvraging.

4. Is dit hetzelfde als een index?
Nee. Een index helpt de databank de juiste rijen sneller vinden, maar het rekenwerk gebeurt nog steeds. Een gematerialiseerde view bewaart het resultaat van dat rekenwerk. Ze lossen elk een ander stuk traagheid op.