[vz-dev] Performance - Umstellung DB Schema

[Andreas Goetz]

Hi Jakob, all,

2015-10-05 15:16 GMT+02:00 Jakob Hirsch <jh at plonk.de>:

> Hi!
>
> Andreas Goetz wrote on 2015-10-02 10:49:
> > ich beobachte aktuell ein paar Probleme mit der Performance bei Nutzung
> > der Aggregation Root Cause scheint darni zu bestehen dass alle Anfragen
> > auf die Aggregationstabelle ziemlich aufwändig Unix Timestamps (sec) in
> > VZ Timestamps (ms) hin- und herrechnen müssen.
>
> Diese "VZ"-Timestamps waren im Nachhinein wohl keine so gute Idee. Man
> brauchte aber sub-second-Auflösung und Javascript möchte die Timestamps
> sowieso in diesem Format. Ansonsten hätte man double oder so benutzen
> und jeden Wert multiplizieren müssen (in der Middlware beim GET oder im
> Frontend).
>

Die Multiplikation vor/nach JSON tut gar nicht so weh- richtig weh tut dass
wir zwischendurch beim Zugriff auf die Aggregationstabelle _alle_ Werte mit
durchmultiplizieren müssen (Idee parken ;).

> Wenn wir- das wäre der Vorschlag- unser DB Schema auf Unix Timestamps
> > umstellen können und auf Sekundenauflösung gehen dann würden wir eine
>
> Nein, damit gäbe es große Abweichungen bei der Leistung. Selbst wenn man
> nur einen Impuls alle 10 bis 11 Sekunden hat, wäre der Fehler im
> Extremfall 10%.
>

Guter Punkt!

>
> Neuere MySQL/MariaDB-Versionen können aber auch timestamps mit
> fractional seconds, evt. wäre das eine bessere Lösung.
>

Muss ich anschauen. Gibts das schon auf Jessie?


> > Für das API liesse sich das transparent halten oder- das wäre eigentlich
>
> Dann mußt du aber auch mit MUL/DIV arbeiten...
>

Wie gesagt- einmalig tut das nichtmal weh.


> > mein Vorschlag- wir stellen auch das API auf Sekunden um. Der Change
> > würde die Kompatibilität von vzlogger bis zu jedem Client beeinflussen.
>
> Das ist m.E. bei der Menge an benutzen Clients (insbesondere der
> Net-IOs, auch wenn man die m.E. eher nicht benutzen sollte) ein no-go.
>

Ok.


> Andere möglichkeit wäre eine Erweiterung der API: ts bleibt
> JS-timestamp, tsX (mit irgendwas sinnvollem für X) wären fractional.
>
>
Ich überlege gerade:

1) entweder... statt ms in der DB etwas mit Faktor 1024 zu speichern- dann
könnte man wenigstens shiften statt zu rechnen
2) gefällt mir grad sehr gut... in der Aggregate Tabelle noch eine
TIMESTAMP Spalte hinzuzufügen.

Bei 2) bliebe die Quellauflösung der Daten gleich und nur für besonders
schnelle Abfragen, bei Bedarf auf auf Sekunden aggregiert, würden wir
wirklcih allen Overhead rausnehmen.

Das muss ich mir mal anschauen...

Viele Grüße,
Andreas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://demo.volkszaehler.org/pipermail/volkszaehler-dev/attachments/20151005/eb621621/attachment.html>