Materialized Views
Door Klaasjan Boven, 20 jaar geleden, 6.831x bekeken
Het nut van een materialized view
Gesponsorde koppelingen
Inhoudsopgave
- Materialized Views
- Het principe achter een materialized view.
- Maken van en opties
- Het nut van…
- De gevaren van en slot van de tutorial
Er zijn 14 reacties op 'Materialized views'
0 
-0 
-0
Om jullie nog een beetje een indruk te geven van een mat_view in PGsql
De laatste is beduidend sneller
Code (php)
1
2
3
4
5
6
7
2
3
4
5
6
7
"gewone view"
SELECT count(*) FROM v_adres
1 rows fetched (2,777 sec)
count
486934
SELECT count(*) FROM v_adres
1 rows fetched (2,777 sec)
count
486934
Code (php)
1
2
3
4
5
6
7
8
2
3
4
5
6
7
8
MATERIALIZED
SELECT count(*) FROM mv_adres
1 rows fetched (265 ms)
count
486934
SELECT count(*) FROM mv_adres
1 rows fetched (265 ms)
count
486934
De laatste is beduidend sneller
0 -0
-0
Goede tutorial, het enige wat ik eigenlijk mis is hoe je kan zien wanneer een view voor het laatst is opgebouwd.
0 -0
-0
Leuke tut! Weer eens een echte database tutorial, leuk.
Meer informatie over materialized views in PostgreSQL kun je o.a. hier vinden: klikkerdeklik
Meer informatie over materialized views in PostgreSQL kun je o.a. hier vinden: klikkerdeklik
0 -0
-0
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.
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.
0 -0
-0
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
1. Praktisch voorbeeld geven in PHP hoe je data vernieuwd
2. Hoe je vervolgens die opgeslagen data weer uitleest
0 -0
-0
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!
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!
0 -0
-0
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?
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?
0 -0
-0
@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
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
0 -0
-0
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.
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.
0 -0
-0
@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;
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;
0 -0
-0
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... ;)
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.
Inhoudsopgave
- Materialized Views
- Het principe achter een materialized view.
- Maken van en opties
- Het nut van…
- De gevaren van en slot van de tutorial
PHP hulp
0 seconden vanaf nu