Ich habe eine Anwendung, bei der eine recht rechenaufwendige View genutzt wird, um Daten auszuwerten. Updates der zugrundeliegenden Tabellen und Auswertung erfolgen meist blockweise, d.H. es gibt Zeiten mit vielen INSERTs/UPDATEs auf den Basistabellen und Zeiten mit vielen SELECTs auf der View.
Es muß sichergestellt werden, daß die View bei Abfrage immer aktuell ist, aber aus Performancegründen wird auch die Materialisierung zwingend gebraucht.
Die für mich beste weil transparenteste Lösung wäre eine “lazy refreshed materialized View”, die automatisch bei jedem SELECT refreshed wird, wenn sich die Basisdaten seit dem letzten refresh verändert haben. So würde der Refresh bei einem Block von Abfragen höchstens einmal ausgelöst und Updates würden ebenfalls nicht ausgebremst.
Postgresql scheint das von Haus aus erstmal nicht anzubieten.oder überseh ich da was? Mit Oracle war das möglich (wobei es da auch noch inkrementelle refreshs gibt, aber das ist jetzt mal nicht soo wichtig).
Die nächste Idee war deshalb, Trigger zu nutzen:
INSERT/UPDATE/DELETE-Trigger auf den Basistabellen setzen ein “dirty” Flag, das signalisiert daß die View nicht mehr aktuell ist.
Ein weiterer Trigger auf der Materialized View prüft dieses “dirty”-Flag. ist es gesetzt, soll der passende REFRESH MATERIALIZED VIEW abgesetzt und dann das Flag gelöscht werden. Dieser Trigger müßte vor jedem SELECT laufen.
Leider scheint aber auch hier Postgres immer ein entscheidendes Feature zu fehlen. Die nicht vorgesehenen Trigger auf materialized Views könnte man ja noch umschiffen, indem man auf die Materialized View eine “normale” View draufsetzt. Aber es gibt scheinbar kein “SELECT” Trigger Event !? - kann man das vielleicht über Rules erzeugen?
Welche Möglichkeiten gibt es, diese Aufgabe transparent umzusetzen, also so, daß die Anwendung möglichst nichts davon wissen muß?
Folgende Ansätze möchte ich ausschließen:
-
Refresh im Update-Trigger der Basistabelle. Macht Aktualisierungen der Basisdaten inakzeptabel langsam.
-
regelmäßiger Refresh über einen Timer-Job o.ä… Birgt die Gefahr daß Abfragen veraltete Daten liefern, deshalb inakzeptabel.
-
Auslösung des Refresh durch den Client-. Produziert inakzeptables Risiko von Fehlern durch Nichtausführung und würde u.U. Eingriffe in Programme erfordern, die nicht geändert werden können/sollen (z.B. weil zugekauft) .