[vz-dev] Performance - Umstellung DB Schema

[Andreas Goetz]

Und ich nochmal...

2015-10-05 15:48 GMT+02:00 Andreas Goetz <cpuidle at gmail.com>:

> Hi Jakob, all,
>
> ..
>
> 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.
>

Ich hab das Ganze (2) mal auf nem Raspi1 mit 200tsd Datensaätzen getract:

SELECT SQL_NO_CACHE UNIX_TIMESTAMP(FROM_UNIXTIME(MIN(timestamp) / 1000,
"%Y-%m-%d %H:00:00")) * 1000
FROM aggregate WHERE
channel_id=4 AND type=2
AND UNIX_TIMESTAMP(FROM_UNIXTIME(timestamp / 1000, "%Y-%m-%d %H:00:00")) *
1000 >= 1441370700000;
//-- ca. 1.5sec

ALTER TABLE aggregate ADD unix_timestamp TIMESTAMP;
UPDATE volkszaehler.aggregate SET unix_timestamp =
FROM_UNIXTIME(timestamp/1000);
ALTER TABLE aggregate ADD UNIQUE ts_uniq2 (channel_id, type,
unix_timestamp);
SELECT * FROM volkszaehler.aggregate;

SELECT SQL_NO_CACHE
UNIX_TIMESTAMP(FROM_UNIXTIME(MIN(UNIX_TIMESTAMP(unix_timestamp)), "%Y-%m-%d
%H:00:00")) * 1000
FROM aggregate
WHERE channel_id=4 AND type=2
AND FROM_UNIXTIME(UNIX_TIMESTAMP(unix_timestamp), "%Y-%m-%d %H:00:00") >=
FROM_UNIXTIME(1441370700000 / 1000);
//-- ca. 0.8sec

SELECT SQL_NO_CACHE
UNIX_TIMESTAMP(FROM_UNIXTIME(MIN(UNIX_TIMESTAMP(unix_timestamp)), "%Y-%m-%d
%H:00:00")) * 1000
FROM aggregate
WHERE channel_id=4 AND type=2
AND unix_timestamp >= FROM_UNIXTIME(1441370700000 / 1000);
//-- immediate

Ein echter Sekunden-Timestamp ist immer noch langsam da mit Datumsformaten
rumhantiert werden muss. Wenn optimiert dann müssten die Intervallgrenzen
direkt in die aggregate Tabelle geschrieben werden. Die Spalte würde dann
also nicht unix_timestamp sondern period_start heissen. Timestamp wird
weiter benötigt da der exakte Timestamp für die Leistungsberechnung an den
Intervallgrenzen notwendig ist.

Schuld war übrigens dieser PR:
https://github.com/volkszaehler/volkszaehler.org/pull/335/files

Long story short: lässt sich mit Erweiterung der Aggregate Tabelle und
etwas Hirnschmalz beheben ohne die Auflösung zu verändern. Hässlich an den
Timestamps ist die hin- und her konvertiererei nur bei Zeitumstellung da
FROM_UNIXTIME(UNIX_TIMESTAMP(unix_timestamp) nicht eineindeutig ist.

@Gernot: damit wissen wir auch warum's bei Dir plötzlich langsamer geworden
ist- keine weiteren Tests notwendig!

Viele Grüße,
Andreas



> 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/0cfc8c96/attachment.html>