Messdatenerfassung mit Datenbank

[Johann Gysin]

Guten Tag

Es geht um die Entwicklung eines Messdatenerfassungssystems. Zur Zeit erarbeiten wir im Team die Grundlagen und sind auf einige Grundsatzprobleme gestossen. Eines liegt darin, wo wir die Messwerte speichern sollen. Eine Idee bestand darin, alle anfallenden Messwerte mit einem Zeitstempel zu versehen und diese direkt in eine schnelle SQL-Datenbank (z.B. My-SQL oder InterBase) zu speichern. Gleichzeitig sollen die Messwerte (vom Messbeginn bis aktuell) von der Datenbank ausgelesen und visualisiert werden können (auf zwei bis drei Clients gleichzeitig).<br>

Ich versuchte das ganze mit einigen Versuchen in Delphi und My-SQL zu testen und bemerkte rasch, dass das ganze einfach zu langsam ist.<br>

Einige Daten:
- Es sollen 250 Kanäle erfasst werden (Die meisten Messwerte sind 8/16 Bit Integer)<br>
- Alle Kanäle werden mit 1Hz gesampelt<br>
- Eine komplette Messung dauert ca. 45min<br>
- In der Woche finden ca. 3 Messungen statt<br>
- An ca. 40 Wochen im Jahr wird gemessen<br>
- Das System soll 10 Jahre funktionieren können<br>

Damit ergibt sich eine Zahl von 810'000'000 einzelnen Messwerten (mit Zeitstempel, Messungsnummer, Kanalnummer). Es wäre zwar schön, wenn es ginge, aber ich glaube nicht so recht daran, dass es sinnvoll oder gar möglich ist, diese Datenmenge in einer einzelnen Tabelle zu verwalten.<br>

Nun meine Fragen:<br>
Ist es überhaupt empfehlenswert, die Messwerte in einer Datenbank zu speichern?<br>
Kriegt man die Performance in den Griff, falls man einen "vernünftigen" Datenbankserver hat, selbst wenn in einigen Jahren 10GB an Messwerten vorhanden sind?<br>
Sollte man die Messwerte nicht in eine einzelne Tabelle speichern, sondern auf mehrere verteilen?<br>

Ich danke schon jetzt vielmals für die Antworten<br>
John

[Falk Prüfer]

Hallo Johann,

je nachdem was man unter einem "vernünftigen" Datenbankserver versteht sehe ich in der Datenmenge kein Problem. Heutige SQL-Datenbanksysteme sind darauf ausgelegt riesige Datenmengen zu handeln. Auch die Performance für die Auswertung auf 3 Clients sollte ausreichen.
Wo ich Schwierigkeiten sehe, ist das Handling der vielen kleinen Transaktionen. Bei Euren Echtzeitmessungen bedeutet das Transaktion starten - Insert - Commit und das einmal in der Sekunde mit "Peanuts". Wenn dort der DB-Server mal mit 1,5 sec aus dem Tritt kommt wars das. (1,5 sec sind für eine Transaktion nicht langsam) Ich würde die anfallenden Messwerte Lokal im Hauptspeicher zwischenpuffern und dann in größeren Blöcken (in einem separaten Thread) in die DB schreiben. Damit fällt das Verhältnis der Zeit die zum eigentlichen Schreiben benötigt wird und der für das Transaktionshandling sehr viel günstiger aus. (Nur noch eine Transaktion für 100 Messwerte z.B.) - Das hat aber den Nachteil, das die Anzeige der Messwerte auf den Clients um diese Pufferzeit hinterherhinkt. Wenn das nicht akzetabel ist, dann müßtet ihr euch auf die Suche nach einer Echtzeitfähigen DB machen - ob allerdings MySQL und IB dazugehören? - k.A.

Gruß Fal

[Johann Gysin]

Hallo Falk<br>

habe mir natürlich auch schon überlegt, was ein "vernünftiger" Datenbankserver für dieses Projekt ist... :-)<br>
Folgende Kombinationen habe ich ausprobiert:<br>
<br>
1. PC mit Pentium I 166MHz und Win98, 96MB RAM, schneller IBM Platte und MySQL<br>
- Dieser kann ca. 300 Messwerte/s speichern. Liest man gleichzeitig Messwertereihen aus, sinkt diese Zahl auf praktisch null.<br>
<br>
2. PC mit Pentium III 450MHz und WinNT, 96MB RAM, langsamer Seagate Platte und MySQL<br>
- Diese Kombination speichert etwa 1'200 Messwerte/s. Liest man Messwertereihen aus, sinkt die Zahl auf etwa die Hälfte.<br>
<br>
Bei diesen Versuchen war die Datenbank mit etwa 100MB an Daten gefüllt, was nicht sehr viel ist. Client und Server waren mit einem 10Mbit Ethernet-Netzwerk miteinander verbunden. Darin sehe ich momentan keinen Flaschenhals, doch werden wir beim eigentlichen System sicher gleich auf 100Mbit gehen.<br>
<br>
Was würdest Du für ein System vorschlagen? Es darf natürlich auch eine andere Plattform sein (Linux, Solaris.......). Beim Datenbankserver bin ich auch ziemlich frei, wenn der Preis in etwa angemessen ist.<br>
<br>
Das mit dem zwischenpuffern der Daten kann ich verstehen, das macht sicher Sinn und würde wohl auch nicht gross stören, wenn die angezeigten Daten 10 oder 20 Sekunden verzögert angezeigt würden. Wie Du sicher bemerkt hast, bin ich ein Neuling bei Datenbanken. Darum bin ich um jeden Tipp sehr froh.<br>
<br>

Viele Grüsse<br>
Johan

[Falk Prüfer]

Hallo Johann,

ich denke mal daß ihr euch über die Grundlegende Struktur eures Projektes schon genügend den Kopf zerbrochen habt - deshalb will ich da auch nichts in Zweifel stellen - möchte aber trotzdem ein paar "Denkanstöße" setzen. Zum Ablegen und Archivieren der Messwerte ist eine SQL-DB sicherlich die richtige Wahl, Das dies sogar auf einer PI Maschine funktioniert hast Du ja selbst ausprobiert. Die Stärke einer SQL-DB (die Daten auf dem Server aufbereiten und dem Client nur die - statische - Ergebnismenge zurückliefern) ist in Eurem Fall wahrscheinlich die größte Schwäche - oder wie löst ihr das Problem, die Daten auf dem Auswerteclient aktuell zu halten? Ich denke mal das geht nur durch das permanente starten der Select-Abfrage und das beschäftigt den DB-Server natürlich erheblich (was Du an den Erfassungseinbrüchen siehst).
Evtl. wäre es günstiger, die DB als "Messwertarchiv" zu nutzen und den Auswerteclient auf anderem Wege über die Messwerte zu informieren. Möglich wäre sicherlich eine direkte TCP/IP Verbindung oder die Benachrichtigung über MIDAS/DCOM. Damit beschränkt sich dann der Netzwerktraffic nur auf die "paar neuen Bytes".

Das sind so ein paar Überlegungen aus meiner SQL-Praxis - was den tatsächlichen Einsatz unter Echtzeitbedingungen angeht habe ich keine eigenen Erfahrungen, vielleicht hat dazu hier im Forum noch jemand ein paar "handfestere" Tips?

Gruß Fal

[Johann Gysin]

Guten Morgen Falk

Das sehe ich auch so, dass man nur jeweils die neuen Messwerte von der Datenbank abfragen würde. Somit könnte man beim Aufruf eines neuen Kanals in der Auswertesoftware per Select-Befehl alle Messwerte abrufen und dann in regelmässigen Abständen (alle 10s oder so) nur noch die neuen, noch fehlenden, Messwerte abfragen.<br>
Momentan schwebt mir eine dreischichtige Datenbankanwendung vor.<br>
Auf alle Fälle bin ich froh, dass das Grundkonzept mit der Datenbank als Messwertsammelstelle nicht ganz neben den Schuhen ist. Irgendwie werden wir das hoffentlich schon zum laufen kriegen in ferner Zukunft... :-)<br>
<br>
Vielen Dank für Deine Anregungen und Grüsse<br>
Johan

[Johann Gysin]

......da ist noch was aufgetaucht:

Spricht etwas dagegen, für jeden Messversuch eine neue Tabelle in der SQL-Datenbank zu erzeugen?<br>
Bei einem Versuch stellte ich fest, dass bei diesem Vorgehen sogar die alte Pentium I Maschine beinahe genug schnell ist mit der select Abfrage alle paar Sekunden.<br>
Im ganzen "Lebenslauf" des Systems würde es somit 1'200 Tabellen + 1'500 Tabellen (alte, ins neue System zu konvertierende Messdaten) = 2'700 Tabellen mit Messdaten ergeben.<br>

Grüsse<br>
Johan

[Falk Prüfer]

... ist aber eigentlich entgegen jeder Logik. Warum willst Du wieder zerstückeln, was mühsam zusammengetragen wurde. Spätestens, wenn Du eine Messdatenrecherche über einen längeren Zeitraum machen willst, scheiterst Du an dem Select über 50, 100 ... oder 2700 Tabellen. Für mich macht es keinen Sinn, Daten die logisch zusammengehören wieder in kleine Grüppchen aufzuteilen - da kannst Du Deine Daten auch für jede Messung als Binärdatei abspeichern - das ist genauso "komfortabel" und genauso "flexibel" ;-)
Als Zwischenlösung wäre es sicherlich möglich eine separate Tabelle für die aktuellen Daten anzulegen. Das Insert der Neuen und das Auslesen (select...) für die Visualisierung laufen über diese Tabelle. Ein Datenbanktrigger sollte dann dafür sorgen, die jeweils ältesten Daten in die eigentliche Messwertsammeltabelle zu übernehmen und in der Zwischentabelle zu löschen (damit diese nicht zu groß wird) - Damit hast Du eine kleine, aktuelle Messdatensammlung und <b> ein</b> großes Messwertarchiv

[Johann Gysin]

Fragt sich was logisch ist; für mich ist es logischer, die Daten eines Messversuches in diesem Grüppchen zu behalten und nicht mit allen anderen zu vermischen. (Aber ich bin ja nicht der Datenbankexperte). Ich finde es halt einfach ein wenig unhandlich, ein 15GB File auf der Festplatte zu haben. Wie mach ich ein Backup von diesem Ding? Das muss ja Stunden dauern. Und wie schnell kann eine Abfrage, welche aus 500'000 Einträgen besteht, aus diesem 15GB File noch sein? Ich kann doch meinen Entwicklern nicht zumuten, dass sie 5 Minuten auf die Messung vom Archiv warten müssen.<br>
Den einzigen Vorteil, welchen ich sehe wäre, dass man sowas machen könnte: "select * from t_eventpoints where messversuch = 1004 and device = 4 and kanal = 50".<br>
Bei einzelnen Tabellen müsste man den Tabellennamen jeweils noch anpassen, was wohl nicht so elegant ist.<br>
(Weiss jemand, warum das mit einem Parameter nicht geht bei einer Query? Irgendwie packt die Query den Parameter in zwei ' wenn es ein String ist; aber die Datenbank akzeptiert leider keine Apostrophe in Tabellennamen)<br>

Gute Idee mit der Zwischentabelle, somit wäre dann gewährleistet, dass während des Messversuches die Performance des Datenbankservers ausreichen würde.<br>

Gruss<br>
Johan

[Falk Prüfer]

Hallo Johann,

Logik war wohl nicht der richtige Ausdruck für das was ich gemeint habe. Vielleicht liegt es auch daran, das ich es zu sehr aus der Sicht der Auswertbarkeit sehe (damit beschäftige ich mich hauptsächlich) und mich jedesmal aufregen könnte, wenn unsere Leute ihre Daten (weil es so schön übersichtlich ist) in unterschiedliche Dateien ablegen und dann davon eine Auswertung haben wollen. Also ich finde immer noch <b>ein dickes</b> Buch mit einem ordentlichen Inhaltsverzeichnis (sprich Index) besser handhabbar (und beim gezielten Zugriff auf eine Information schneller) als eine riesige Bibliothek mit lauter <b>dünnen Heftchen</b> (Wobei die Bibliothek auf den ersten Blick natürlich besser aussieht) - um mal mit Bildern zu sprechen.
Das Thema Backup ist bei 15GB natürlich immer eine Überlegung wert. Aber ob du die nun aus einer Datei oder 2700 sicherst ist eigentlich egal - 15GB bleiben 15GB - und eine SQL Datenbank speichert das ganze physisch eh nur in einer oder einigen wenigen Dateien - egal ob eine oder 2700 Tabellen (Glaub ich ;-)

So weit ich weiß bietet SQL keine Möglichkeit den Tabellennamen als Parameter zu übergeben. Du bist dort also immer gezwungen den SQL-String interaktiv (z.B. über eine Delphianwendung) zusammenzubauen. Ganz problematisch wird es dann, wenn Du Messreihen miteinander vergleichen willst, die in unterschiedlichen Tabellen liegen.

Gruß Fal

[Johann Gysin]

Guten Tag Falk<br>

Ich begreife langsam, worauf Du hinaus willst. Mir ist ein dickes Buch mit einem guten Inhaltsverzeichnis auch lieber als ein Büchergestell voller Zeitschriften.<br>
Das Datenbankdesign ist wohl sehr entscheidend, wenn man (bzw die Datenbank) sehr viele Einträge verwalten muss.<br>
Vielleicht würde es sich sogar lohnen, professionelle Hilfe zu holen um diese Aufgabe zu lösen. Denn leider wird das ganze nur so gut funktionieren wie die Datebank, welche das "Herz" unserer Messdatenerfassung bildet.<br>

Ich danke Dir vielmals für die Anregungen; dann werde ich mich wohl oder übel mal mit den Grundlagen wie Indexe und Datenbankstukturen auseinandersetzen müssen.....<br>

Viele Grüsse<br>
Johan