[vz-dev] Alternative Implementierung für vzcompress

[Andreas Goetz]

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