[vz-dev] Aggregationsmode "DELTA"

[Thorben Thuermer]

On Sun, 3 Nov 2013 10:36:04 +0100 <vz at stromtarif-24.de> wrote:
> Meine Antwort ist wohl verloren gegangen, daher hier nochmal.
> 
> Hab von Github noch keinen echten Plan daher Code anbei...
[code]

sorry, aber so ist unguenstig (zuviel fehleranfaellige manuelle arbeit)...
du musst dich ja nicht bei github anmelden,
aber einmal die ausgabe von 'git diff' in eine datei umleiten und als
attachment waehre gut.

> Entscheidend ist, dass innerhalb eines Aggregationszeitraumes mind. 1 Wert
> geschrieben wird. Zur Zeit schreibe ich immer den ersten Wert plus die
> Veränderten in die DB.
> 
> Auf diese Weise lässt sich die Datenmenge reduzieren und die Unschärfe (in
> der Darstellung) beschränkt sich auf den Agg-Zeitraum.

- Thorben



es folgt ein nicht markiertes zitat?

> Ich denke jetzt nochmal laut...
> 
>  
> 
> 2013/10/28 Andreas Goetz <cpuidle at gmail.com>
> 
> Moin,
> 
>  
> 
> 2013/10/28 Thorben Thuermer <r00t at constancy.org>
> 
> ...
> 
>  
> 
> > Im Ergebnis führt das dazu, dass das FE hässliche "Rampen" an den Stellen
> > anzeigt wo von 0-Werten (bzw. Stellen in der DB mit längeren Intervallen)
> > wieder auf Daten übergegangen wird.
> 
> beschraenkt sich das problem nicht drauf, jeweils die erste UND die letzte
> null drinzulassen?
> wenn du die letzte loescht, kann die middleware halt nichtmehr sagen, in
> welchem zeitraum die naechste aenderung stattgefunden hat,
> und verteilt sie halt auf den gesamten zeitraum seit dem letzten wert.
> 
>  
> 
> Schon getestet- tut es leider nicht. Das Problem ist "so gross", wie Tupel
> zusammengezählt werden. Wenn z.B. 2 Tupel am Ende vom Vortag aus 0 und x auf
> x/2 aggregiert werden und die ersten beiden Tupel vom Foleetag (0 und y) auf
> y/2 aggregiert, dann bedeutet das schlimmstenfalls eine Rampe von x/2 bis
> y/2 ohne dass die 0 jeweils im FE angezeigt wird. Je mehr Tupel aggegiert
> werden desto größer die Abweichung.
> 
>  
> 
> Das Problem ist dass wir im Moment (wenn das FT tupels=xyz übergibt) Pakete
> schnüren. Seit dem entsprechenden Patch macht das die Datenbank:
> 
>     $sql = 'SELECT MAX(aggregate.timestamp) AS timestamp,
> SUM(aggregate.value) AS value, COUNT(aggregate.value) AS count '.
>            'FROM ('.
>            '    SELECT timestamp, value, @row:=@row+1 AS row '.
>            '     FROM data WHERE channel_id=?' . $sqlTimeFilter . 
>            ') AS aggregate '.
>            'GROUP BY row DIV ' . $packageSize .' '.
>            'ORDER BY timestamp ASC';
>  
> 
> In Griff kriegen liesse sich das nur wenn das FE einen irgendwie einen
> Hinweis bekommen wird dass zwischendurch die 0 "steht"  und die Daten
> ausgedünnt sind.
> 
>  
> 
> Was spräche denn jetzt dagegen, stattdessen äquidistante Stücke zu
> schneiden, also nach timestamp DIV $packageSize zu gruppieren? und den
> entsprechenden Timestamp im Select hochzuzählen? Das Ganze noch mit IFNULL
> Statements ergänzt sollten wir in der Lage sein, fehlende (Null-)Werte zu
> ergänzen. Performance to be tested.
> 
> Dann besteht natürlich wieder die Gefahr, dass wir zwischen zwei
> Zählerwerten eine Null erfinden falls sich da kein weiterer Messwert
> anfindet- Tuples darf also nicht granularer werden als Messwerte wirklich
> vorliegen.
> 
> Wär hätte Lust einen Prototyp zu bauen und Performance zu testen??
> 
> vg
> 
> Andreas 
> 
>  
>