Firebird V3.0 - Neue Aggregatfunktionen

[lowmax_5]

Vielen Dank für die Antworten. Da hatte ich mir doch wohl ein wenig zu viel Hoffnungen in die neuen Aggregatsfunktionen gesteckt... Da sehr viele Datensätze durchgegangen werden müssen und die Performance nicht entsprechend gut ist, muss ich dann wohl konzeptionell anders vorgehen (==>OLAP).

[tsteinmaurer]

Was heißt sehr viel je Tabelle und wie lange dauert die Abfrage?

[mkinzler]

Du kannst zuerst Joinen und zusammenfassen (langsam) oder schauen, ob die zuerst zusammenfasst und dann die Daten kombinierst ( im Idealfall schneller)

[lowmax_5]

Zitat:

Was heißt sehr viel je Tabelle und wie lange dauert die Abfrage?

In der Praxis ist das Thema komplexer als in dem von mir genannten Beispiel. Innerhalb einer SP werden neben Joins auch Sub-SP's aufgerufen, um die notwenigen Daten zusammenzustellen. Die Laufzeit beträgt ca. 1 Minute aber auch mehr, wobei es auf einige Tabellen zwischen 200T und 22Mio IR's gibt. Alles ist soweit optimiert, das es nur sehr wenige NIR's gibt.

Da die Datenmenge auf jeden Fall durchlaufen werden muss, um die Werte zu ermitteln, komme ich wohl um das Thema OLAP/Aggregatstabellen nicht herum, um auch bei varierenden Fragestellungen eine AdHoc-Abfragen in einer akzeptablen Zeit beantworten zu können. Würde es hier noch andere Lösungswege geben?

[tsteinmaurer]

Zitat:

Würde es hier noch andere Lösungswege geben?

Nein. Für analytische (Ad-Hoc) Fragestellungen bei wachsendem OLTP Datenvolumen wirst in Richtung Voraggregrierung etc. gehen müssen. Wennst für das OLAP System auf Firebird oder relational bleiben willst, dann hilft dir vielleicht folgender Artikel von mir weiter: https://www.ibphoenix.com/resources/.../general/doc_1

[mkinzler]

Interessanter Artikel

[lowmax_5]

Zitat:

Wennst für das OLAP System auf Firebird oder relational bleiben willst, dann hilft dir vielleicht folgender Artikel von mir weiter: https://www.ibphoenix.com/resources/.../general/doc_1

Das hört sich schon mal sehr gut an! Wenn ich es richtig verstehe, werden die Daten (mit einer Update-Strategie) 'vorbereitet' und in die DWH-Tabellenstruktur gepackt. Anschliessend können diese dann 'zeitnah' angerufen werden.(alles mit FB) Mondrian als OLAP-Server untersützt dabei den Anwender, die Abfragen zu generieren - es würde aber auch ohne den OLAP-Server gehen, wenn die Abfragen vorher feststehen bzw. definiert werden.
Korrigiere mich bitte, falls ich auf dem Holzweg bin ...

[tsteinmaurer]

Zitat:

Korrigiere mich bitte, falls ich auf dem Holzweg bin ...

Nene, das hast du vollkommen richtig verstanden. Das Ganze ist schon 5 Jahre her, d.h. ich weiss nicht was jetzt bzgl. Mondrian (ist ja mittlerweile im Pentaho Dunstkreis reingewandert) der aktuellste Stand ist, aber im Wesentlichen bietet dir Mondrian als ROLAP-Server (relationaler OLAP Server) eine Art multidimensionale Sicht auf relationale Daten. Ein (Ad-Hoc) Olap-Client sendet MDX (Multidimensional Expressions) Abfragen, die von der Syntax her ähnlich zu SQL sind, an den OLAP Server, der konvertiert das in SQL und greift auf das RDBMS zu und sendet die Daten zum OLAP-Client zurück. Der OLAP Server macht halt dann auch noch Caching etc ....

Wenn deine Zugriffswege/Abfragen via SQL absteckt sind, spricht nichts dagegegen die Voraggregierung auf diese Anforderungen hinzutrimmen und direkt auf das OLAP Datenmodell im RDBMS auszuführen.

LG