View Full Version : SQL - Materialized Query Tables
Hallo,
wir sind gerade dabei ein BI-System aufzubauen. Um relativ performant auf die Daten unserer Maschine zugreifen zu können, wollte ich die relevanten Daten über MQTs extrahieren. Allerdings ist es bei uns so, dass viele Daten über User Defined Functions (UDF) zu ermitteln sind. Jetzt scheint es aber so zu sein, dass man in MQTs keine UDFs verwenden darf. Ich erhalte zumindest immer eine diesbezügliche Fehlermeldung.
Gibt es eine Möglichkeit diese Einschränkung irgendwie zu umgehen? Oder soll ich statt der MQTs doch normale Tables erstellen? Was würdet Ihr empfehlen?
Viele Grüße,
KM
dschroeder
23-05-16, 14:29
Ob MQTs UDFs können, weiß ich nicht. Aber ich meine, MQTs können nicht automatisch live gehalten werden. Das kann nur im Abstand von ein paar Minuten geschehen, meine ich. Das hat uns immer gestört.
Die Kollegen haben bei uns ein BI System aufgebaut, indem Sie eine eigene DataWarehouse Daten-Bibliothek gebaut haben. Die wird bei uns durch permanent pollende Jobs aktuell gehalten. Mir persönlich gefällt das System aber nicht so gut. Aus heutiger Sicht würde ich versuchen, in meiner normalen Datenumgebung lieber die benötigten Werte zu cachen. Die meisten Werte kann man ja direkt per SQL holen. Einige müssen aber immer teuer berechnet werden. Ich würde versuchen, diese "teuren" Wert zu cachen. Dann kann auch die normale Datenumgebung schnell auf die Werte zugreifen.
Aber wenn du das vernünftig mit den MQTs hinbekommst, sag bitte nochmal Bescheid. Vielleicht können wir und da ja auch noch verbessern.
Dieter
andreaspr@aon.at
23-05-16, 14:48
Ob MQTs UDFs können, weiß ich nicht. Aber ich meine, MQTs können nicht automatisch live gehalten werden.
Dieses Feature des Live-Updates gibt es nur bei DB2 LUW.
Auf der IBM i dürfte der Gedanke sein, dass diese wirklich nur für Bereiche verwendet werden wo die Daten nicht aktuell sein müssen.
Hab schon paar mal mit IBM & Common Europe kommuniziert um u.a. auch dieses Feature zu bekommen. Allerdings ohne Erfolg.
Es gibt aber auch Möglichkeiten Indice mit integrierten SQL Funktionen erstellen zu lassen.
Das wäre dann so ne Art Workarround.
dschroeder
23-05-16, 15:05
Es gibt aber auch Möglichkeiten Indice mit integrierten SQL Funktionen erstellen zu lassen.
Das wäre dann so ne Art Workarround.
Geht aber nur mit integrierten Funktionen, nicht mit UDFs, oder?
Dieter
andreaspr@aon.at
23-05-16, 15:28
Stimmt, es gehen nur Funktionen wie UPPER usw.
Manchmal wird es günstiger, ein echtes BI-System einzuführen.
Dann hat man sehr viel mehr Möglichkeiten als mit Query oder Web-Query.
Zumal beim Import in ein DWH die UDF's dann verwendet werden können.
Nur so eine Frage: Sind MQTs wirklich unbedingt erforderlich?
Hast Du schon versucht mit Hilfe von Views - gesichertes (komplexes) SQL-Statement und Indices insbesondere EVI (Endocoded Vector Indices) mit Include-Anweisungen performant an die Daten zu kommen?
Hier ein Artikel zum Thema EOA (Encoded Vector Index Only Access):
Encoded-vector index (EVI) only access in IBM DB2 for i ("http://www.ibm.com/developerworks/ibmi/library/i-evi-only-access-in-ibm-db2-for-i/index.html)
Birgitta
Da es sich hier ja um die UDF's handelt gewinne ich mit Views auch nicht mehr Performance als mit den ggf. jetzt schon durchgeführten Queries da die UDF's ja in die View eingebettet werden müssen.
Um schnell auf die Daten zuzugreifen muss man hier tatsächlich regelmäßig aus den Daten neue vollständige Tabellen aufbauen. Hierbei sind natürlich weitere Gesichtspunkte aus Performancegründen zu berücksichtigen:
- muss ich immer alles neu aufbauen?
- reicht ggf. ein partieller Neuaufbau mit vorherigem Delete eines bestimmten Zeitraumes?
Ein Beispiel:
Um den Umsatz in DWH zu schieben muss ich nicht immer alles neu aufbauen. Wenn ich weiß, das z.B. max. bis zum 1. des Monats rückwärts fakturiert wird, lösche ich die Daten ab 1. des Monates und bau ab da neu auf.
Der Auftragsbestand ändert sich ja grundsätzlich und ist daher eher immer vollständig neu aufzubauen.
Das ist z.B. das Prinzip, dass ich mit unserer BI-Lösung durchführe.
Da es sich hier ja um die UDF's handelt gewinne ich mit Views auch nicht mehr Performance als mit den ggf. jetzt schon durchgeführten Queries da die UDF's ja in die View eingebettet werden müssen.
Ohne Analyse kannst Du das doch gar nicht wissen!!
Vielleicht sind die UDFs auch gar nicht der Grund, sondern fehlende Indices (Binary Radix Tree und/oder EVIs)
Vielleicht sind die UDFs nicht notwendig oder werden die Spalten mit den UDFs nicht ausgewählt.
Vielleicht können sowohl die SELECT als auch die UDFs für eine bessere Performance umgeschrieben werden (z.B. keine UDFs oder Skalaren Funktionen auf der linken Seite der Vergleichsoperatoren in den WHERE-Bedingnungen)
Birgitta
"Allerdings ist es bei uns so, dass viele Daten über User Defined Functions (UDF) zu ermitteln sind."
Nun glaube ich KM in der Hinsicht, dass er bereits geprüft hat, in wie weit seine UDF's durch native SQL's ersetzt werden können.
Sicherlich mag die eine oder andere UDF inzwischen einfacher mit scalaren Funktionen realisierbar sein, aber das steht hier ja nicht zur Debatte.
Ich kann mir auch vorstellen, dass die UDF's selber inzwischen durch Cache-Funktionen zu beschleunigen sind. Aber auch das war hier nicht die Frage.
Dazu müsste KM z.B. eine UDF beschreiben, was diese denn nun leistet.
Betrachte ich z.B. die Infor-Anwendung, so baue ich hier gerne Wrapper um bestehende Infor-Routinen die mit Native-IO irgendwas zaubern und mir ein Ergebnis liefern (z.b. Preisfindung).
Dies werde ich nie und nimmer per scalaren SQL's realisieren können.