Otimierung SQL Abfrage oder Logik

[haentschman]

Hallöle...

Ich bräuchte mal ein paar Tipps zur Optimierung. Außerdem redet ja sonst keiner mit mir...

Gegeben:
* Datentabelle mit 3,5 Mio Datensätzen
* In der Datentabelle sind nur die Werte gespeichert wenn sie sich ändern. Bsp. Value 5,6,7,5,4 - Value 5,5,6,6,6,6,7,7,5,5,4 gibts nicht.
* Gewählter Zeitraum für die SQL Abfrage zum Beispiel letzte 24 Stunden.
* Es gibt 2 Modi: Anzeige der Daten im kompletten Zeitraum (Bild1) bzw. nur die vorhandenen Daten (Bild 2)
* Es kann vorkommen das die vorhandenen Daten nicht den gesamten Zeitraum abdecken. Das passiert z.B. wenn das Gerät ausgeschaltet war und keine Daten aufgezeichnet hat. Dazu generiere ich mir in der Komplettansicht für jede Serie einen Anfangs und Endwert der aus dem vorhergehenden vorhandenen Datensatz besteht. Darin besteht der Flaschenhals.

* Ein Thread holt die Daten für jede Serie nacheinander ab und füllt damit für jede Serie getrennte Liste. (incl. evt. generiertem Anfang und Ende)
In diesem Beispiel würde die Abfrage auf den vorhergehenden Wert 12 Mal durchgeführt werden. Ob "Kerndaten" vorhanden sind oder nicht. Jede dieser Abfragen benötigt im Durchschnitt 70ms. Da bedeutet das incl. Transport (100ms rechnet sich besser ) 1,2 Sekunden nur für die "Berechnung" flöten gehen. Dass gefällt mir nicht wirklich...

Soll:
* Ideen für Optimierung ohne Komplettumbau... Letztendlich komme ich wahrscheinlich nicht um eine SQL Abfrage herum weil ich mir die Ergebnisse nicht anderweitig "Merken" kann. Über eine SP, die mir die Values listet, denke ich schon nach. Die muß aber die Werte auch aus der DB generieren...

SQL:
Beide Abfragen bringen die korrekten Ergebnisse. Der komplette Join (wäre schön) liegt nur 10ms drüber.

komplett mit Join

Code:

select first (1) D.F_PARAMETER_ID, D.F_TIMESTAMP_UNIX, D.F_POWER_STATE, D.F_VALUE, T.F_TYPE_ID from T_RECORD_DATA D
join T_DEVICE_PARAMETERS P on P.ID = D.F_PARAMETER_ID
join T_MEASURE_TYPES T on T.ID = P.F_MEASURE_TYPE_ID
where D.F_PARAMETER_ID = 1060 and D.F_TIMESTAMP_UNIX < 1449737313
order by F_TIMESTAMP_UNIX desc

vereinfacht

Code:

select first (1) F_TIMESTAMP_UNIX, F_VALUE from T_RECORD_DATA D
where F_PARAMETER_ID = 1060 and F_TIMESTAMP_UNIX < 1449737313
order by F_TIMESTAMP_UNIX desc

[HeZa]

Ich werde daraus nicht ganz schlau. ?-)

Das FIRST (1) läßt mich schaudern, ließt du jeden Datenpunkt deines Diagramms einzelnd? Das wäre Fatal.

[haentschman]

Danke...

Prinzipiell geht es um die gerade horizontale Linie die du im Chart rechts siehst. Der Chart kann die nur zeichnen bzw. die X-Achse breit ziehen wenn der letzte "Datumswert" den Wert des letzten vorhergehenden Wertes hat.
Die Abfrage dient nur dazu EINEN und zwar den letzten vor einem bestimmten Timestamp abzufragen. Deshalb First(1) und desc... Das gruslige daran ist das der Server immer erst alle Daten vor dem Zeitpunkt lesen muß um den EINEN zurückzugeben. Das geht durch den desc Index trotzdem erstaunlich schnell. Mich stört das ich in der Summe der Abfragen Zeit einbüße...

Zitat:

ließt du jeden Datenpunkt deines Diagramms einzelnd?

...Das wäre allerdings Selbstmo... Wenn der User, auch wenn es bescheuert ist, sich alle Daten darstellen will kommen in diesem Beispiel pro Serie rund 60000 also 360000 Werte zusammen. Das ganze dauert mit Darstellung 12 Sekunden. Selbst das wäre akzeptabel. Gerade bei den "wenig" Daten stört mich der Overhead der "Berechnung" der vorhergehenden Werte.

Nachtrag: Tsss... den letzten habe ich mir auch ausgelesen. Dabei entspricht das genau dem letzten Datensatz der "Kerndaten". Den habe ich ja schon. Ich muß nur einen holen wenn gar keine "Kerndaten" vorhanden sind. Am Anfang komme ich aber nicht drum herum...

Da hab ich doch eine Idee. Um die gerade Linie auf die "0" Linie zu ziehen bräuchte ich ja jeweils einen Datenpunkt des Anfanges und der ersten Daten (Equivalent am Ende) zu füttern. Das würde die Werteabfrage per SQL obsolet machen. Dann wären halt keine Linien in der "Mitte"...

[haentschman]

Moin...

Na bitte geht doch. Ich habe jetzt jeweils den ersten bzw. letzten Datensatz der "Kerndaten" für Beginn und Ende benutzt. Das erspart die SQL Abfragen. Nur im Extremfalle wenn keine Kerndaten vorhanden sind wird Anfang und Ende aus der DB geholt...

Schön das wir drüber geredet haben...

[Dejan Vu]

Ich habe zwar nicht genau verstanden, was Du willst, aber ich denke, Du hast einzelne Abschnitte und willst die irgendwie erkennen.

Datenbanken sollten imho immer so aufgebaut werden, das die Kernfunktionen und -abfragen performant umgesetzt werden sollten. Hier ist eine Kernabfrage die Sache mit den Abschnitten (wenn ich das richtig verstanden habe).

Du solltest eine Tabelle mit den expliziten Abschnitten pflegen. Dann geht die Abfrage viel schneller. Diese Tabelle könnte immer dann geupdated (oder upgedatet?) werden, wenn ein neuer Abschnitt beginnt (beim Ausschalten ist das ja ein wenig spät ). Beim Einschalten sucht man sich einmalig das Ende des letzten Abschnittes, trägt es in die Tabelle ein und danach den Anfang (nämlich 'jetzt') das neuen Abschnittes. So hast Du deine 70ms verteilt (nämlich bei der Datenerfassung).

Oder habe ich das Problem komplett falsch verstanden?

[haentschman]

Danke für deine Anteilnahme...

Zitat:

Oder habe ich das Problem komplett falsch verstanden?

Ja leider...aber nicht schlimm. Den Erklärbär hab ich schon wegen Hilfe kontaktiert...

Das Problem ist nicht die Datenbank sondern die Anzeige bei Anzeigezeitraum größer als Datenzeitraum der vorhandenen Daten. Um diese waagerechten Striche der Serien (Anfang und Ende) zu bekommen benötigt man einen Datenpunkt am Anfang Anzeigezeitraum und Ende Anzeigezeitraum. Diese Werte hatte ich aus der DB ermittelt. Auch wenn die einzelne Anweisung schnell war brachte die Summe der Abfragen einen blöden Overhead. Das habe ich jetzt so gelöst, das ich schon geladene Daten verwende als immer die Werte neu zu ermitteln.