-         

Ergebnis 1 bis 5 von 5

Thema: Messwerte für grafische Darstellung speichern in ein SQL Datenbank

  1. #1
    Erfahrener Benutzer Begeisterter Techniker
    Registriert seit
    07.11.2004
    Beiträge
    332

    Messwerte für grafische Darstellung speichern in ein SQL Datenbank

    Anzeige

    Hallo Zusammen,

    ich möchte Messwerte (zyklisch erfasste Daten) in einer SQL Datenbank (mySQL) abspeichern. Hierbei sollten die Daten idealerweise in komprimierter Weise gespeichert werden und später für die Darstellung in einem Trenddiagramm bereit stehen. (Min. Sekundentakt).

    Die Software wird unter kUbuntu und Verwendung von QT4.7 und C++ erstellt.

    Ich dachte hierbei an der Verwendung eines BLOB Field, wobei ich hier noch Problem (gedankliche) in der internen Verarbeitung habe:

    - Die Messwerte sollten mit Zeitstempel abgelegt werden
    - Jeder Messwert muss seiner Messquelle (Tagname) zugeordnet werden können
    - Es sollten/werden Stützwerte (wenn der Messwert sich länger nicht ändert) im festen Zeitraster abgelegt
    - Das Beschreiben der Daten erfolgt in einem seperaten Thread, welcher die Daten zyklisch ablegt
    - Das Auslesen sollte zeitgleich möglich sein, bis zu den zuletzt abgelegt Daten.

    Das ganze sollte zeitlich so schnell wie möglich sein. Hat jemand eine Idee, wie ich das Zwischenspeichern von Werten
    machen könnte, wenn die SQL Datenbank nicht erreichbar ist.

    Gruss R.
    Kaum macht man es richtig, schon funktioniert's ...

  2. #2
    Erfahrener Benutzer Roboter Genie
    Registriert seit
    11.08.2008
    Ort
    Hallein
    Alter
    26
    Beiträge
    802
    Ich würde dir MongoDB empfehlen. Eignet sich für sowas viel besser, besonders wenn man die Daten nachträglich auswerten will. Mit Map/Reduce geht das dann super.
    Kultuverein Metal Resurrection, für mehr Bands und Konzerte in Österreich (:

  3. #3
    Erfahrener Benutzer Begeisterter Techniker Avatar von schorsch_76
    Registriert seit
    25.03.2012
    Ort
    Kurz vor Neuschwanstein
    Alter
    41
    Beiträge
    398
    Ich schreib zum Beispiel meine PV Anlagendaten in eine SQL Tabelle (PostgreSQL) . Um den Speicherplatz brauchst du dir nicht viele Gedanken machen. 4 Jahre (2 min Takt) sind bei mir grade mal ca 12 MB im unkomprimierten SQL Textformat. Gezippt sinds dann nur 3 MB.
    SQL ist dafür da dir die richtigen Datentypen zu liefern. Du brauchst nicht in einem Blob rumhantieren wenn du Spannungen/Ströme etc aufnehmen willst. Die Kompimierung macht der DB Server für dich.

    Eien Tabelle wie du sie möchtest würde ich wie folgt anlegen:
    date_time (DATE_TIME)
    tag (VARCHAR)
    messwert(REAL)

    Ein SQL Server kann die konkurrierenden Aufrufe handhaben. Das ist seine Aufgabe

    Eine Abfrage wäre dann etwa so:
    Code:
    SELECT messwert FROM datatable
    WHERE DATE(date_time)='2013-02-01'
    ORDER BY date_time;
    Einfügen:
    Code:
    INSERT INTO datatable
    (date,messwert,tag) VALUES(NOW(),12345,"was weis ich");
    Kuck dir die die Tutorials zu SQL im Netz an.

    Bsp.
    http://www.mysqltutorial.org/
    http://dev.mysql.com/doc/refman/5.1/de/tutorial.html

    Gruß
    Georg

  4. #4
    Erfahrener Benutzer Begeisterter Techniker
    Registriert seit
    07.11.2004
    Beiträge
    332
    Hallo Georg,

    im Prinzip wäre mir das auch lieber so, da ich in diesem Fall mir keine Gedanken für die Daten machen muss.

    Ich werde das so dann mal ausprobieren und schaue mir dann die Datengröße an.

    SQL ist mir eigentlich schon bekannt, da ich bereits eine SQL Datenbank für ein Meldesystem (Alarme/Events) im Einsatz habe. Nur bei historischen Trenddaten können andere Ansätze besser sein. So kenne ich z.B. eine Lösung von Siemens (PMQ) für historische Trenddaten und hier sind die Datenbanken gleich mehrer MB gross nach einem Tag.

    @TheDarkRose
    Ich hab mir kurz die Wiki von MongoDB angesehen. Ich kannte diese Datenbank bis dato nicht.
    Derzeit weiss ich nicht ob mein SQL Server (externer Rechner im Netzwerk, QNAP NAS Server) diese Art der Datenbank unterstützt. Ebenso weiss ich nicht, wie eine Anbindung dieser Datenbank für meine Zwecke möglich ist. Das sind derzeit zuviele "ich weiss nicht", daher schaue ich mir erst mal den MySQL nochmals genauer an. Schliesslich soll es ja auch so einfach wie möglich sein. Bei einem "normalem SQL Server sind mir die Strukturen kein Geheimnis, bei einem OO-DB bin ich absoluter Anfänger.

    Gruss R.
    Geändert von Ritchie (02.02.2013 um 19:40 Uhr)
    Kaum macht man es richtig, schon funktioniert's ...

  5. #5
    Erfahrener Benutzer Roboter Genie
    Registriert seit
    11.08.2008
    Ort
    Hallein
    Alter
    26
    Beiträge
    802
    MongoDB ist keine OO-DB. Die ist dokumentenorientiert. Datensätze werden als JSON Doc abgespeichert. Ganz fein, vor allem ist es schemalos. Mit der Größe hast du etwas recht. Habe dies bei meinen aktuellen Projekt im Einsatz zur Auswertung vom Messdaten im Zählerschrank. ~1Mil Datensätze kommen auf ~200MB. Dafür ist die DB sehr schnell und mit Map/Reduce kannst du beliebige Auswertungen fahren, die mit SQL niemals möglich wären.
    Für C++ gibt es einen schönen OO-Connector, genauso wie für PHP.
    Kultuverein Metal Resurrection, für mehr Bands und Konzerte in Österreich (:

Ähnliche Themen

  1. Python und SQL habe da ein Problem...
    Von Sebas im Forum Offtopic und Community Tratsch
    Antworten: 1
    Letzter Beitrag: 13.04.2012, 16:47
  2. Font and Bitmap Generator für grafische LCDs z.B. KS0108
    Von muGUI im Forum Allgemeines zum Thema Roboter / Modellbau
    Antworten: 2
    Letzter Beitrag: 21.02.2010, 18:58
  3. Messwerte speichern
    Von Kuwe im Forum Bauanleitungen, Schaltungen & Software nach RoboterNetz-Standard
    Antworten: 7
    Letzter Beitrag: 17.11.2009, 20:32
  4. Grafische Darstellung von Fahrdaten mit xdraw
    Von harm-1 im Forum Robby RP6
    Antworten: 1
    Letzter Beitrag: 04.03.2009, 21:19
  5. Datenbank für Bauteile??
    Von Goblin im Forum Elektronik
    Antworten: 17
    Letzter Beitrag: 09.06.2004, 15:43

Stichworte

Berechtigungen

  • Neue Themen erstellen: Nein
  • Themen beantworten: Nein
  • Anhänge hochladen: Nein
  • Beiträge bearbeiten: Nein
  •