Ich steh grad vor ein paar Überlegungen, und da sich ja hier das Know How sammelt, hoffe ich, der eine oder andere hat da Ideen.
Zwar geht es um die Speicherung von Messdaten auf einen Embedded Gerät. Gemessen wird hier am Zählpunkt, die Spannungen, Strom sowie die Energie aus dem und ins Netz. Meist alle 30 Sekunden, da kommt schon ein bisschen was zusammen. Das jetzige Gerät speichert diese Daten in einer CSV ab, was hier kein Problem ist, da diese so auf den Server geladen werden, wo eh dann alles in einer MongoDB landet.
Aber beim neuen Gerät finde ich CSV nicht mehr so effektiv, da dieses zukünftig einen Touchscreen besitzen soll, und somit am Gerät schon einige Auswertung angezeigt werden sollen, die bisher nur online mögich sind. Nur stehe ich grad an, was wäre die Alternative? Das ganze ist ein ARM mit einen angepassten Linux BSD. Dachte zuerst an sqlite, wo ich zwar die Daten abfragen könnte, bin mir aber nicht sicher ob das effektiv genug ist. Hätte jemand weitere Alternativen im Kopf?
Zum Prozessor selbst: ein ARM9 mit 454MHz und dazu ein 128MiB DDR2 RAM angebunden über einen 16bit Bus.
Ich würde bei CSV bleiben. Das kann man immer weiterbearbeiten.
Was hat die Anzeige mit dem Dateiformat zu tun?
Werden die Daten tabellarisch oder graphisch angezeigt?
Die Daten sollen grafisch dargestellt werden. Auf 7" ist ja ein bisschen Platz dafür. Irgendwie hab ich eine kleine Abneigung gegen CSV, liegt vielleicht am jetzigen Gerät. Die Darstellung soll aber schon über mehrere Tage einfach sein, ist da das Auswerten aus den CSV Dateien nicht eher unpraktisch?
Mir ist jetzt gerade noch BSON (binäres JSON) eingefallen, das verwendet MongoBD ja auch um die Daten abzuspeichern, sowie in der Übertragung.
ich denke auch entweder sqlite oder so etwas wie json/csv auf binärebene
Das hängt bisschen davon ab was du mit den Daten auf dem Gerät machen willst.
Spätestens wenn du irgendwie suchen oder andere Operationen machen willst die man gut mit Datenbanken machen kann würde ich sqlite nehmen.
Ja eben diverse Diagramme über die Zeit erstellen, Daten aggregieren und diverse Berechnungen. Wem es interessiert, ich gebe euch gerne den Link zur derzeitigen Monitoring Plattform. Am liebsten wäre mir MongoDB am Gerät, dafür ist die Leistung definitiv nicht da ^^ Und nur mit den Daten direkt aus einer entfernten Datenbank / über Webservice zu arbeiten geht nicht wirklich, da nicht sichergestellt ist, das am Einsatzort überhaupt ein Netz vorhanden ist.
Edit zu kappesf: naja sollte dazu sagen, das hier noch ein paar komplexe Regelalgorythmen ablaufen. Und auf das Rendering der GUI darf man auch nicht vergessen. Sehe zwar zu, das ich auf 16bit für das Display runterkomme, aber aktuell mit 24bit geht da bisschen was an Leistung verloren. Als Speicher soll eh eine SD Card zum Einsatz kommen und nicht der interne Flash.
Als Alternative zu SQLite fallen mir noch die Berkeley DB und extremeDB (kostet aber was) ein. Grob überschlagen dürften bei deiner Anwendung pro Tag unter 100 kB an Daten anfallen; hattest du mal Gelegenheit zu testen ob deren Verwaltung wirklich einen inakzeptablen Flaschenhals darstellt?
Da hast Du das Problem der Anbindung des TouchPanels an den Prozessor. Bei mir ist es über RS485, das ist so langsam das ich die Graphen auf dem BlackFin vorberechne/normiere und nur noch die eigentlichen Ergebnisse rüber schiebe.
Dachte zuerst an sqlite, wo ich zwar die Daten abfragen könnte, bin mir aber nicht sicher ob das effektiv genug ist. Hätte jemand weitere Alternativen im Kopf?
Jetzt kommt es eigentlich darauf an wie lange die Daten vorgehalten werden sollen. Wenn es aber nur ein kleiner Datensatz ist sollte SQLite reichen. Wobei ich eher der Pragmatiker bin und das ganze erstmal in einem eigenen binärem Format speichern würde.
@Dow_Jones : im Moment hat so eine Tages-CSV rund 580kB an. Zum Testen bin ich noch nicht viel gekommen. Darum ja unter Theoretisches ^^ BerkleyDB aufn Embedded, hmm. Hab aber noch nie damit gearbeitet.
@mogel : Da habe ich eine etwas glücklichere Anbindung. Geht über eine richtige parallele RGB-Schnittstelle. Das übernimmt dann der i.MX28 mit dem in der Hardware integrierten LCD_IF Schnittstelle. Die Frames müssen nur über DMA im Speicher abgelegt werden, was durch den MSX-Framebuffer leicht erledigt ist.
@kappesf : Ist eure Grafiklib eine Eigenentwicklung oder ist diese frei verfügbar? Ich habe derzeit mal Qt mit dem integrierten Qt Window Server im Einsatz, was ganz gut läuft.
Da habe ich eine etwas glücklichere Anbindung. Geht über eine richtige parallele RGB-Schnittstelle. Das übernimmt dann der i.MX28 mit dem in der Hardware integrierten LCD_IF Schnittstelle. Die Frames müssen nur über DMA im Speicher abgelegt werden, was durch den MSX-Framebuffer leicht erledigt ist.
okay - damit klärt sich die PN - das TouchPanel was wir nutzen hat halt Embedded-Linux. Da läuft dann das HMI drauf mittels Qt (hat richtig gut getan mal wieder C++ zu machen).
[QUOTE=TheDarkRose] @kappesf : Ist eure Grafiklib eine Eigenentwicklung oder ist diese frei verfügbar? Ich habe derzeit mal Qt mit dem integrierten Qt Window Server im Einsatz, was ganz gut läuft.[/QUOTE]
Ne Eigenentwicklung, da es nichts freies gab was auch nur annähernd performant genug gewesen wäre. Das ist inzwischen eben alle sauf mehr Leistung ausgelegt wie z.B. im Mobile Bereich. Die Darstellung im Panel ist nebensache, die Steuerprozesse müssen vor allem performant laufen. Zudem Kommunikation zu anderen Anlagenteilen etc. Dafür ist die Grafik lib halt auch sehr einfach gehalten. Sieht eben nicht aus wie Metro Oberflächen
Da gehts eben auch um Sicherheit. Die sqlite verwenden wir inzwischen schon recht lange (auf externen SSDs mit Industrie Spezifikationen falls große Datenmengen). Da kann aber dann eben nur ein Prozess zugreifen da es file dbs sind. Verteilt wird über ein Event System zwischen den Prozessen. Ein Prozess verwaltet die db und stellt Daten bereit. Die Anderen fragen ab und füttern.
Ich werde mir mal Qwt für die Widgets anschauen. Die Screenshots sehen zwar nicht sehr schön aus, aber ich hoffe darauf, dass das alles eine Frage des Applikationsdesign ist
Ansonsten habe ich ja zum Glück nicht soviele Anlagenteile. Ein Analogausgang mit PID-Regler sowie ein paar Sensoreingänge. Höchsten das über RS485 aller möglicher Grims Grams noch dazu kommt. Da sollte aber eine Verschiebung des Codes in „Realtime“ mittels Xenomai reichen, falls dies überhaupt nötig ist.
Holla, da lag ich aber heftig daneben. Ich schiebe das dann mal auf das CSV Format… ^^; Mit der BDB hatte ich auch vor Jahren zuletzt gearbeitet, fand sie damals aber prima. Beim googeln bin ich dann gerade auf die Lighning MDB gestoßen (offenbar Teil von OpenLDAP). Die soll wohl leichtgewichtiger als die BDB sein, aber weitgehend kompatibel. Deren Microbenchmark schaut zumindest schon mal vielversprechend aus.
Was mir ansonsten noch ad Hoc zur Performancesteigerung einfällt - sofern nicht gerade der gesamte Datenbestand in einem einzigen Diagramm angezeigt werden soll könnte man einen Thread im Hintergrund laufen lassen, der die Daten in regelmäßigen Abständen für die Anzeige aufbereitet (also die für’s Diagramm relevanten Daten extrahiert/berechnet) und in separaten Tabellen abspeichert. Das könnte im Extremfall eigentlich sogar soweit gehen, das die komplette Bitmap eines Diagramms im voraus erzeugt wird. Nach jeder Messung müsste man dann halt nur noch die neuen Messdaten einzeichnen. (Jaja, ich weiss, schön ist das nicht. Aber u.U. recht effektiv. )
Also die Benchmarks zu MDB sehen schon interessant aus. Auch das es gerade mal zusätzliche 32KiB an Objektcode ist. Ist zwar nur ein simpler Key-Value Store, aber sollte ausreichen. Timestamp der Messung als Key und alle Messwerte als JSON im Value abspeichern.
Ich mache ähnliches. Datenerfassung läuft per CronJob 1x/Minute. Daten wandern in eine MySQL-Datenbank. Ganz grob etwa so:
data:
id
entityid
value
entities:
id
name
Das ganze läuft auf einem Sheevaplug-Computer mit Debian Linux im Heizungskeller. Auswertung erfolgt über eine PHP getriebene Webseite (wird ebenfalls auf dem Sheevaplug gehostet). Anzeige der Graphen erfolgt mit der Google Chart API (https://developers.google.com/chart/).
Hab jetzt knapp 1 1/2 Jahre lang jede Minute ungefähr 40 Werte in der DB gesammelt (mehrere hundert MB). Geht immer noch flott.
Ich glaube ich mache mir da echt zu viele Gedanken darüber. Wobei relationele DBs mag ich nicht so sehr, daher die Suche nach einer Alternative ^^
Denn es kann jedes Gerät unterschiedliche Messdaten erzeugen. Klar könnte ich (bzw. müsste ich bei sqlite, wie auch MDB) eine value-Spalte wo man eben z.b. ein JSON-String oder serialisiertes Array ablegt. Bei BSON könnte ich über die Daten traversieren ohne einen Zwischenschritt zu parsen… Hmm, mal sehen.
Geht ja doch um ein paar Hundert Geräte im Jahr ^^
Also ich hab jetzt rund 40Mio Datensätze (870k Messungen mit je 46 Werten) in der MySQL DB. Sind 230MB an Daten. Ich mach mir da absolut keine sorgen. Das kann nochmal 10 Jahre laufen… Wobei ich irgendwann anfange die Daten zu dumpen und aus der DB zu nehmen (weil die 4GB SD Karte im Sheevaplug irgendwann voll ist und ich auch ein Backup haben möchte).
Speicherplatz selber ist IMHO kein Problem außer bei Geräten ohne Internetverbindung. Die Daten werden regelmäßig in unser Online Monitoring übertragen und am Gerät eine bestimmte Vorhaltezeit. Dort werkelt eh eine MongoDB. Bevor ich es übernahm waren es auch nur 1,17 Mio Datensätze auch gute 117 MiB Speicher. Der Nachteil bei einer dokumentenorientierten Datenbank ist halt, das jedes Dokument (jeder Messwert) immer alle relevanten Felder namentlich beschreibt. Mit Indizes kommt eine durchschnittliche Größe von 206 Bytes pro Messwert zusammen. Dafür gewinnt man vollkommene Flexibilität was die gespeicherten Werte anbelangt. Können bei jeden Gerät anders sein, da individuell konfigurierbar.
So ähnlich würde ich das auch am Gerät bevorzugen. Mit einer einzigen value-Spalte verliere ich einfach die Abfragbarkeit nach nur bestimmten Messwerten… Gut ohne DB-System is eh die Frage, wie man eine ordentliche Abfragbarkeit erledigt.
- das TouchPanel was wir nutzen hat halt Embedded-Linux. Da läuft dann das HMI drauf mittels Qt (hat richtig gut getan mal wieder C++ zu machen).
)