Raspberry Pi: Werte vom Temperaturlogger in SQL oder RoundRobin DB speichern?

Hallo Axel,

Axel Schwenke schrieb:
>> habe aber bedenken ob der Datenmengen und der vergleichsweise
>> kleinen HW des Raspberry. Ist daher eher ein verwerfen von Daten unter
>> Nutzung von Round-Robin anzuraten?
>
> Auf jeden Fall. RRDtool ist für genau solche Anwendungen gemacht,

Wenn das "auf jeden Fall" so wäre, würde der TO nicht fragen.

> Ich hab mal ein Monitoring-Tool für ein paar Hundert Meßstellen (Server,
> Switches etc.) gebaut. Wie ein Vorposter schon bemerkte, ist das
> Speichern der Daten das kleinste Problem. Die Abfragen sind es. Die
> werden immer langsamer,

Wenn man mit Datenbanken umgehen kann (und vielleicht nicht ausgerechnet 
MySQL benutzt), dann nicht. In PostgreSQL kann man beispielsweise die DB 
mithilfe des Vererbungs-Feature partitionieren und über einen Trigger 
auf INSERTs a) die Daten verteilen sowie b) veraltete Tabellen 
akkumulieren oder wegsichern oder oder oder...

LG,
Karl

Hallo zusammen,

vorab schon mal danke für eure Antworten, wobei es mir weniger um den 
verfügbaren Speicher geht. Habe ein "All-In" Satz von Reichelt, da ist 
gleich eine 8GB Karte dabei. Selbst die könnte ich gegen was größeres 
tauschen.


@Karl Heinz: ok, das werde ich wohl nicht miterleben, bis zur 90 sind es 
nur noch 35 Jahre... Also halbieren wir die hundert mal ;=) War eher 
eine worst-case Rechnung um die max. Datenmenge zu ermitteln.
Was den PC angeht ging es beim 286 los, der 386SX war schon toll, aber 
mit dem DX ging die Post erst ab. Der 386DX steht immer noch im Keller 
mit DOS und einigen Programmen, aber keine Angst: gibt auch was 
moderneres im Hause Schuster.

@Karol: Danke für die Erklärungen, habe mich da mal ein wenig belesen 
und war völlig auf dem Holzweg was die interne Struktur anging. Das 
Platz nicht das Problem ist, war mir wohl bewusst. Geht mir auch eher um 
Abfragen, z.B. zeichne mir die Temperatur übers Jahr unter Berechnung 
eines Mittelwertes pro Tag (oder min/max), oder Temperatur im Januar der 
letzten 10 Jahre, oder, oder, oder.
Wie gesagt: um die Speicherung an sich mache ich mir weniger Sorgen, 
eher um den Betrieb und Abfrage der Daten über das Webinterface für 
Grafiken.

@Axel: die Waschküche interessiert mich wirklich weniger, aber alle vier 
Seiten des Hauses, Dachgeschoss, Kessel & Boiler sowie Garage. Würde 
mich schon interessieren wie z.B. die Temperaturen vor einem Jahr waren. 
Ob das Sinn macht: ehrlich gesagt nein. Ist eher die Neugier.
Hast du ggf. Grenzen bzgl. Performance bei Round-Robin parat? Meine 
Vorstellung wäre sonst:
1,5 Jahre alle Werte zu speichern (Vergleich zum Vorjahr mit ein wenig 
Überlappung möglich)
dann auf Mittelwert/min/max über 3h zusammenfassen (aufstehen um kurz 
nach sechs), Rückkehr gegen 17Uhr-18Uhr jeweils mit Werten erfasst
nach 10 Jahren dann auf einen Tag

@Florian: das soll die Karte mal schön selber übernehmen, 
schlimmstenfalls ist sie halt kaputt. Könnte die Daten ja alle 24h aufs 
NAS schieben (lassen).


Danke für eure Erfahrungen, wird demnach wohl auf Round-Robin 
hinauslaufen. Gibt dazu ja genügend Beispiele im Netz, werde dann 
nächstes WE und über die Feiertage mal schauen.
Frage am Rande: kann man alte RRT Dateien "importieren"? Hintergrund: 
würde die dann jeden Monat sichern und irgendwo ablegen um sie bei 
Bedarf rauskramen zu können für Detailwerte.


Danke und Grüße, Bernd

Bernd Schuster schrieb:

> -> bei 8 Sensoren macht das also:
> 100Jahre  365Tage  24h * 12Messwerte/h  8Sensoren  2Byte = ~160MByte
>
> Dazu kommt dann noch die (SQL-)ID, der Timestamp und (einmalig) die
> Sensornr. zu jedem der 8 Sensoren

Wer Timestamps hat, braucht keine zusätzlichen IDs. Und wer das Prinzip 
einer Daten-Spalte entdeckt hat, braucht keine Sensornummern zu 
speichern, sondern sieht einfach eine entsprechende Anzahl Spalten vor. 
Und übrigens: zum Speichern von Timestamps braucht man nicht unbedingt 
den so benannten Datentyp zu verwenden, wenn dieser für den geplanten 
Zweck viel zu genau ist, da tut es auch ein (U)Integer, bei dem dann 
halt ein Zählschritt 5 Minuten entspricht und der Wert 0 dem 
Startzeitpunkt der Aufzeichnung. Die Umrechnung von Zeit zu proprietärer 
Zeitstempel und zurück ist trivial, man kann das entweder mit 
Datenbankfunktionen oder Funktionen im Anwenderprogramm erschlagen.

Kurzfassung: zu deiner obigen Rechnung kommt nur noch der 
Int-Zeitstempel mit vier Byte dazu, der reicht dann sicher auch für ein 
wesentlich längeres Leben. Ideal wäre für deine Anforderungen ein 
uint-Datentyp mit drei Byte, aber den jibbet wohl nicht bei SQlite. 
Möglichwerweise gibt es aber die Möglichkeit, Custom-Datentypen zu 
bauen, keine Ahnung. Dann könnte es doch was werden mit dem idealen 
Datentyp für deinen Zeitstempel.

> Idealerweise würde ich natürlich gerne alle Daten (in einer SQlite DB)
> aufheben, habe aber bedenken ob der Datenmengen und der vergleichsweise
> kleinen HW des Raspberry. Ist daher eher ein verwerfen von Daten unter
> Nutzung von Round-Robin anzuraten?

SQlite ist ganz nett für kleinere Datenbestände. Richtest du auf einem 
richtigen Rechner noch eine richtige DB ein und auf dem RasPi einen Job, 
der die kleine mit der großen DB synchronisiert, wann immer die große DB 
verfügbar wird und danach denn die lokale DB nach unten hin ausdünnt, 
hast du alles: kleine Datenbestände auf dem RasPi und trotzdem alle 
Daten und diese auf einer Maschine, die mit den Datenmengen auch 
tatsächlich umgehen kann.

Das wirst du spätestens zu schätzen lernen, wenn du z.B. mal wissen 
willst, wie hoch etwa der größte Temperaturgradient innerhalb einer 
Stunde über alle Meßstellen und den gesamten Meßzeitraum war. Da dürfte 
der Pi schon eingehen wie eine Primel, wenn er auch nur aus dem 
Datenbestand eines Jahres das Ergebnis extrahieren soll. Das läuft 
nämlich auf einen Self-Join einer Tabelle mit 365*24*12=ca. 100.000 
Zeilen hinaus, die beim join entstehende (virtuelle) Zwischentabelle hat 
also flockige 100.000*100.000=10.000.000.000 Zeilen. Da rechnet auch ein 
ordentlicher Desktop-PC schon eine geraume Weile dran, aber er kommt 
immerhin zu einem Ergebnis, und das sehr deutlich bevor die 100 Jahre 
deiner geplanten Lebenszeit abgelaufen sind...

Der RasPi hingegen würde wegen Speichermangel schlicht abkacken. Selbst 
mit allen Tricks, die sich die Entwickler von RDBMs im Laufe der Zeit 
haben einfallen lassen, um den Impact solcher Riesenjoins zu minimieren, 
es bleibt immer noch genug über, um den RasPi völlig zu überfordern.

Das ist nur ein Kinderspielzeug, kein Datenbankserver!

Karol Babioch schrieb:

> Und wer das so macht hat das Prinzip der Normalisierung nicht
> verstanden.

Vollständige Normalisierung kann auch der Untergang sein. Das erklärt, 
warum praktisch keine realexistierende DB mit nennenswerter Zeilenzahl 
vollständig nomalisiert ist.

Der Unterschied in SQL:

Meine Variante:

create table
 temperatures
(
 ts int primary key,
 sens1 int16,
 sens2 int16,
 ...
 sens8 int16
);

..fertig

Deine Variante:

create table
 sensors
(
 id int primary key,
 ...was es sonst noch über den sensor zu speichern gibt
)

create table
 temperatures
(
 ts int,
 sens int foreign key references sensors(id),
 value int16,
 primary key (ts,sens)
)

..fertig?

Nicht ganz... Hier zeigt sich nämlich schon das erste Problem. Für die 
temperatures-Tabelle ist es nicht mehr möglich, ts als Primärschlüssel 
zu benutzen. Hier braucht man einen Primärschlüssel, der über zwei 
Spalten reicht. Das ist in SQL natürlich möglich, aber es ist schon von 
vorherein deutlich ineffizenter bei ALLEN Operationen, die den 
Primärschlüssel bzw. seinen Index benutzen.

Aber jetzt wird's hammerhart: Meine Beispielabfrage, angewendet auf 
diese zwei Beispiel-DBs, die dieselben Informationen enthalten, also 8 
Sensoren und deren Meßwerte alle 5 Minuten über ein Jahr.

Die Ausgangsbedingungen sind dann:

Meine Variante enthält eine Tabelle mit gut 100.000 Zeilen. Deine 
Variante zwei Tabellen, davon eine mit 8 Zeilen und eine mit gut 800.000 
Zeilen.

Die Abfragen lauten nun (nur der kritische Teil, der eine 
Zwischentabelle erstellt, wie sie auch die DB intern erstellen würde, um 
die Aggregatfunktionen darauf anzuwenden):

Meine Variante:

select
 t1.sens1,
 t1.sens2,
 ...
 t1.sens8,
 t2.sens1,
 t2.sens2,
 ...
 t2.sens8
from
 temperatures as t1
 join temperatures as t2 on t1.ts+12=t2.ts;

Hier sind 100.000 Zeilen * 100.000 Zeilen * 1 Vergleich zu erledigen. 
Also
*10.000.000.000*
Operationen.

Deine Variante:

select
 t1.value,
 t1.sens,
 t2.value
from
 temperatures as t1
 join temperatures as t2 on t1.ts+12=t2.ts and t1.sens=t2.sens;

Hier sind 800.000 Zeilen * 800.000 Zeilen * 2 Vergleiche plus deren 
logische Verknüpfung zu erledigen. Letzteres erfolgt im 
Kurzschlußverfahren, knallt also zu deinem Gunsten nur halb rein. 
Trotzdem ergibt sich immer noch folgender Aufwand:
800.000 Zeilen * 800.000 Zeilen * 1 Vergleich +
800.000 Zeilen * 800.000 Zeilen * 1/2 Vergleich
Insgesamt
*960.000.000.000*
Operationen.

Also mal flockig der 96fache Rechenaufwand.

Danach sind dann beide Varianten weitgehend gleich, weil sich die höhere 
Zeilenzahl der Zwischentabelle deiner Variante und die höhere Zahl der 
nötigen Operationen bei der Zwischentabelle meiner Variante bei der 
Aggregatbildung ziemlich exakt ausgleichen.

Hallo zusammen,

danke für die Erläuterungen. Nach euren Ausführungen bin ich nun weg von 
SQL, das übersteigt dann doch ein wenig meine Anforderungen und 
Kapazitäten des kleinen Raspberry. Größtenteils bin ich da aber auch 
überfordert, so einen guten Einblick habe ich dann doch nicht.

@Axel: danke. Tendiere aktuell zu Round-Robin und nach deinen 
Anmerkungen parallel zu einer Text/CSV Datei pro Sensor pro Monat (ggf. 
auch pro Tag). Ersteres kann der Raspberry verarbeiten, die Textdateien 
fürs Archiv auf dem NAS. Wenn der Raspberry performant genug ist, würde 
ich ihn sonst auch noch gleich Stunden/Tages min/max/Schnittwerte in 
einer extra Textdatei berechnen lassen, da der Raspberry eh immer laufen 
muss und der Zeit genug hat. Speicherplatz ist halt vorhanden, und 
Berechnungen die mich interessieren kann er auch vorab erledigen.

Gruß, Bernd

Wenn es nur um Temperaturen in einem bestimmtem Messintervall geht, dann 
nehme ich für diesen Zweck eine low-level Datei. Jeder Record bekommt 
einen 32bit Zeitstempel und n*16bit Messwerte. Genauer als 16bit ist in 
der Regel keine physik. Größe im Heimgebrauch. Mit anderen Worten eine 
binäre Datei mit fester Recordlänge. Als Intervall werden z.B. 2 Minuten 
gewählt. Bei 64 Messwerten ergibt das ca. 277Mb pro Jahr. Die 
Schreibroutine sorgt dafür, dass ab dem ersten Wert immer alle Records 
geschrieben werden. Dabei werden Lücken mit Dummywerten gefüllt. Selbst 
nach 20 Jahren und einer Datei von ca. 5GB braucht man nur 2 
Leseoperationen auf die Datei um die Werte zu einem bestimmten Zeitpunkt 
zu bekommen. Einmal die ersten 4 Byte am Anfang um den Startzeitpunkt zu 
ermitteln. Daraus ergibt sich dann ein fester Offset in die Datei wo die 
Daten stehen. Eine einfache Konsistenzprüfung erfolgt über den 
Zeitstempel jedes Eintrags gegen seine Position in der Datei.
Das ganze macht zwar erst mal ein wenig Arbeit, spart aber den 
kompletten Overhead einer Sql-Datenbank und ist obendrein noch schneller 
und kompakter. Wenn ich z.B. einen bestimmten Monat analysieren will, 
lese ich ab dem Startoffset (n*16+32)*31Tage Bytes aus der Datei in den 
Speicher und mache die Analyse ausschließlich im Speicher.
Nur mal so als Beispiel wie es auch ohne Sql gehen kann. cvs-Dateien 
oder Textformate ohne feste Recordlänge halte ich aber auch nicht für 
klug.

Hallo Bernd,

Bernd Schuster schrieb:
> danke für die Erläuterungen. Nach euren Ausführungen bin ich nun weg von
> SQL, das übersteigt dann doch ein wenig meine Anforderungen und
> Kapazitäten des kleinen Raspberry.

Deine Anforderungen vielleicht, die Kapazitäten des RasPi sicher nicht.

Sogar die mit Abstand leistungsfähigste der hier besprochenen 
Datenbanken, PostgreSQL, läuft wunderbar rund auf dem RasPi. Damit ist 
es kein Problem, veraltete Daten automatisch zu verwerfen, zu 
akkumulieren, sie in andere Tabellen oder Logdateien zu überführen oder 
oder oder... die Möglichkeiten werden dabei nur durch Deine Fähigkeiten 
begrenzt.

Viel Erfolg mit Deinem Projekt,
Karl

Karl Käfer schrieb:

> Sogar die mit Abstand leistungsfähigste der hier besprochenen
> Datenbanken, PostgreSQL, läuft wunderbar rund auf dem RasPi.

Dann frage sie doch einfach mal die von mir vorgegebene Frage...

Also: Bei welchem Sensor gab es im letzten Jahr innerhalb einer Stunde 
den größten Temperatursprung und wie groß war der?

Dann wirst du sehen, wie "wunderbar rund" PostgreSQL auf dem RasPi 
tatsächlich läuft...

Und PostgreSQL ist wirklich ein sehr schönes und hervorragend 
optimiertes relationales DB-System. Aber auch die Postgre-Entwickler 
können nunmal keine Wunder vollbringen. Wenn die Komplexität einer 
Abfrage die Resourcen der Maschine überfordert, dann ist das halt so. Da 
hilft kein Wunschdenken und kein Verbreiten gegenteiliger Behauptungen, 
sondern nur eins: eine leistungsfähigere Maschine.

Hallo zusammen,

danke für eure Anmerkungen., so langsam bekomme ich immer mehr eine 
Vorstellung davon was ich wirklich will und am Ende mit vertretbarem 
Aufwand auch realisierbar ist.

@Axel: Großeltern (schon lange tot) hatten einen Bauernhof, die hatten 
noch Aufzeichnungen von jedem Tag in Kladden. Interessanterweise konnte 
man mit den Daten im Frühjahr sehr gut vorhersagen wie die Ernte ausfiel 
(mal abgesehen von ein paar Ausreißern). Daher der Wunsch irgendwie alle 
Werte zu behalten, ist eher eine Macke aus der Kindheit. Primär 
interessiert aber nur ein Verlauf in Form eines Graphen.
Was den Timestamp angeht: dann wird die Datei halt 50MB größer. Stört 
das die SD-Karte? Außerdem habe ich so eine Sicherung gegen 
Stromausfall, verschlampte Sensorwerte o.ä., als wenn ich nur über einen 
C-Pointer stumpf an eine Stelle auf Grundlage der Anzahl von Messwerten 
springe.
Das RRD die gewünschten Werte gleich mit berechnet und ausgibt wusste 
ich nicht. Muss mich weiterhin einlesen.

@old man: da fehlt mir die "einfache" Auswertung. Hatte mir in der 
Vergangenheit einmal http://dygraphs.com angesehen, aber dafür müsste 
ich mir ein Array selber im Speicher aufbauen und ob das überhaupt auf 
dem Raspberyy läuft kann ich auch noch nicht sagen.

@Karl & c-hater: komplexe DB Abfragen wie die genannte benötige ich 
wahrscheinlich gar nicht, bzw. kann mir das aktuell nicht vorstellen. Es 
geht rein um die Aufzeichnung und Darstellung von Temperaturkurven. 
Einzig die Zeiträume (z.B. alle Daten jedes aufgezeichneten Januars) 
sollten sehr variabel sein. Zusätzlich interessieren mich halt noch 
min/max/Mittelwerte.

Danke und Gruß,

Bernd

Hallo,

c-hater schrieb:
> Karl Käfer schrieb:
>> Sogar die mit Abstand leistungsfähigste der hier besprochenen
>> Datenbanken, PostgreSQL, läuft wunderbar rund auf dem RasPi.
>
> Dann frage sie doch einfach mal die von mir vorgegebene Frage...
>
> Also: Bei welchem Sensor gab es im letzten Jahr innerhalb einer Stunde
> den größten Temperatursprung und wie groß war der?
>
> Dann wirst du sehen, wie "wunderbar rund" PostgreSQL auf dem RasPi
> tatsächlich läuft...
>
> Und PostgreSQL ist wirklich ein sehr schönes und hervorragend
> optimiertes relationales DB-System. Aber auch die Postgre-Entwickler
> können nunmal keine Wunder vollbringen. Wenn die Komplexität einer
> Abfrage die Resourcen der Maschine überfordert, dann ist das halt so. Da
> hilft kein Wunschdenken und kein Verbreiten gegenteiliger Behauptungen,
> sondern nur eins: eine leistungsfähigere Maschine.

Ach, weißt Du, wenn ich mir etwas Mühe gebe, dann kann ich mir für jede 
beliebige Maschine und jede beliebige Datenbank etwas ausdenken, um die 
Veranstaltung ins Schwitzen zu bringen. Und das, was Du da vorschlägst, 
ist dabei allerdings sogar noch eher witzlos, dank window functions und 
index-only scans (seit PostgreSQL 9.2). ;-)

Aber ja, wen wundert's: komplexe statistische Auswertungen sind auf dem 
Pi zwar möglich, erfordern aber ein wenig Zeit. Kein Problem: wenn man 
solche Daten gewinnen will, kann das der Pi in seiner Idle-Zeit 
vorberechnen (als Datenlogger hat er ja genug Idle-Zeit dafür) oder man 
lädt sich die Daten auf eine schnellere Büchse und kann dann mit R, 
Python+Matplotlib, Matlab oder Ähnlichem arbeiten. Ein Datenlogger (und 
darum geht es dem TO ja) muß keine riesige Rechenleistung haben. Wow, 
große Überraschung allenthalben. Wer hätte das denn ahnen können...

Und jetzt? Hast Du jetzt "gewonnen"? Dann bist Du ein ja ein richtiger 
kleiner Held!

Liebe Grüße,
Karl

Hi Bernd,

Bernd Schuster schrieb:
> @Karl & c-hater: komplexe DB Abfragen wie die genannte benötige ich
> wahrscheinlich gar nicht, bzw. kann mir das aktuell nicht vorstellen. Es
> geht rein um die Aufzeichnung und Darstellung von Temperaturkurven.
> Einzig die Zeiträume (z.B. alle Daten jedes aufgezeichneten Januars)
> sollten sehr variabel sein. Zusätzlich interessieren mich halt noch
> min/max/Mittelwerte.

In meinem Fall läuft auf dem RasPi ein kleiner Paste-Webserver mit einer 
Bottle.py-Webseite, der Temperaturdaten über AJAX zieht und daraus 
Kurven mithilfe von jQuery-Flotcharts zeichnet. (siehe Anhang) Der 
Vorteil: das Rendering findet auf dem schnellen Client statt, der RasPi 
macht nur einen simplen SELECT und stellt die Daten via AJAX bereit. Das 
SELECT ist dank Index auf der zeitpunkt-Spalte sehr schnell; natürlich 
könnte das ganz leicht etwa so umgebaut werdenm, daß statt eines 
Zeitraumes von n Tagen bis jetzt zwei Timestamps, einzelne 
Wochen/Monate/Jahre oder Ähnliches angegeben werden.

Übrigens: wenn Du komplexere Sachen machen willst, dann kann der Pi die 
natürlich mit einem Cronjob vorausberechnen. Ich könnte mir zum Beispiel 
vorstellen, mit Python + Matplotlib die Daten beispielsweise mehrerer 
Jahre übereinander zu legen und daraus hübsche Box-Whisker-Plots mit 
Standardabweichungen, Minima und Maxima zu zeichnen.

HTH,
Karl

Karl Käfer schrieb:

> Ach, weißt Du, wenn ich mir etwas Mühe gebe, dann kann ich mir für jede
> beliebige Maschine und jede beliebige Datenbank etwas ausdenken, um die
> Veranstaltung ins Schwitzen zu bringen.

Natürlich.

Allerdings ist meine Frage ja nun auch nicht so weit hergeholt, bei der 
Analyse von Sensordaten ist es ganz allgemein die erste Aufgabe, 
Irregularitäten im Datenmaterial zu finden und auszufiltern, bevor die 
eigentliche Auswertung erfolgt. Und was wäre deiner Meinung nach dazu 
besser geeignet als die Suche nach Sprüngen (und auch über längere 
Zeiträume quasikonstante Meßwerte, was von der Komplexität der Abfrage 
her exakt dieselbe Problematik darstellt)?

Wenn du zu blöd bist, den Sinn hinter solchen Abfragen zu erkennen, nur 
als Stichworte: Wackelkontakt, Kabelbruch...

> Und das, was Du da vorschlägst,
> ist dabei allerdings sogar noch eher witzlos, dank window functions und
> index-only scans (seit PostgreSQL 9.2). ;-)

Das hilft bei diesem Problem ziemlich exakt genau garnix. Hier wird in 
der ersten (also der wirklich teuren) Stufe sowieso nur der Index des 
Primärschlüssels benutzt. Und zwar in beiden dargestellten Varianten 
gleichermaßen. Und das gilt übrigens für alle ernstzunehmenden RDBMs 
mindestens der letzten 30 Jahre, ebenfalls gleichermaßen.

Vielleicht wirfst du einfach mal einen Blick auf die Joinbedingungen und 
vergleichst das mit den jeweils im Primärschlüssel enthaltenen Spalten?

Merke: Die Fähigkeit zur Buzzword-Replikation ist was völlig anderes als 
echter Sachverstand. Verkäufer und Marketingfritzen machen grundsätzlich 
ersteres, wirkliche Programmierer haben im Idealfall letzteres.

> oder man
> lädt sich die Daten auf eine schnellere Büchse

Das war genau, was ich eingangs vorgeschlagen habe. Und deine Erwiderung 
war im Prinzip: NEEIIIN, der RasPi kann das alles wunderbar alleine, 
das läuft immer völlig rund und ohne jedes erwartbare Problem...

c-hater schrieb:
> Allerdings ist meine Frage ja nun auch nicht so weit hergeholt, bei der
> Analyse von Sensordaten ist es ganz allgemein die erste Aufgabe,
> Irregularitäten im Datenmaterial zu finden und auszufiltern,


c-hater schrieb:
> Wenn du zu blöd bist, den Sinn hinter solchen Abfragen zu erkennen, nur
> als Stichworte: Wackelkontakt, Kabelbruch...

Na ja, deine Aussage bezog sich darauf sowas in einem Zeitraster von 
einem Jahr zu finden. Wer ein Jahr braucht um einen Wackelkontakt oder 
Kabelbruch zu detectieren ist wirklich zu blöd...

Ich werfe trotzdem nochmal den Ansatz einer binären Datei in den Ring. 
In meinem Beispiel waren das 277Mb pro Jahr bei 64 Messwerten. Das 
kriegt ein Rpi noch problemlos in den Speicher. Die einzige Zeit die 1 
Jahr Analyse braucht, ist die Zeit um die Daten zu lesen. Alle anderen 
Routinen laufen dann komplett im Speicher und damit "sauschnell". 
Natürlich muss man da ein wenig Grips in die Programierung investieren. 
Das ist aber besser investierte Zeit als hier über die Fähigkeiten von 
Sql-Datenbanken zu streiten. Aber sich wirklich auf eine low level Ebene 
zu begeben ist heute nicht mehr zeitgemäß...

old man schrieb:

> Na ja, deine Aussage bezog sich darauf sowas in einem Zeitraster von
> einem Jahr zu finden. Wer ein Jahr braucht um einen Wackelkontakt oder
> Kabelbruch zu detectieren ist wirklich zu blöd...

Nun, es soll Leute geben, die haben tatsächlich was anderes zu tun, als 
magisch gebannt auf die grafischen Darstellungen irgendwelcher 
Sensorwerte zu starren, um Irregularitäten darin zu entdecken. Diese 
Leute überlassen die Suche nach solchen Problemen gern Computern, denn 
deren Aufmerksamkeit erschlafft nicht, wenn das Endspiel der Fußball-WM 
läuft oder irgendeine Tussi in irgendeinem Film das Oberteil ablegt.

> Ich werfe trotzdem nochmal den Ansatz einer binären Datei in den Ring.

Hossa. Du weißt schon, daß die Daten aller RDBMs in "binären Dateien" 
abgelegt werden?

> Natürlich muss man da ein wenig Grips in die Programierung investieren.

Ja, was glaubst du denn, womit die Entwickler von Datenbank-Engines ihre 
Zeit vertrödeln? Vielleicht versuchst du einfach mal, die Abfrage in 
deiner bevorzugten Sprache auf deine "Binärdateien" anzuwenden.

Dann wirst du, wenn du nicht völlig verblödet bist, doch irgendwann 
feststellen, daß selbst du zehn Milliarden Vergleiche machen musst, um 
zweimal hunderttausend Datensätze einer bestimmten Bedingung folgend 
miteinander zu kombinieren. Diese öde, blöde Mathematik läßt leider auch 
für Möchtegern-Genies wie dich keinerlei Ausnahmen zu...

Natürlich lassen sich für spezielle Probleme Vereinfachungen finden. Um 
mal beim konkreten Beispiel zu bleiben: Statt die Datensätze alle 
miteinander zu vergleichen, könnte man sich natürlich zunutze machen, 
daß es eine gewisse Beziehung zwischen ihnen gibt, nämlich, daß pro 
Stunde eben normalerweise genau 12 davon auflaufen. War das aber 
irgendwann mal nicht der Fall (weil z.B. der Server mal down war), 
dann liefert diese Vereinfachung nur noch Müll, und ist dann für ihren 
eigentlichen Zweck (Irregularitäten im Datenmaterial zu entdecken) nicht 
mehr zu gebrauchen.

Ganz allgemein lassen sich also komplexitätverringernde Optimierungen 
nur realisieren, wenn man bestimmte Eigenschaften der Daten sicher 
kennt. Kennt man aber solche Eigenschaften, lassen sie sich gewöhnlich 
auch mit SQL nutzen. Wenn man SQL kann...

> Aber sich wirklich auf eine low level Ebene
> zu begeben ist heute nicht mehr zeitgemäß...

Du begreifst garnix. SQL ist nur eine andere Art der Darstellung des 
Problems. Das Problem und die ihm innewohnende Komplexität bleibt aber 
über alle Darstellungen des Problems exakt dieselbe. SQL-RDBMs sind der 
(einigermaßen gelungene) Versuch, diese Komplexität mit einer Sprache zu 
beschreiben und für die Menge aller Probleme möglichst effizient 
umzusetzen.

Das Problem von SQL ist nur, daß höchstens 1% der Menschheit es 
schaffen, in Mengen zu denken. Und, noch viel schlimmer: die meisten 
prozeduralen Programmierer schaffen das ebenfalls nicht. Das ist 
schlimm, weil die es eigentlich sind, die aus den Fähigkeiten der 
Datenbanken wirklich Vorteile ziehen könnten und massiv 
Entwicklungsaufwand sparen könnten, wenn sie den neben ihrer bevorzugten 
Sprache auch noch SQL wirklich beherrschen würden. Also alles jenseits 
von "select elephant from africa where isdead=1;"

Hallo C und auch alle anderen Hasser,


Au weia, ich hatte zuerst nicht bemerkt mit wem ich hier diskutiere. 
Sorry, von deinen Aussagen habe ich schon genügend unkommentiert 
gelesen. So werde ich auch weiter verfahren. Der Ton alleine ist schon 
das allerletzte. Warum gehst du nicht in die Politik, da ist Schreien im 
Moment auch das Mittel der Wahl?

Wer glaubt nur seine eigene Denke ist die einzig richtige, der 
disqualifiziert sich von vorn herein. Ich sage nicht dass mein Weg der 
einzig mögliche ist, aber für die Auswertung von im Zeitraster geloggten 
Daten wage ich die Behauptung meine Routinen schneller in der Sprache 
meiner Wahl zu programmieren als du das in SQL formulierst. Ich habe ja 
schließlich noch die Zeit zusätzlich die du mit Schreien verbringst.

Was ist den SQL in dem Fall von geloggten Daten? Eine flache Tabelle mit 
maximal ein paar Indexen über die Felder. Da kannst du fitt in SQL sein 
oder auch nicht und von Mengen was verstehen oder auch nicht, am Ende 
bleibt ausser der Tabelle und ein paar Sortierschlüsseln nichts 
brauchbares übrig. Und gegen sowas an zu stinken ist nun wirklich keine 
Kunst. Ausser man ist so verbohrt und kann die Realität schon nicht mehr 
wahrnehmen.

Aber das Problem hast du ja sowieso. Jedenfalls hier im Forum. Und damit 
beende ich mein Statement in diesem Thread.

Hallo Axel,

Axel Schwenke schrieb:
> Mal wieder ein Feature, das PostgreSQL von dem angeblich doch sooo
> unterlegenen MySQL übernommen hat. MySQL hat covering indexes übrigens
> seit ... schon immer.

Ach Gottchen, ja. MySQL ist trotzdem nichts weiter als eine vollkommen 
überbewertete Datenbanksimulation. Nimmt es immer noch "0000-00-00" als 
Datum an? Wirft es immer noch keinen Fehler, wenn man einen 300 Zeichen 
langen String in einem VARCHAR(255) speichert, sondern schneidet die 
Zeichenkette kommentarlos einfach ab? Kann MySQL immer noch NULL-Werte 
in NOT NULL-Spalten schreiben? Bleiben MySQL-Frontendprozesse immer noch 
ewig in einem select(2) hängen, wenn das Backend abraucht (mal davon ab: 
wie kann das eigentlich passieren?), und muß man dann immer noch die 
ganze Büchse rebooten, weil man den Prozeß auch mit einem MySQL-Restart 
und kill -9 nicht abgeschossen bekommt?

Solange das alles so ist, ist MySQL nicht "angeblich", sondern 
tatsächlich unterlegen, und für ernsthafte Arbeiten leider unbrauchbar. 
Sorry, lieber Herr MySQL Performance Engineer, aber eine Schwalbe macht 
noch keinen Sommer, und eine einzige (vergleichsweise nebensächliche und 
ausschließlich performancerelevante) Funktion, die MySQL schon länger 
hat als PostgreSQL, kann MySQLs beschriebene kritische Fehler und seine 
Instabilität leider nicht ausgleichen. Und invalide Daten anzunehmen, 
Constraints zu verletzten oder sogar angenommene Daten kommentarlos zu 
kürzen, sorry, das geht nunmal wirklich überhaupt gar nicht.

Liebe Grüße,
Karl

Hallo,

c-hater schrieb:
>> Und das, was Du da vorschlägst,
>> ist dabei allerdings sogar noch eher witzlos, dank window functions und
>> index-only scans (seit PostgreSQL 9.2). ;-)
>
> Das hilft bei diesem Problem ziemlich exakt genau garnix.

Ach ja? Unter der Voraussetzung, daß jemand Karols DB-Design verwendet, 
mag das sein. Ich bin aber nicht Karol, und in der realen Welt schreibe 
ich Daten lockerflockig in eine einzelne Tabelle, wie Du ja oben selbst 
schon ganz richtig vorgeschlagen hast. Ich habe mir jedoch die Freiheit 
genommen, die Daten auf hübsche Monatstabellen zu verteilen:

1

CREATE TABLE temperatur (

2

  id SERIAL PRIMARY KEY,

3

  zeit TIMESTAMP DEFAULT NOW(),

4

  ch0 INTEGER DEFAULT 0,

5

  ch1 INTEGER DEFAULT 0,

6

  ch2 INTEGER DEFAULT 0,

7

  ch3 INTEGER DEFAULT 0

8

);

9

CREATE OR REPLACE FUNCTION parent_insert_trigger()

10

RETURNS TRIGGER AS $_$

11

DECLARE

12

    ayear VARCHAR(4)      := substring(NEW.zeit::CHAR(18) from 0 for 5);

13

    amonth VARCHAR(2)     := substring(NEW.zeit::CHAR(18) from 6 for 2);

14

    datum DATE            := NEW.zeit::DATE + INTERVAL '1 month';

15

    nyear VARCHAR(4)      := substring(datum::CHAR(18) from 0 for 5);

16

    nmonth VARCHAR(2)     := substring(datum::CHAR(18) from 6 for 2);

17

    tablename VARCHAR(32) := 'temperatur_' || ayear || '_' || amonth;

18

BEGIN

19

    IF NOT EXISTS(

20

        SELECT * 

21

        FROM information_schema.tables 

22

        WHERE table_catalog = CURRENT_CATALOG

23

          AND table_schema = CURRENT_SCHEMA

24

          AND table_name = tablename) THEN

25

        EXECUTE format(

26

          'CREATE TABLE %I (

27

             CONSTRAINT zeit_cstr CHECK (

28

               zeit::date >= %L::date 

29

               AND zeit::date < %L::date) ) 

30

           INHERITS (temperatur);', 

31

          tablename, 

32

          ayear||'-'||amonth||'-01', 

33

          nyear||'-'||nmonth||'-01');

34

        EXECUTE format(

35

          'CREATE INDEX %I ON %I USING btree (%I)',

36

          tablename||'_zeit_idx', tablename, 'zeit');

37

    END IF;

38

    EXECUTE format('INSERT INTO %I VALUES (($1).*)', tablename) USING NEW;

39

  RETURN NULL;

40

END;

41

$_$ LANGUAGE plpgsql;

42

CREATE TRIGGER insert_parent_trigger BEFORE INSERT ON temperatur 

43

  FOR EACH ROW EXECUTE PROCEDURE parent_insert_trigger();

So eine Monatstabelle kann man dann jederzeit auf Anomalien prüfen, wo 
ist das Problem? Wobei es natürlich sinnvoller wäre, wenn das 
Programm/Skript, das die Sensoren ausliest, schon eine 
Plausibilitätsprüfung macht und bei merkwürdigen Werten gleich eine 
E-Mail schickt oä...

Aber ich schweife ab. Für so eine Monatstabelle ist die Prüfung mit den 
von mir genannten Features dann auch ziemlich einfach und performant:

1

SELECT DISTINCT 

2

  date_trunc('hour', zeit), 

3

  MIN(ch0) OVER (PARTITION BY date_trunc('hour', zeit)),

4

  AVG(ch0) OVER (PARTITION BY date_trunc('hour', zeit)),

5

  MAX(ch0) OVER (PARTITION BY date_trunc('hour', zeit)),

6

  STDDEV(ch0) OVER (PARTITION BY date_trunc('hour', zeit))

7

FROM ONLY temperatur_2014_04

8

ORDER BY date_trunc('hour', zeit);

Damit habe ich Minimum, Maximum, Durchschnitt und Standardabweichung für 
jede Stunde im betrachteten Zeitraum April 2004. Das braucht für einen 
Kanal in einer Monatstabelle auf dem RasPi 4 (in Worten: vier) Sekunden. 
Das noch für die anderen Kanäle zu implementieren ist dem geneigten 
Leser als Hausaufgabe überlassen (mit vier Kanälen benötigt der Query 
allerdings insgesamt 15 Sekunden).

Natürlich kann man daraus einen View machen, sinnvollerweise gar einen 
Materialized View, da eine Monatstabelle nach Monatsende natürlich nicht 
mehr verändert wird. Mit einem Select auf den View (oder einen Subquery) 
kann man sich auch wunderschön die Minima und Maxima aus der kleinen 
Ergebnistabelle holen, damit kann man Fehler und Störungen schon sehr 
schön zeitlich eingrenzen...

> Merke: Die Fähigkeit zur Buzzword-Replikation ist was völlig anderes als
> echter Sachverstand.

Da muß ich mich auf Dein hochgeschätztes Urteil verlassen, mit 
Buzzword-Replikation kennst Du Dich offensichtlich viel besser aus als 
ich.

> Das war genau, was ich eingangs vorgeschlagen habe.

Dem hatte ich gar nicht widersprochen, warum sollte ich auch? 
Schließlich habe ich selbst genau das schon seit einem guten Jahr in 
Betrieb.

> Und deine Erwiderung war im Prinzip: NEEIIIN, der RasPi kann das alles
> wunderbar alleine,

Ach, das war meine Erwiderung? Komisch, zu Deinen Ausführungen hatte 
ich doch tatsächlich gar nichts geschrieben. Aber wie ich bewiesen habe, 
kann man das ziemlich einfach und ausgesprochen performant lösen, wenn 
man ein bisschen Sachverstand hat.

Nun, nachdem ich mir nun Deinen Merksatz eingeprägt habe, demzufolge die 
Fähigkeit zur Buzzword-Replikation etwas völlig anderes ist als echter 
Sachverstand, möchte ich Dir herzlich danken, daß Du mich daran erinnert 
hast. Als Gegenleistung möchte ich Dir gerne auch einen Merksatz mit auf 
Deinen vermutlich nicht einfachen Weg geben: eine große Klappe ersetzt 
jedenfalls keinen echten Sachverstand. ;-)

Vielen Dank für Deine Aufmerksamkeit,
Karl "nicht Karol" Käfer

Hallo,

Karl Käfer schrieb:
> Damit habe ich Minimum, Maximum, Durchschnitt und Standardabweichung für
> jede Stunde im betrachteten Zeitraum April 2004. Das braucht für einen
> Kanal in einer Monatstabelle auf dem RasPi 4 (in Worten: vier) Sekunden.

Ach so, das hatte ich vergessen zu erwähnen: bei mir werden die Sensoren 
einmal pro Minute ausgelesen und die Daten abgespeichert. Meine Tabelle 
enthält demzufolge 43.200 Datensätze anstatt nur 8640 bei einem 
Intervall von 5 Minuten.

Liebe Grüße,
Karl

Hallo Karol,

Karol Babioch schrieb:
> Karl Käfer schrieb:
>> und muß man dann immer noch die
>> ganze Büchse rebooten, weil man den Prozeß auch mit einem MySQL-Restart
>> und kill -9 nicht abgeschossen bekommt?
>
> Wobei man das auch dem Betriebssystem zurechnen könnte ;).

Ja, das würde ich auch sagen, wenn ich es nicht schon sowohl unter 
diversen Linuxen als auch unter Solaris gesehen hätte. Aber selbst wenn 
es wirklich nur daran läge... die anderen erwähnten Sachen sind mE. 
sogar noch viel schlimmere Showstopper als ein Zombie, der einen Core 
verbrennt.

Liebe Grüße,
Karl

Hallo Bernd,

ich habe eine ähnliche Anwendung wie Du planst am laufen.
Bei mir sind aber ausser Temperatur noch Zählerdaten von 2 eHZ und einem 
Wärmemengenzähler dabei.

Im Moment werden Temperaturen und Zählerstände in eine MySQL Datenbank 
auf meinem NAS geschrieben. Per Insert-Trigger werden aus den 
Zählerdaten Leistungsdaten generiert, damit habe ich dann, immer über 
5min gemittelt, die aktuelle Leistung. Da sieht man dann über den Tag 
den Kühlschrankkompressor takten oder erkennt wenn man vergessen hat ein 
Licht auszuschalten.

Auf dem NAS läuft zusätzlich ein Webserver zum darstellen von Graphen 
und Tabellen. Performancetechnisch funktioniert das nicht schlecht, nur 
wenn ich bei den Leistungscharts zwischen Tagen hin und herspringe 
dauert es halt immer ein paar Sekunden bis die Daten abgefragt sind.

Ein Dorn im Auge ist mir aber noch das ich ne Menge Daten mitschleife, 
die eigentlich nicht mehr gebraucht werden. Die Zählerstände im 5 min 
Raster zb sind nachdem daraus die Leistung errechnet wurde eigentlich 
nutzlos, da würde ein Wert pro Tag reichen.

Durch diesen Thread motiviert werde ich da das Konzept auch nochmal 
überarbeiten.

Variante 1:
Ich stelle komplett auf RRDtool um. Ich habe nur etwas bedenken da ich 
wie Du, die Tagesdaten schon gerne mindestens über 2 Jahre in voller 
Genauigkeit hätte um auch mal einen Vergleich zu ziehen. Ich weis nicht 
wie da die Performance ist wenn da soviele Daten im 5 Min Raster drin 
sind.


Variante 2:
Mittelwerte, Max, Min und Tagesverbrauch in die SQL DB und für jeden Tag 
die Detailwerte wie Leistung und Temperatur im JSON Format in eine Datei 
geschrieben. Die sind recht fix als Chart angezeigt und belasten nicht 
die Datenbank, vielleicht noch den Dateinamen mit in die Tagestabelle 
damit man schnell das File findet.

Im Moment tendiere ich zu Variante 2 obwohl mir das Konzept hinter 
RRDTool echt gut gefällt.

Vielleicht kommen hier ja noch ein paar gute Vorschläge wenn mal die 
Glaubenskriege beendet sind...

Karl Käfer schrieb:

[...]

Dir ist schon klar, daß das zwar eine Lösung ist, aber nicht die Lösung 
der gestellten Aufgabe, sondern für etwas völlig anderes (mit um viele 
Größenordnungen geringerer Komplexität)?

Es ist eine Lösung für das Problem, kontinuierlich auflaufende Daten auf 
für willkürliche Zeiträume separierte Tabellen zu verteilen.

Das ist nett und performancefördernd, wenn man dann ausschließlich 
Abfragen fährt, die sich auf den willkürlich gewählten oder einen 
kleineren Zeitraum beziehen.

Es ist aber nicht nur keine Lösung für jegliche Abfragen, die sich auf 
den gesamten Zeitraum beziehen, sondern im Gegenteil für diesen Fall die 
schlimmste aller denkbaren Performance-Bremsen.

Hallo Axel,

Axel Schwenke schrieb:
> Entweder lügst du oder du hast das während einer Therapiesitzung
> geträumt. Kein Prozeß kann SIGKILL abfangen oder anders darauf
> reagieren als daß er sich beendet.

Tja, das sollte man meinen, und vielleicht würde ich es auch nicht 
glauben, wenn ich es nicht selbst erlebt hätte. Aber vielleicht möchtest 
Du mal in die Manpage von select(2) schauen? Da stehen ein paar extrem 
interessante Sachen drin, insbesondere zu den Themen Blocking, Timeouts 
und Multithreading.

> Und zwar deswegen, weil das außerhalb
> der Kontrolle des Prozesses liegt. Da ist allein das Betriebssystem
> dafür zuständig.

Mir ist natürlich klar, daß jemand, der sein Geld mit MySQL verdient, es 
verteidigen muß und vielleicht auch einen etwas geschönten Blick darauf 
haben muß. Aber ich habe schon genug Probleme und sogar Datenverluste 
mit MySQL erleben müssen und bin aus genau diesem Grund schon vor Jahren 
auf eine Datenbank umgestiegen, die mir keine solchen Schwierigkeiten 
macht. Ob man in MySQL heute etwas konfigurieren kann, finde ich schon 
ziemlich lächerlich -- was für eine Datenbank soll denn das sein, bei 
der man die Datenintegrität erst konfigurieren muß? -- aber letztlich 
ist mir das ehrlich gesagt schnurzpiepegal. Wenn mein Vertrauen einmal 
weg ist, dann ist es erstmal weg. Und indem Du mich beschimpfst oder mir 
irgendwelchen Unsinn unterstellst, werden Du und Dein MySQL-Team mein 
Vertrauen sicher nicht zurückgewinnen. Deswegen habe ich jetzt 
PostgreSQL und komme damit endlich wieder in den Genuß von etwas, das 
ich mit MySQL eben leider nicht mehr hatte: nämlich einen ruhigen 
Schlaf.

Liebe Grüße,
Karl

Hallo,

c-hater schrieb:
> Dir ist schon klar, daß das zwar eine Lösung ist, aber nicht die Lösung
> der gestellten Aufgabe, sondern für etwas völlig anderes (mit um viele
> Größenordnungen geringerer Komplexität)?

Nö. Ich habe genau die Aufgabe gelöst, die Du gestellt hattest, mit 
einer überschaubaren Komplexität -- das die Komplexität überschaubar 
ist, hatte ich ja schon in meinem ersten Beitrag erwähnt -- mit einer 
hervorragenden Performanz und mit genau jenem Feature, das ich erwähnt 
und welches Du als "Buzzword-Replikation" abgetan hattest.

> Es ist aber nicht nur keine Lösung für jegliche Abfragen, die sich auf
> den gesamten Zeitraum beziehen, sondern im Gegenteil für diesen Fall die
> schlimmste aller denkbaren Performance-Bremsen.

Nachträglich die Aufgabe ändern und dann behaupten, die präsentierte 
Lösung würde nicht dazu passen, ist einfach lächerlich. Wenn Du schon zu 
solchen Tricksereien greifen mußt, kannst Du in der Sache offensichtlich 
nichts mehr entgegnen.

Auch Deine Aussage, die Verteilung der Daten auf mehrere Tabellen sei 
eine Performancebremse, ist totaler Quatsch. Abfragen, die sich über den 
ganzen Zeitraum beziehen, werden im besten Fall beschleunigt, und im 
schlimmsten nicht verlangsamt. Wenn man keine Ahnung hat, ... genau.

Liebe Grüße,
Karl

Hallo zusammen,

kurze Rückmeldung: habe zig Seiten im Internet gelesen und in alten 
Büchern gewühlt und bin dann letztendlich doch bei einer SQL Tabelle 
(derzeit: SQLite) gelandet. Habe an der Stelle keine Performance 
Einbrüche festgestellt (ok, die kommen auch erst über die Zeit wenn die 
Tabelle wächst), wobei auch rrdtool mehr als ausreichend schnell war. 
Entscheidung für SQL war dann ein "gewohntes" Umfeld und die Möglichkeit 
alle Daten aufzuheben. Wenn es denn mal eng werden sollte, gibt es 
sicher die Rev D des Raspberyy Pi mit mehr Power...  Ich kann aber auch 
gerne ein paar Sekunden auf eine Grafik warten, frage die ja nicht alle 
drei Sekunden ab.
Derzeit kämpfe ich mehr mit der richtigen Verdrahtung, bin jetzt weg von 
parasitärer Versorgung, da ich bei einigen Sensoren manchmal keine Werte 
erhalten hatte. Gibt es eine "perfekte" Anschaltung für 1-wire Sensoren 
an einen Controller der gegen Störungen geschützt ist und lange 
Leitungslängen erlaubt?
Danke für eure Mühen und begrabt das Kriegsbeil.

Gruß, Bernd