Versio

Materialized Views

Het nut van een materialized view

Gesponsorde koppelingen

Inhoudsopgave

  1. Materialized Views
  2. Het principe achter een materialized view.
  3. Maken van en opties
  4. Het nut van…
  5. De gevaren van en slot van de tutorial

 

14 reacties op 'Materialized Views'

PHP hulp
PHP hulp
0 seconden vanaf nu
 
Gesponsorde koppelingen
Klaasjan Boven
Klaasjan Boven
5 jaar geleden
 
0 +1 -0 -1
Om jullie nog een beetje een indruk te geven van een mat_view in PGsql

Code (php)
PHP script in nieuw venster Selecteer het PHP script
1
2
3
4
5
6
7
"gewone view"
SELECT count(*) FROM v_adres

1 rows fetched (2,777 sec)

count
486934


Code (php)
PHP script in nieuw venster Selecteer het PHP script
1
2
3
4
5
6
7
8
MATERIALIZED

SELECT count(*) FROM mv_adres

1 rows fetched (265 ms)

count
486934


De laatste is beduidend sneller
PHP Newbie
PHP Newbie
5 jaar geleden
 
0 +1 -0 -1
Leuke, goede, interessante tut. Top!


5 jaar geleden
 
0 +1 -0 -1
Goede tutorial, het enige wat ik eigenlijk mis is hoe je kan zien wanneer een view voor het laatst is opgebouwd.
ILoran punt NL
iLoran punt NL
5 jaar geleden
 
0 +1 -0 -1
goeie tutorial!
Frank -
Frank -
5 jaar geleden
 
0 +1 -0 -1
Leuke tut! Weer eens een echte database tutorial, leuk.

Meer informatie over materialized views in PostgreSQL kun je o.a. hier vinden: klikkerdeklik
Klaasjan Boven
Klaasjan Boven
5 jaar geleden
 
0 +1 -0 -1
@Frank ik zal de link even toevoegen bedankt
Eddy Erkelens
Eddy Erkelens
5 jaar geleden
 
0 +1 -0 -1
Goede tut. Ik had nog nooit gehoord van views, maar daar kan je zeker wat mee. Omdat het zo snel is!

Wat ik duidelijk nog mis: de MATERIALIZED VIEW komt dus niet voor bij MySQL? Je hebt het er wel even over, maar duidelijk is het niet.

Tevens mis ik af en toe wel eens hoofdletters, punten en komma's etc.
Bas Kreleger
Bas Kreleger
5 jaar geleden
 
0 +1 -0 -1
En misschien ff een praktijk gericht voorbeeld toevoegen? Want je voert die query uit en dan? Mijn vragen en wat misschien goed is om te laten zien dmv een voorbeeld:

1. Praktisch voorbeeld geven in PHP hoe je data vernieuwd
2. Hoe je vervolgens die opgeslagen data weer uitleest
Eddy Erkelens
Eddy Erkelens
5 jaar geleden
 
0 +1 -0 -1
Voer die query eens uit in phpMyAdmin oid en dan zie je dat er een extra 'tabel' ontstaat. Daaruit kan je dan gewoon je queries halen, maar dan heel simpel en zonder allerlei verbindingen. Want dat heb je al gedaan met je view.

Je kan dan (in php) gewoon SELECT * FROM view_table WHERE id = '$id' doen.
met je view heb je dan al de naam van een (eventuele) categorie erbij gezet etc.
Je voert de 'samenvoegende' query dus 1x uit en het resultaat zet je in die view.
In php open je de view. En die staat dus al klaar.
Er zijn minder mogelijkheden, maar het is wel veel sneller!
Rudie dirkx
rudie dirkx
5 jaar geleden
 
0 +1 -0 -1
Wat ik mis - en waar ik dodelijk benieuwd naar ben - is waarom VIEWS zo verschrikkelijk langzaam zijn. Om je te quoten: "De performance daalt hierdoor echter drastisch."
Que? Pourqoi?
Je zegt (ongeveer) "door indexen enzo", maar daar doe ik het niet voor. Dus: wat is het verschil? Waarom is een VIEW zo langzaam? Ik snap dat het sneller is om 1x per dag je statische view te refreshen, maar 100x per dag? Of op hele drukke sites met veel meer readen dan writen: elke minuut?
Klaasjan Boven
Klaasjan Boven
5 jaar geleden
 
0 +1 -0 -1
@T vercetti. Dit heeft te maken met de mate van normalisatie. Genormaliseerde data wil nog wel een qua performance wat minder zijn.
Als data goed genormaliseerd is is de kans op fouten stukken kleiner dan bij niet genormaliseerde data. Tevens levert genormaliseerde data zeer complexe queries op met erg veel joins. Met name dit laatste kan ten koste gaan van de performance. Als je van de lastige grote queries views maakt zodat je ze makkelijk kan bevragen en zelfs kan combineren wordt de performance minder.

Uiteraard hangt de resfresh rate af van de benodigde actualiteit van de gegevens. Voor mijn werk resfresh ik ze bijvoorbeeld 1 keer per dag om 7 uur s' morgens, althans dat doet oracle voor mij.

Een refresh kan enkele seconden tot minuten duren. Dit heeft weer te maken met de complexiteit van de bevraagde views
Frank -
Frank -
5 jaar geleden
 
0 +1 -0 -1
Een VIEW is een voorgeprogrammeerde query, dat is dus vooral handig bij complexe queries. Een materialized view bevat zelfs vooraf geselecteerde resultaten, wat de boel dus nog eenvoudiger en sneller maakt. Maar je krijgt hier pas echt voordeel van wanneer je met complexe queries in grote tot zeer grote databases zit te werken. Een paar miljoen records meer of minder zal dan niet echt meer opvallen.

Een VIEW is dus niet langzaam, de query die in de VIEW staat kan langzaam zijn.

Het gebruik van VIEW's maakt het programmeerwerk overigens ook een stuk eenvoudiger, je krijgt een betere scheiding tussen de programmeerlogica en de database. Optimaliseren van queries in een VIEW gaat ook een stuk eenvoudiger dan queries die in PHP-code zijn weggedrukt, het is 100x overzichtelijker. En veiliger, je kunt users eenvoudig de rechten toekennen of ontnemen op het gebruik van een VIEW. De rest van de database is dan een nogo area voor de users, alles via de VIEW.
Klaasjan Boven
Klaasjan Boven
4 jaar geleden
 
0 +1 -0 -1
@Webmakerij

In oracle kan je dat zo opvragen:

SELECT
NAME,
TO_CHAR(last_refresh,'DD-MM HH24:MI:SS') laatste_update,
TO_CHAR(start_with,'DD-MM HH24:MI:SS') volgende_update
FROM
USER_SNAPSHOTS
ORDER BY laatste_update;
Frank -
Frank -
4 jaar geleden
 
0 +1 -0 -1
Het implementeren van materialized views staat ook op de agenda bij PostgreSQL, zie de ToDo-lijst

Tot die tijd mag je zelf de triggers, tabellen en queries aanmaken. Leer je een hoop van, maar het gaat op een gegeven moment vervelen... ;)

Om te reageren heb je een account nodig en je moet ingelogd zijn.

  • Labels
  • Geen tags toegevoegd.