Re: Der Umgang mit der Objektart: DOMAIN
Verfasst: Mo 6. Apr 2020, 10:32
Wie ich eingangs schon beschrieb löse ich komplexe SQL's in parallele Einzelschritte auf.
Wenn du mit dem Konzept "CTE" und "Derived Table" bekannt bist, erklärt sich das nahezu von selbst.
In der BI-Welt (Business-Intelligence) bedarf es komplexer Abfrage von u.U. zig Tabellen zu einem großen Gesamtergebnis.
Der Nachteil bei Joins, ins besonders Gruppierungen, ist, dass kaum Indizes verwendet werden können.
Beispiel (simplifiziert):
with T1 as (
select k1, k2, sum(f1) f1
from Tab1
where ...
group by K1, K2
)
,T2 as (
select ka1, ka2, avg(f2) f2
from Tab2
group by ka1, ka2
)
select * from T1
inner join T2 on k1 = ka1 and k2 = ka2
Dies wird von mir nun zerlegt in
create table tempt1 ...
create index tempt1i1 on tempt1 (k1, k2)
create table tempt2
create index tempt2i1 on tempt2 (ka1, ka2)
insert into tempt1
select .... // Select 1 von oben
insert into tempt2
select ... // Sleect 2 von oben
//Final
select * from tempt1
inner join tempt2 on k1=ka1 and k2=ka2
Dies bedarf 2er paralleler Verbindungen. Je nach Komplexität gibt es eben bis zu 8 parallele Ausführungen.
Das Erstellen der Tabellen und Indizes dauert weniger als 1 Sekunde (durch Domains).
Die jeweiligen Selects können Indizes verwenden, da die Basistabellen passende Indizes haben (auch diese werden i.Ü. von mir nach Bedarf erstellt).
Der Final-Select bring die Daten dann in die Auswertung.
Zum Schluss gibts dann 2 "Drop Table", die übrigens die Indizes gleich mit löschen.
Das Hauptproblem bei der Betrachtung (betrifft übrigens jede DB) ist, dass CTE's tatsächlich keine echten Tabellen erstellen.
Verknüpft man wie oben 2 Gruppierte Ergebnisse, wird "von links nach rechts" abgearbeitet:
T1 wird nach Index (falls vorhanden) oder natural verarbeitet und gruppiert.
Dann wird je Gruppe aus T1 die passende Gruppe aus T2 ermittelt, wobei das bei Indexverwendung aus T1 u.U. auch direkt passiert.
Und dies kann da schon mal etwas länger dauern, ins besonders, wenn es für T2 keinen passenden Index gibt.
Durch die schrittweise Zerlegung und Bildung passender Indizes wird das Ergebnis z.T. drastisch beschleunigt.
Vor allem dann, wenn auf Grund der Aufgabenstellung auch schon mal gerne 20 - 30 Tabellen im Kontext verarbeitet werden.
Einen "order by" verwende ich grundsätzlich nicht mehr, da eine Sortierung i.d.R. durch den Frontend (z.B. Grid, Pivot) sowieso durch den User gesteuert wird.
In der BI-Branche wird da gerne mit vordefinierte Würfeln (Cubes) gearbeitet, die die Arbeitslast vorneweg nehmen. Leider kann das schnell unflexibel werden, da jede Veränderung (Feld dazu) eine komplette Neuberechnung erfordert.
Hinzu kommt, dass die Berechnung von Cubes auch schon mal gerne länger als 24 Stunden dauert und man somit nie auf aktuellen Zahlen eine Auswertung bekommt.
Wenn du mit dem Konzept "CTE" und "Derived Table" bekannt bist, erklärt sich das nahezu von selbst.
In der BI-Welt (Business-Intelligence) bedarf es komplexer Abfrage von u.U. zig Tabellen zu einem großen Gesamtergebnis.
Der Nachteil bei Joins, ins besonders Gruppierungen, ist, dass kaum Indizes verwendet werden können.
Beispiel (simplifiziert):
with T1 as (
select k1, k2, sum(f1) f1
from Tab1
where ...
group by K1, K2
)
,T2 as (
select ka1, ka2, avg(f2) f2
from Tab2
group by ka1, ka2
)
select * from T1
inner join T2 on k1 = ka1 and k2 = ka2
Dies wird von mir nun zerlegt in
create table tempt1 ...
create index tempt1i1 on tempt1 (k1, k2)
create table tempt2
create index tempt2i1 on tempt2 (ka1, ka2)
insert into tempt1
select .... // Select 1 von oben
insert into tempt2
select ... // Sleect 2 von oben
//Final
select * from tempt1
inner join tempt2 on k1=ka1 and k2=ka2
Dies bedarf 2er paralleler Verbindungen. Je nach Komplexität gibt es eben bis zu 8 parallele Ausführungen.
Das Erstellen der Tabellen und Indizes dauert weniger als 1 Sekunde (durch Domains).
Die jeweiligen Selects können Indizes verwenden, da die Basistabellen passende Indizes haben (auch diese werden i.Ü. von mir nach Bedarf erstellt).
Der Final-Select bring die Daten dann in die Auswertung.
Zum Schluss gibts dann 2 "Drop Table", die übrigens die Indizes gleich mit löschen.
Das Hauptproblem bei der Betrachtung (betrifft übrigens jede DB) ist, dass CTE's tatsächlich keine echten Tabellen erstellen.
Verknüpft man wie oben 2 Gruppierte Ergebnisse, wird "von links nach rechts" abgearbeitet:
T1 wird nach Index (falls vorhanden) oder natural verarbeitet und gruppiert.
Dann wird je Gruppe aus T1 die passende Gruppe aus T2 ermittelt, wobei das bei Indexverwendung aus T1 u.U. auch direkt passiert.
Und dies kann da schon mal etwas länger dauern, ins besonders, wenn es für T2 keinen passenden Index gibt.
Durch die schrittweise Zerlegung und Bildung passender Indizes wird das Ergebnis z.T. drastisch beschleunigt.
Vor allem dann, wenn auf Grund der Aufgabenstellung auch schon mal gerne 20 - 30 Tabellen im Kontext verarbeitet werden.
Einen "order by" verwende ich grundsätzlich nicht mehr, da eine Sortierung i.d.R. durch den Frontend (z.B. Grid, Pivot) sowieso durch den User gesteuert wird.
In der BI-Branche wird da gerne mit vordefinierte Würfeln (Cubes) gearbeitet, die die Arbeitslast vorneweg nehmen. Leider kann das schnell unflexibel werden, da jede Veränderung (Feld dazu) eine komplette Neuberechnung erfordert.
Hinzu kommt, dass die Berechnung von Cubes auch schon mal gerne länger als 24 Stunden dauert und man somit nie auf aktuellen Zahlen eine Auswertung bekommt.