Skip to content

Messdaten Speicherung

Jump to bottom Edit New page
Ronny Hartenstein edited this page May 12, 2015 · 11 revisions

Warnung: Das ist ein erster Vorschlag, wie die Speicherung umgesetzt werden könnte

  • Ansprechpartner: Chemnitzer OK Lab (Morris, Phibo, Ronny, Tobi)

Format

  • Messstation
    • Ortsangabe
    • Eigentümer, Ansprechpartner, Kontakt
    • Lizenzierung
  • Messdaten
    • Zeitangabe
    • Messtyp/Datentyp (Innen-/Außentemparatur, Windgeschwindigkeit, Lärmpegel, ...)
    • Messgenauigkeit (Abweichung, kann sich eventuell ändern)
    • Messwert
    • Referenz auf Messstation

Die Idee ist es, dass man Messdaten möglichst einfach abspeichert. Dafür sind die obigen 5 Eigenschaften wichtig.

Die Zeitangabe soll in einem übergreifenden gleichen Format abgebildet werden. Hier bietet sich ISO8601 an (2009-01-01T12:00:00.000+01:00). Als Zeitzone sollte UTC gewählt werden, somit ist man global unabhängig.

Der Messtyp soll erfassen, um welche Art von Daten es sich bei dem erfassten Wert handelt. Hierbei sollte aus einer definierten Menge an möglichen Werten ausgewählt werden, um die übergreifende Korrelation zu ermöglichen.

Die Messgenauigkeit kann beispielsweise sich während der einzelnen Messungen unterscheiden, wenn z.B. ein Sensor in einem gewissen Messbereicht höhere Genauigkeiten liefert. Hier ist noch zu schauen, wie man die Genauigkeit erfasst (prozentual, absolut, ...).

Der Messwert enthält den gemessenen Wert in einem (zum Messtyp) einheitlichen Format. Hier bieten sich SI-Einheiten und deren abgeleiteten Typen an. Wir müssen hier eine Zuordnung von Messtyp auf die jeweilige Einheit vornehmen, damit eine übergreifende Nutzung der Daten möglich ist.

Die Referenz auf die Messstation sollte ein einfacher Schlüssel sein, um den Messwert einer Station zuordnen zu können. Beispiel: Chemnitz-1

Architektur

Wir (Code for Chemnitz) haben uns folgende Ideen, zur Umsetzung einer dezentralen Speicherung (einzelne Städte) der Messdaten gemacht. Wir sind dabei zu folgenden Anforderungen gekommen:

  • einzelne Messdaten sind nahezu unabhängig voneinander - einfaches Schreiben an unterschiedlichen Standorten und späteres Zusammenführen keinerlei Problem
  • einzelne Messdaten sollen möglichst lokal vorgehalten werden können
  • es können sehr schnell sehr viele Daten anfallen (20 Stationen mit 5 Sensoren a 1 Messwert pro 5 Minuten in 1 Jahr: 10,5 Millionen Messwerte)
  • sollten bestmöglich auch lokal durchsuchbar/verarbeitbar sein - Anbieten von Dumps zum lokalen Verarbeiten
  • Backup? - Idee: Verteilung in Monats-/Jahresdumps via Torrent

Relationale Datenbank

  • 👎 Konsistenz-Bedingung der Datensätze untereinander viel zu stark
  • 👎 extrem starres Schema
  • 👎 Skalierung auf ein verteiltes Netz schwierig
  • 👎 zu viele Features, die nicht benötigt werden -> später potentielles Performance-Problem

NoSQL

  • 👍 Schema frei gestaltbar - ⚠️ wir sollten uns dennoch an ein gewisses Grundschema halten, da die Daten sonst extrem schwer zu verarbeiten sind
  • ⚠️ keinerlei Datensatz-Referenz-Konsistenz - Verweise auf nur wenige Datensatz-externe Daten (Messstation, Messtyp - im Bereich weniger hundert Einträge) - manuell machbar
  • Verteiltheit besser skalierbar - jeder kann vorerst mit eigener Instanz starten und es sollte eventuell ein Weg gefunden werden alle einzelnen Instanzen über eine Wrapper-Instanz anzusprechen
  • Lokale Verfügbarkeit: Aufsetzen - Gewünschte Dumps einspielen - Daten nutzen

Alternative: SOS

von @johnjohndoe: Ich möchte an dieser Stelle darauf hinweisen, dass es einen Standard für die Verwaltung von Sensor-Messdaten gibt. Dieser heißt Sensor Observation Service (SOS) und wurde vom Open Geospatial Consortium (OGC) veröffentlicht. Das sind die Leute, die auch Standards wie WFS und WMS verzapft haben.

Der Vorteil des SOS ist, dass Sensordaten – gleich welcher Art – in einem einheitlichen Format und über standardisierte Operationen im Internet verfügbar werden und somit der webbasierte Zugriff auf Sensordaten vereinfacht wird.

Ich weiß, dass die Dokumente etwas sperrig sind - und XML abschreckend. Aber da ich vor kurzem einen Workshop zu diesem Thema besucht habe, bin ich sehr angetan von SOS. Der Workshop wurde von 52North auf der FOSSGIS veranstaltet, die eine Referenzimplementierung für SOS in Java geschrieben haben. Diese ist Open Source. Zu dieser Server-Komponente gibt es noch einen Proxy, der eine REST-Schnittstelle abbildet. Hier gibt es eine Aufzeichnung eines Vortrags, der ähnlich zum Workshop ist. Ergänzend gibt existiert eine JavaScript-basierter Client, der die Sensordaten grafisch darstellen kann. Diese Anwendung ist ebenfalls Open Source und für mobile optimiert und getestet.

Anmerkungen

Add a custom footer
Add a custom sidebar
Clone this wiki locally