<div dir="ltr">Und ich nochmal...<br><div class="gmail_extra"><br><div class="gmail_quote">2015-10-05 15:48 GMT+02:00 Andreas Goetz <span dir="ltr"><<a href="mailto:cpuidle@gmail.com" target="_blank">cpuidle@gmail.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Hi Jakob, all,<br><div class="gmail_extra"><br><div class="gmail_quote">..<span></span></div><br></div><div class="gmail_extra">Ich überlege gerade:<br><br></div><div class="gmail_extra">1) entweder... statt ms in der DB etwas mit Faktor 1024 zu speichern- dann könnte man wenigstens shiften statt zu rechnen<br></div><div class="gmail_extra">2) gefällt mir grad sehr gut... in der Aggregate Tabelle noch eine TIMESTAMP Spalte hinzuzufügen. <br><br></div><div class="gmail_extra">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.<br></div></div></blockquote><div><br></div><div>Ich hab das Ganze (2) mal auf nem Raspi1 mit 200tsd Datensaätzen getract:<br><br>SELECT SQL_NO_CACHE UNIX_TIMESTAMP(FROM_UNIXTIME(MIN(timestamp) / 1000, "%Y-%m-%d %H:00:00")) * 1000 <br>FROM aggregate WHERE <br>channel_id=4 AND type=2 <br>AND UNIX_TIMESTAMP(FROM_UNIXTIME(timestamp / 1000, "%Y-%m-%d %H:00:00")) * 1000 >= 1441370700000;<br>//-- ca. 1.5sec<br><br>ALTER TABLE aggregate ADD unix_timestamp TIMESTAMP;<br>UPDATE volkszaehler.aggregate SET unix_timestamp = FROM_UNIXTIME(timestamp/1000);<br>ALTER TABLE aggregate ADD UNIQUE ts_uniq2 (channel_id, type, unix_timestamp);<br>SELECT * FROM volkszaehler.aggregate;<br><br>SELECT SQL_NO_CACHE UNIX_TIMESTAMP(FROM_UNIXTIME(MIN(UNIX_TIMESTAMP(unix_timestamp)), "%Y-%m-%d %H:00:00")) * 1000<br>FROM aggregate <br>WHERE channel_id=4 AND type=2 <br>AND FROM_UNIXTIME(UNIX_TIMESTAMP(unix_timestamp), "%Y-%m-%d %H:00:00") >= FROM_UNIXTIME(1441370700000 / 1000);<br>//-- ca. 0.8sec<br><br>SELECT SQL_NO_CACHE UNIX_TIMESTAMP(FROM_UNIXTIME(MIN(UNIX_TIMESTAMP(unix_timestamp)), "%Y-%m-%d %H:00:00")) * 1000<br>FROM aggregate <br>WHERE channel_id=4 AND type=2 <br>AND unix_timestamp >= FROM_UNIXTIME(1441370700000 / 1000);<br>//-- immediate<br><br></div><div>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.<br><br></div><div>Schuld war übrigens dieser PR: <a href="https://github.com/volkszaehler/volkszaehler.org/pull/335/files">https://github.com/volkszaehler/volkszaehler.org/pull/335/files</a><br><br></div><div>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.<br><br></div><div>@Gernot: damit wissen wir auch warum's bei Dir plötzlich langsamer geworden ist- keine weiteren Tests notwendig!<br></div><div><br></div><div>Viele Grüße,<br></div><div>Andreas<br><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><br></div><div class="gmail_extra">Das muss ich mir mal anschauen...<br><br></div><div class="gmail_extra">Viele Grüße,<br></div><div class="gmail_extra">Andreas<br><br></div></div>
</blockquote></div><br></div></div>