Hallo Florian,
mit etwas mehr Zeit kann ich Dir jetzt ausführlicher antworten. Zur
Erinerung nochmal das Statement (mit kleinen Optimierungen):
-- delete - all channels
delete from data
where id in (
select id from (
select o.channel_id, o.id,
(
select max(timestamp)
from data i_p
where i_p.channel_id = o.channel_id
and i_p.timestamp < o.timestamp
) as prev_ts,
p.id as prev_id, p.value as prev_value,
(
select min(timestamp)
from data i_n
where i_n.channel_id = o.channel_id
and i_n.timestamp > o.timestamp
) as next_ts,
n.id as next_id, n.value as next_value
from data o
left join data p on p.timestamp = prev_ts and o.channel_id
= p.channel_id
left join data n on n.timestamp = next_ts and o.channel_id
= n.channel_id
where o.channel_id in (select id from entities where class =
"channel")
and p.value = o.value
and n.value = o.value
and o.value = 0
)
)
On 15.04.2013 22:34, Florian Knodt wrote:
Nabend die Dritte,
das ist jetzt die 0-Wert-Löschung? Er sucht 3 aufeinanderfolgende
Werte eines Kanals und löscht wenn alle 0 sind den Mittleren, richtig?
Wenn Du Dir das innere SELECT anschaust siehst Du, dass alle Datensätze
zurückgegeben werden, die den gleichen Wert aufweisen wie der vorherige
und nächste Datensatz im gleichen Kanal- das sind also die
"innenliegenden" Datensätze einer Folge. Mit dem äußeren SELECT wird
diese Liste auf die IDs reduziert und der Löschung zugeführt.
Die Einschränkung auf Nullwerte erfolgt mit dem letzten Teil der
WHERE-Clause.
Am 2013-04-14 20:22, schrieb Andreas Goetz:
eine Optimierung welche mir für vzcompress noch einfiele wäre die
Löschung (nicht nur Komprimierung) redundanter Nullwerte.
Bei MeterInterpreter die nullen, bei SensorInterpreter
aufeinanderfolgende und identische Werte würde ich sagen - wenns bei
letzterem gleich bleibt sollte das ähnlich funktionieren.
Guter Punkt. Wenn Die den letzten Teil der WHERE-Clause (=0) weglässt,
ist jetzt auch dieser Fall mit abgedeckt.
0-Strecke einsparen. Die letzte 0 wird benötige, damit das Frontend
keine Rampen in die Darstellung einbaut.
Guter Punkt, das hätte ich glatt verpennt…
Leider funktioniert das nach meinen Tests trotzdem nicht. Die Werte
stehen korrekt in der DB, werden per JSON korrekt zurückgeliefert, aber
im Chart wird die letzte Null eines Bereiches ignoriert. Ursache ist mir
nicht klar.
Nachteilig ist natürlich dass man nich tmehr so einfach auf der
Datenbank Werte mehrerer Kanäle für einen Timestamp "zusammenjoinen"
kann
...und ggf. nicht so weit im Frontend zoomen kann - afair zeigt das
nichts an wenn keine Daten vorhanden sind. Wenn wir den ganzen
(Sonnen)Tag von 0 reden und z.B. auf Stundenansicht gehen könnte das
ggf. auch etwas seltsam aussehen
Auch ein guter Punkt- aber das gleiche Problem, welches auch bei
Komprimierung der Werte besteht, oder? Im SQL könnte man den maximalen
Zoomraum durch Einschränkung der WHERE-Clause vor Löschung schützen:
...
and p.timestamp < o.timestamp - 1*60*1000
and n.timestamp > o.timestamp - 1*60*1000
damit sind dann nur Datensätze betroffen, deren Vorgänger und Nachfolger
_innerhalb_ eines angegebenen Intervalls liegen (vmtl. müsste man sich
aber eher auf den Intervallanfang/ende konzentrieren- das braucht noch
etwas Bastelei). Der Weg sollte der gleiche sein.
Wie wär's- bekommen wir das in die Neuimplementierung noch mit rein?
"noch"? ich mach von meiner Seite keinen Schreibschutz drauf und
deklariere es als fertig ;) Spaß beiseite: Ist notiert und hört sich
erfolgsversprechend an, wenn ich etwas Zeit bekomme und der
Schleifenbug raus ist schau ichs mir an.
Ich bin gespannt- gibts eigentlich ein GIT dafür?
Viele Grüße,
Andreas
