Problemstellung: Eine Messung erzeugt kontinuierlich große Datenmengen, dabei fallen jeweils Tupel von Messdaten an, z.B. Zeit, X-Wert, Y-Wert, etc. Diese Daten sollen in einer relationalen Datenbank mit SQL-Schnittstelle gespeichert werden. Gesucht wird ein Beispiel für das Schema des Datenbankmodells bzw. Informationen darüber, wie derart strukturierte Daten in einer relationalen DB effizient verwaltet werden können.
Hallo,
Das Datenbankmodell ist meines Erachtens nicht abhängig davon, woher die Daten kommen. Für das Strukturieren der Daten sollte dann die andere Seite (zB Client) zuständig sein; diese hat dann die Daten so zu liefern, dass sie der Struktur entsprechen. Das hat den Vorteil, dass das DBMS nicht damit beschäftigt ist, die Daten „einzusortieren“, was wichtig für die Perfomance ist, sobald Messdaten aus mehreren Quellen kommen. Außerdem können auf dieser Seite schon „Filter“ mit eingebaut werden.
Vielleicht war es auch das, was Du mit „Verwalten“ meinst, sonst ist mir Deine Fragestellung nicht ganz klar.
Wie das Modell im Einzellnen dann aussieht, hängt eben von den Daten ab…Man kann detaillierte Dinge beachten wie zB, dass man die Zeit nicht mitliefern muss, sofern es sich um Realtime-Aufnahmen handelt, die wird in vernünftigen DBMS automatisch bei Anlegen des Datensatzes ergänzt…usw.
Ein Beispiel für eine solches System ist der Einsatz von LabView und MySQL. LabView holt die Messdaten und schickt die, meinetwegen über ODBC, auch manipuliert, bereits strukturiert in die DB, wenn es entsprechend programmiert wurde…
Bin mir aber nicht sicher, ob ich nicht das Thema verfehlt hab.
Gruss, Daniel
Hallo Tobias,
Ich bin ja sonst keiner, der rumnölt, aber jetzt muss ich mir den Frust doch mal von der Seele schreiben. Dass es jetzt gerade dich trifft, dafür kannst du zwar überhaupt nichts, aber ich krieg sonst noch ein Magengeschwür.
In diesem Brett - wie in (fast) allen anderen auch - gibt es ein paar Leute, die ihre private Zeit opfern, um anderen zu helfen. Das Ganze passiert unentgeltlich, und nicht wenige von den regelmässig antwortenden vierdient eigentlich genau in dem Bereich sein Geld, in dem er anderen hilft, sprich die Experten schädigen eigentlich zusätzlich ihr eigenes Geschäft. Was sie aber dafür schon erwarten sind eigentlich nur zwei Dinge:
- Der Fragende hat eigenständig versucht sein Problem zu lösen oder sich zumindest darüber Gedanken gemacht (merke: Dieser Punkt hier trifft dich, Tobias).
- Ein kurzes Dankeschön, wenn die Antwort geholfen hat.
Vor allem letzteres ist in letzter Zeit ziemlich aus der Mode gekommen. Ich erwarte mir ja keinen Kniefall oder ähnliches, aber da es in letzter Zeit nachweislich auch schon vorgekommen ist, dass Antworten von mir, die mir einige Zeit gekostet haben noch nicht mal mehr vom Fragenden gelesen(!) werden kommt dann schon die Frage auf, wofür man sich die Mühe überhaupt noch macht.
So, das musste einmal raus.
@MOD: Kannst die Antwort ruhig kommentarlos löschen Robert, fühle mich jetzt schon besser 
Und jetzt noch zu deiner Frage Tobias: Wo genau liegt dein Problem mit der Aufgabenstellung bzw. wie sieht dein Lösungsansatz bisher aus?
Würde dir nämlich schon gerne helfen, aber dein Posting beinhaltet ja noch nicht mal eine richtige Frage…
Gruß,
Martin
[Bei dieser Antwort wurde das Vollzitat nachträglich automatisiert entfernt]
Also, ich versuch mal, mich genauer auszudrücken.
Mein Problem ist, dass sehr viele Tupel von Messdaten in einer Messreihe anfallen und ich diese aus Gründen der Datensicherheit sofort in die Datenbank schreiben muß. Allerdings möchte ich ungern auf Dauer jeden Tupel in einem eigenen Datensatz speichern, da dies die Tabelle mit den Meßreihen aufbläht und bei der Suche nach einzelnen Meßreihen in der DB die Performance wohl in die Knie geht.
Mein einziger Ansatzpunkt wäre bisher für jede Datenquelle eine Tabelle anzulegen, in der die Tupel als einzelne Datensätze gespeichert werden und diese am Ende einer Messung diese Datensätze alle zu einem Datensatz zusammenzufassen.
Für weitere Anregungen wäre ich wirklich dankbar.
[Bei dieser Antwort wurde das Vollzitat nachträglich automatisiert entfernt]
wenn ich von was magengeschwüre krieg, dann von leuten, die mich grundlos anmeckern. was zur hölle bringt dich auf die idee, ich hätte mir selbst noch keine gedanken gemacht? und bedanken kann ich mich erst dann, wenn ich eine antwort gekriegt habe, dann gerne sogar wenn mir die antwort nicht geholfen hat, aber jemand sich bemüht hat mir zu helfen. aber ich gehe mal davon aus, dass du für deine antwort nicht ernsthaft dank erwartest.
und wenn man die frage nicht versteht, weil ich mich unklar ausdrücke oder aus sonstigen gründen, dann kann man auch freundlich nachfragen oder sich einfach aus dem thema raushalten.
Hallo Tobias,
Ich bin ja sonst keiner, der rumnölt, aber jetzt muss ich mir
den Frust doch mal von der Seele schreiben. Dass es jetzt
gerade dich trifft, dafür kannst du zwar überhaupt nichts,
aber ich krieg sonst noch ein Magengeschwür.
In diesem Brett - wie in (fast) allen anderen auch - gibt es
ein paar Leute, die ihre private Zeit opfern, um anderen zu
helfen. Das Ganze passiert unentgeltlich, und nicht wenige von
den regelmässig antwortenden vierdient eigentlich genau in dem
Bereich sein Geld, in dem er anderen hilft, sprich die
Experten schädigen eigentlich zusätzlich ihr eigenes Geschäft.
Was sie aber dafür schon erwarten sind eigentlich nur zwei
Dinge:
- Der Fragende hat eigenständig versucht sein Problem zu
lösen oder sich zumindest darüber Gedanken gemacht (merke:
Dieser Punkt hier trifft dich, Tobias).- Ein kurzes Dankeschön, wenn die Antwort geholfen hat.
Vor allem letzteres ist in letzter Zeit ziemlich aus der Mode
gekommen. Ich erwarte mir ja keinen Kniefall oder ähnliches,
aber da es in letzter Zeit nachweislich auch schon vorgekommen
ist, dass Antworten von mir, die mir einige Zeit gekostet
haben noch nicht mal mehr vom Fragenden gelesen(!) werden
kommt dann schon die Frage auf, wofür man sich die Mühe
überhaupt noch macht.So, das musste einmal raus.
@MOD: Kannst die Antwort ruhig kommentarlos löschen Robert,
fühle mich jetzt schon besserUnd jetzt noch zu deiner Frage Tobias: Wo genau liegt dein
Problem mit der Aufgabenstellung bzw. wie sieht dein
Lösungsansatz bisher aus?Würde dir nämlich schon gerne helfen, aber dein Posting
beinhaltet ja noch nicht mal eine richtige Frage…Gruß,
Martin
hi tobias! (dies ist eine begrüßung)
lies dir nochmals ganz genau durch, was martin schrieb - vor allem den anfang
und anscheinend dürfte es doch etwas geholfen haben, da du in deinem neuerlichen posting genauer auf das problem eingehst und sogar schon lösungsansätze hast - wenn nicht sogar schon die lösung (die einzelnen sätze in eine art „zwischentabelle“ ablegen, die nach der messung mittels pl/sql, snapshot o.ä. zusammengefaßt werden - könnte aber auch mit einem auswertetool realisiert werden)
grüße, tomh (dies ist ebenfalls eine grußformel)
ps: kurz zusammengefaßt dein erstes posting: ich habe daten und möchte sie in einer datenbank ablegen; könnt ihr mir weiterhelfen?
also deine zusammenfassung meines postings ist ja wohl reichlich übertrieben (vielleicht solltest du mein erstes posting nochmals lesen). allerdings habe ich auch nicht behauptet, dass ich mein problem bereits im ersten posting absolut verständlich und erschöpfend beschreiben habe. ausserdem habe ich nichts dagegen, dass man mich auffordert mein problem genauer zu beschreiben,
ich hab nur was dagegen grundlos angemeckert zu werden (vielleicht solltest du auch mein zweites posting nochmal lesen).
[Bei dieser Antwort wurde das Vollzitat nachträglich automatisiert entfernt]
Also, ich versuch mal, mich genauer auszudrücken.
Mein Problem ist, dass sehr viele Tupel von Messdaten in einer
Messreihe anfallen und ich diese aus Gründen der
Datensicherheit sofort in die Datenbank schreiben muß.
Allerdings möchte ich ungern auf Dauer jeden Tupel in einem
eigenen Datensatz speichern, da dies die Tabelle mit den
Meßreihen aufbläht und bei der Suche nach einzelnen Meßreihen
in der DB die Performance wohl in die Knie geht.
Mein einziger Ansatzpunkt wäre bisher für jede Datenquelle
eine Tabelle anzulegen, in der die Tupel als einzelne
Datensätze gespeichert werden und diese am Ende einer Messung
diese Datensätze alle zu einem Datensatz zusammenzufassen.
Für weitere Anregungen wäre ich wirklich dankbar.
Hallo Tobias!
Sorry erstmal wegen meines vorigen, wahrscheinlich doch etwas ruppigen Posts.
Jetzt, wo du auch schreibst, wo das Problem liegt wird es erheblich einfacher dir zu helfen…
Die Frage, ob die DB bei der zu erwartenden Anzahl von Daten in die Knie geht ist wesentlich abhängig von der verwendeten Hard- und Software, weiters natürlich von der Strukturiernug der Daten und erst am Ende (und eigentlich auch nur peripher) von der tatsächlichen Datenmenge. Um ein Beispiel für WIRKLICH viele Informationen in einer DB, die performant durchsucht werden können zu sehen: http://www.google.com
Zurück zu deinem Problem:
Verstehe ich dich richtig, dass du eigentlich nur sehr flache Daten speichern willst (eben z.B. Timestamp, x, y)? Diese Daten lassen sich meiner Meinung nach nicht verlustfrei „komprimieren“, sprich wann immer du aus mehreren Messdatensatz einen einzelnen generierst verlierst du Detailinformationen (z.B. indem du nur noch Intervall, durchschnittl. x, durchschnittl. y speicherst). Die Frage, wie du die Daten also sinnvoll zusammenkürzen kannst, ergibt sich einzig und allein aus der Analyse des zu lösenden Problems. Vielleicht kannst du uns ja dazu noch etwas mehr Hinweise geben.
Ansonsten kann ich nur noch sagen, dass z.B. Oracle mit Datensatzzahlen von mehreren Millionen noch kein ernsthaftes Problem hat, wenn du dir vorher überlegt hast, welche Zugriffe auf die Daten erfolgen werden und welche Indices du daher benötigst.
Ich weiss ja, dass das nicht sonderlich ergiebig ist, aber ohne weitere Hinweise…
Gruß,
Martin
hi!
also deine zusammenfassung meines postings ist ja wohl
reichlich übertrieben
so übertrieben nun auch wieder nicht; der informationsgehalt strebte gg. null - erst das zweite posting gab aufschluß, worin die probleme liegen (könnten) - ich hätte dir anfangs access empfohlen, jedoch nach dem 2. posting doch eher in richtung oracle, wenn nicht gar teradata …
ich hab nur was dagegen grundlos angemeckert zu werden
deswegen auch der hinweis auf den anfang des postings, in dem du als _zufälliges_ opfer ausgewählt wurdes
grüße,
tomh
ps: es ist keine schande, freundlich zu sein und hie und da ein paar grußformeln einzuwerfen
hi, die sache mit dem verwendeten datenbanksystem ist leider wieder eine ganz andere sache, das werden wohl leute aufgrund finanzieller überlegungen entscheiden und nicht hauptsächlich anhand technischer notwendigkeiten. mir gehts vorläufig deshalb darum wie ich die daten sinnvoll in einer db speichern kann und zwar ausschließlich unter verwendung von standard sql. gruss tobias
[Bei dieser Antwort wurde das Vollzitat nachträglich automatisiert entfernt]
hi.
also das problem ist nicht, dass ich befürchte die db könnte aufgrund der reinen datenmenge in die knie gehen, sondern dass ich nur mal beispielhaft sagen wir 10000 einzelmessungen pro messreihe habe, die ich sofort nach der einzelmessung in die db schreiben muß. Wenn ich jetzt sagen wir 1000 messreihen habe, dann habe ich schon weiß gott viele datensätze in der tabelle drin. wenn ich dann nur eine einzige messreihe aus der db abrufen will muß ich alle Datensätze durchsuchen zu welcher messreihe sie gehören anstatt nur einen datensatz für eine ganze messreihe zu suchen, was natürlich optimal wäre, falls es hierfür eine vernünftige lösung gibt. und ich bin mir jetzt nicht sicher, ob das lesen der messreihen aus der db bei sovielen datensätzen in einer akzeptablen zeitspanne möglich ist, das schreiben der einzelnen datensätze ist sicher zeitmässig kein problem. also falls jemand hierzu eine vernünftige idee hat wäre ich wirklich dankbar. übrigens sind die zahlenbeispiele oben eher untertrieben, d.h. es werden wohl eher deutlich mehr daten anfallen.
du hast übrigens recht es sind nur flache daten, teilweise nur (TIMESTAMP, X) und ich will sie auch nicht komprimieren, ich suche nur nach einer sinnvollen art wie ich die daten problemlos in die datenbank rein kriege (wobei das einfachste wäre jede messung als einzelnen datensatz zu schreiben) und auch wieder raus (wobei es ziemlich ungeschickt wäre wenn jede messung in einem einzelnen datensatz gespeichert wäre).
ok, ich hoffe man versteht mich jetzt. ich weiss übrigens, dass ich eine talent habe mich ziemlich unklar auszudrücken und gerne mal etwas zu knapp formuliere.
gruss tobias
p.s. kein problem wegen deinem ruppigen posting, ich bin nicht empfindlich und auch nicht nachtragend. ich wollte mich nur gegen meiner meinung nach unberechtigte kritik wehren.
hi.
also das problem ist nicht, dass ich befürchte die db könnte
aufgrund der reinen datenmenge in die knie gehen, sondern dass
ich nur mal beispielhaft sagen wir 10000 einzelmessungen pro
messreihe habe, die ich sofort nach der einzelmessung in die
db schreiben muß. Wenn ich jetzt sagen wir 1000 messreihen
habe, dann habe ich schon weiß gott viele datensätze in der
tabelle drin.
10 Mio. sind’s in dem Fall
wenn ich dann nur eine einzige messreihe aus der
db abrufen will muß ich alle Datensätze durchsuchen zu welcher
messreihe sie gehören anstatt nur einen datensatz für eine
ganze messreihe zu suchen, was natürlich optimal wäre, falls
es hierfür eine vernünftige lösung gibt.
Die gibt es natürlich. Falls du Informationen speichern willst, die eine ganze Messreihe betreffen, dann solltest du das in einer eigenen Tabelle ablegen, die dann in etwa so aussehen könnte: TABLE Messreihe(ID,Datum,Info1,Info2…) Obwohl nicht im Sinne der Normalisierung, aber für grosse Datenmengen, insbesondere wenn die sich nach der erstmaligen Erfassung nicht mehr ändern, durchaus geeignet (bitte mich dafür nicht zu prügeln, ihr Jünger der Normalisierung bis zur 5. NF) wären hier eventuell auch noch Infos über die Child-Datensätze (die Messwerte nämlich) wie Anzahl, Minimum, Maximum - je nachdem was du dort eben gebrauchen kannst. Dann gibt es eben noch die Messwerte, die in etwa so aussehen könnten: TABLE Messwert(ReihenID,FortlaufendeID,Timestamp,x,y,…). Die ReihenID in Messwert referenziert natürlich die ID in Messreihe und bildet zusammen mit der FortlaufendeID den primary key. Wenn du da dann noch einen hübschen Index drüberlegst, dann klappt’s auch mit der Performance.
und ich bin mir jetzt
nicht sicher, ob das lesen der messreihen aus der db bei
sovielen datensätzen in einer akzeptablen zeitspanne möglich
ist, das schreiben der einzelnen datensätze ist sicher
zeitmässig kein problem.
Mit Index (s.o.) und einigermassen dafür geeigneter Hardware und Software (nein, nicht MS Access!) sollte auch das Lesen kein Problem sein. Sooo gross sind die Daten die du abspeichern willst nämlich gar nicht: Wenn wir nur die Messwerte betrachten, dann hat ein Datensatz Daumen*Pi 100 Byte (mitsamt dem ganzen Overhead und so), die 10000 Messwerte für 1000 Messreihen lassen sich damit noch bequem auf 1 GB unterbringen, da zuckt Oracle/DB2/MS-SQL noch nicht mal mit der Wimper… Um die oben angesprochenen DBMS’s in Schwierigkeiten zu bringen brauchts da dann doch schon um Grössenordnungen mehr (kannste ruhig noch mal mit 100 multiplizieren).
ich suche nur nach einer sinnvollen art wie ich die daten
problemlos in die datenbank rein kriege (wobei das einfachste
wäre jede messung als einzelnen datensatz zu schreiben) und
auch wieder raus (wobei es ziemlich ungeschickt wäre wenn jede
messung in einem einzelnen datensatz gespeichert wäre).
Was stört dich daran? Mit einer geegneten WHERE Klausel bekommst du genau die, die du brauchst. Ist auch nicht schwieriger zu handlen als ein Datensatz mit 10000 Spalten (jeder Messwert eben in einer Spalte nicht in einer Zeile). Damit bringst du übrigens mit Sicherheit so gut wie jedes RDBMS in Schwierigkeiten…
p.s. kein problem wegen deinem ruppigen posting, ich bin nicht
empfindlich und auch nicht nachtragend. ich wollte mich nur
gegen meiner meinung nach unberechtigte kritik wehren.
Ich hatte ja auch geschrieben, dass du die ganze Ladung abbekommen hast, obwohl du ja die meisten der von mir angesprochenen „Verfehlungen“ noch nicht mal begangen hast. Ich bin auch nicht der Oberschiedsrichter hier, mir ist schlicht und einfach der Kragen geplatzt. Jedenfalls beruhigt es mich, dass du mir das nicht übel nimmst. Darauf können wir das dann mal beruhen lassen, denke ich…
Gruß,
Martin
Hallo Tomh!
Lass das mal gut sein, Tobias und ich haben uns schon wieder lieb… *g*
Gruß,
Martin
P.S.: Hatte bis vor einer Minute gar nicht bemerkt, dass wir beide in Wien sitzen 
Könnten wir ja mal bei einem Bierchen besprechen, unsere Leiden als w-w-w Helferchen *g*
[Bei dieser Antwort wurde das Vollzitat nachträglich automatisiert entfernt]
hi martin!
P.S.: Hatte bis vor einer Minute gar nicht bemerkt, dass wir
beide in Wien sitzen
besprechen, unsere Leiden als w-w-w Helferchen *g*
sofern es der gesundheitszustand meines zwerges (fieber und husten und schnupfen und so) und meiner angetrauten (schwangerschaft im 5. monat mit dementsprechenden begleiterscheinungen zulassen: gerne - wir mailen uns zusammen
grüße,
tomh
danke
hallo.
ich glaub euch jetzt einfach mal, daß ein vernünfiges db system meine daten in akzeptabler geschwindigkeit wieder aus der db raus kriegt. werde das wohl mal ausprobieren und außerdem noch meine idee mit der zwischentabelle (wobei ich dann eben nach der messung die ganzen daten noch mal verarbeiten muß und irgendwie die ganze messreihe in eine spalte kriegen).
danke übrigens für eure bemühungen.
gruss tobias