Suche nach optimaler Datenbank für große Datenmenge

[SirOPIUM]

Hallo,

ich bin derzeit auf der Suche nach einer optimalen Lösung um eine große Menge Daten zu speichern. Die Situation ist folgende:
Es gilt eine Vielzahl von Werten zu erfassen, für diese einen neuen Datensatz anzulegen und diese (für einen möglichst langen Zeitraum) zu archivieren (wobei sich "möglichst lange" hier auf einen eher kurzen Zeitraum von wenigen Wochen beschränken dürfte), bevor alte Daten (aus Platzgründen) gelöscht werden müssen um neue einzutragen.

Problem Dabei ist, dass es hier um vermutlich mehrere hundert (genaue Zahlen liegen mir leider noch nicht vor) "Variablen" (nahezu ausschließlich Zahlen) geht, die teilweise in sehr kurzen Abständen (deutlich unter einer Sekunde), teilweise aber auch in äußerst langen Abständen (mehrere Stunden), geändert werden. Hier habe ich momentan Bedenken, dass eine klassische relationale Datenbank die vielen "leeren" Felder der zu diesem Zeitpunkt nicht angegebenen Variablen auch mit ablegt und die Datenbank somit auf eine enorme Größe anwächst (was sie vermutlich auch ohne diese leeren Felder schon macht). Ein weiterer Punkt ist die Möglichkeit, die darin enthaltenen Daten ausreichend schnell abzulegen.
Der spätere Zugriff auf die Daten sollte auch in einem vertretbaren Zeitrahmen liegen und den weiteren Betrieb nicht einschränken.
[edit]
War etwas um den heißen Brei geredet. Nachfolgend ein paar weitere Informationen dazu, die hoffentlich etwas mehr Klarheit verschaffen.
[/edit]

Wie sind eure Meinungen?
Ist eine Datenbank die optimale Lösung für das von mir angesprochene Problem?
Welche Art von Datenbank (falls sinnvoll) würde sich dafür generell eignen?
Gibt es Vorschläge, mit welchen bereits vorhandenen Möglichkeiten ich mein Vorhaben am optimalsten realisieren kann?
Ist es sinnvoller ein eigenes Konzept umzusetzen, um mit dieser Datenmenge zu arbeiten?

mfg SirOPIUM

 

[vop]

...Ich hoffe, genug Informationen dazu gegeben zu haben.

Für mich liest es sich so, als würdest du um den heißen Brei reden?
Was genau hast du vor?
Messdatenerfassung in Echtzeit?
Wir können nicht gut beraten, wenn wir nichts genaueres Wissen.
Darf die DB was kosten?
Ist Internet-Zugriff gefragt oder soll sie auf einem Notebook laufen? ......
Es gibt tausend weitere Fragen....
vop

 

[SirOPIUM]

Ja, war ziemlich um den heißen Brei geredet. Dafür möchte ich mich entschuldigen.

Wie du richtig erkannt hast, geht es darum Messwerte aufzuzeichnen, teilweise in Echtzeit. Das ganze soll unter Linux realisiert werden. Die Messdaten selbst werden allerdings auf anderen Systemen erfasst.

Wenn es Varianten gibt, für die keine teure Lizenz erforderlich ist, würde ich das bevorzugen, wenn es allerdings eine wesentlich bessere Lösung gibt, die etwas kostet, bin ich für jeden Hinweis dankbar.

Indirekt wird wohl eine Schnittstelle zum Internet realisiert werden, allerdings ist diese nicht für permanente Zugriffe und nur für "vereinzelte" Nutzer vorgesehen.


Welche Fragen darf ich als nächstes versuchen zu klären?

 

[vop]

Sind es nur "breite" Tabellen, damit meine ich einfache Struktur, viele Spalten in wenigen Tabellen oder
sind viele Relationen zwischen den Tabellen zu erwarten?

Müssen die Daten nur archiviert werden oder finden Bearbeitungen statt?

Wenn ich es richtig sehe, wird hauptsächlich in die DB geschrieben und nur gelegentlich von wenigen Personen gelesen?

Wenn die Erfassung in Echtzeit auf einem anderen System stattfindet, dann kann evtl. für die Eintragung in die DB etwas mehr Zeit aufgewendet werden?

Wenn es nichts kosten darf, sollte MySQL eigentlich die bisher von mir verstandenen Anforderungen erfüllen.
Ich selbst habe in MySQL unter Linux schon GB-große Tabellen mit mehreren Millionen Datensätzen verarbeitet.

Zunächst solltest du aber genauer wissen, was überhaupt in der DB gespeichert werden soll, welche Tabellen womit gefüllt werden sollen und wie komplex die Relationen sind?

Gibt es ein Problem (Geheimnis) damit, etwas konkreter zu werden? :suspekt:

 

[SirOPIUM]

Da es bei der Angelegenheit um ein firmeninternes Projekt geht, möchte ich eigentlich ungern sämtliche Informationen veröffentlichen. Teilweise sind die von mir gegebenen Informationen dann etwas schwammig formuliert. ~

Jup, sind einfach nur wenige "breite Tabellen", mit vielen Datensätzen.
Als gemeinsamer Bezugspunkt soll ein Zeitpunkt mit erfasst werden (wird auf den Echtzeitsystemen Milisekundengenau mitprotokolliert), um die Daten wieder einordnen zu können.
Oft werden nur einzelne Werte erfasst und die meisten anderen Werte werden zu diesem Zeitpunkt nicht aufgezeichnet.

Die Datenbank soll zur (zeitlich begrenzten) Archivierung dienen. Ein weiteres Verändern der enthaltenen Daten ist nicht vorgesehen, wobei ein Datensatz unter Umständen um einen Wert (der bisher "leer" war) erweitert werden soll (keine ganz neue Kenngröße!). Lediglich ein späterer Löschvorgang eines Datensatzes ist unumgänglich, da nur begrenzte Speicherkapazitäten vorhanden sein werden.
Das ganze wird somit ein recht großer Ringspeicher werden, in dem die ältesten Daten wieder gelöscht werden sollen um den neuen Platz zu bieten.

Unter Umständen werden manche der Datensätze somit nie gesichtet, sondern werden erfasst und irgendwann wieder gelöscht. Es erfolgen also nur relativ wenige Zugriffe darauf. Das Arbeiten mit den Daten muss somit auch nicht in minimaler Zeit möglich sein, sollte aber dennoch vernünftig durchführbar sein.

Die Archivierung in der Datenbank sollte nicht zeitkritisch sein. Nach Möglichkeit sollen auch mehrere Daten gemeinsam in wenigen Zugriffen verarbeitet werden, als dass viele einzelne Zugriffe erfolgen.


Da bei den einzelnen Daten der Zeitpunkt, zu dem sie erfasst wurden, eine wichtige Rolle spielt und deshalb auch immer vorhanden ist, war mein Gedanke, die Zeit als eindeutiges Merkmal für einen Datensatz zu verwenden. Da zum selben Zeitpunkt vermutlich nur wenige Daten gleichzeitig erfasst werden (mehrere Werte für eine Kenngröße zum selben Zeitpunkt sind nicht zu erwarten) und viele Kenngrößen in diesem Moment unbekannt sind dürften die einzelnen Datensätze eher kurz ausfallen. Einige der zuvor nicht erfassten Werte könnten aber nur wenig später aktualisiert werden und erfordern somit einen neuen Datensatz, der wieder kaum gefüllt ist.

Es dürften also mehrere Millionen Datensätze für sehr viele unterschiedliche Kenngrößen anfallen. Bei den Daten sollte es sich theoretisch nur um Zahlenwerte (also wenige Byte) handeln, wobei nicht sicher ausgeschlossen werden kann, dass vereinzelt Zeichenketten variabler (aber begrenzter) Länge vorhanden sind.
Die endgültige Menge der Daten und damit die erforderliche Größe sind derzeit schwer einzuschätzen, da die Zahl der aufzuzeichnenden Werte stark variiert.



Eine finanzielle Lösung ist nicht ganz auszuschließen, sofern es nennenswerte Gründe gibt, wenn Kosten gespart werden können, ist dies nur eben auch nicht zu vernachlässigen.

Wie gut sind derart große Tabellen bei MySQL zu handhaben?
Gibt es hierbei eine maximale Größe (oder maximale empfohlene Größe)?
Wäre es denkbar, bei Tabellen dieser Größe neue Kenngrößen hinzuzufügen, oder ist es sinnvoller die Tabelle abzuschließen und eine neue mit der zusätzlichen Kenngröße "anzuhängen"?

edit:
Oder ist das Konzept, die Zeit als Schlüssel zu verwenden aus der Sicht, dass nur ein kleiner Teil des Datensatzes verwendet wird, nicht optimal? Wie sehen Alternativen dazu aus?


SirOPIUM

 

[vop]

Bei einem vernünftigen DB-Design dürfte es mit MySQL eigentlich keine Probleme mit ein paar Millionen Datensätzen geben.
Bei vernünftigem Einsatz von Indexen ist auch der lesende Zugriff sehr schnell.
Da du keine Echtzeitverarbeitung benötigst (so lese ich das heraus) sollte MySQL und eigentlich jedes andere RDBMS problemlos in Frage kommen.
Die sind gerade für große Datenmengen gemacht.

Zur Schlüsselfrage:
Solltest du Millisekunden-genaue Daten haben könnte u. Umständen der Zeitschlüssel Probleme machen, wenn du mehrere Daten für einer Millisekunde erfassen mußt. Wenn du das ausschließen kannst, böte sich der Zeitstempel an.
Das Löschen kann auf einfach über den Zeitstempel erfolgen, indem du einfach alle Datensätze älter als n Zeiteinheiten löscht.
Da du recht wenig Daten pro Eintrag speichern willst (so verstehe ich dich) dürftest du eigentlich nicht so schnell an die Datengrenzen einer DB kommen.

 

[SirOPIUM]

Vielen Dank für die Informationen, Hilfestellungen und guten Ratschläge.

Ich hatte bisher angenommen, dass die relevanten Werte nicht häufiger als einmal je ms geändert werden. Momentan habe ich jedoch bedenken, ob das sichergestellt ist.
Mein Gedanke war, alle Aufzeichnungen, die zum selben "Zeitpunkt" stattfanden in einem Datensatz abzulegen und die Zeit eben als Schlüssel zu verwenden. Sollten jedoch mehrere auftreten, kann ich das Konzept nicht direkt in dieser Form weiterverfolgen. Ich bin nicht sicher, aber das Ablegen mehrerer Werte für ein Element in einem Datensatz ist nicht möglich, oder irre ich mich?

Leider hat sich ein bisher nicht eindeutiger Punkt (entgegen meiner Erwartungen) geändert: Es hat sich leider auch herausgestellt, dass sich die Anzahl der zu erfassenden Elemente ändern können muss. Somit müssten theoretisch während das ganze aktiv ist neue Elemente (also neue "Tabellen-Spalten") hinzugefügt werden, andere dagegen ab einem bestimmten Zeitpunkt als ungültig markiert werden.
Ist dies ebenfalls mit den angesprochenen Möglichkeiten ohne Nachteile realisierbar, oder stellt das für viele der RDBMS Schwierigkeiten dar?

 

[vop]

Zum Schlüssel
Soll eine Datensatz eindeutig identifiziert werden können, können natürlich nicht mehrere mit dem selben Schlüsselwert existieren. Dein Zeitstempel scheidet also als Schlüssel aus.

Du brauchst einen anderen eindeutigen Schlüssel, der z.B. auch eine Kombination aus Zeitstempel und zusätzlichem Wert sein kann. Eben ein eindeutiges Kriterium.
Oder du läßt von der DB einen automatischen Schlüsselwert erzeugen. Dieser steht dann aber nicht in Bezug auf den Zeitstempel.

Zu den nicht klaren Daten
Du kannst natürlich in einer Tabelle auch weitere Spalten verwenden, die nur bei manchen Datensätzen verwendet werden und häufig leer sind.

Du kannst aber auch durch geeignete Verknüpfungen zusätzliche Infos in anderen Tabellen unterbringen und referenzieren.
Dafür brauchst du wie gesagt ein gut durchdachtes DB-Design.

Da du allerdings nicht mit konkreten Beispielen kommst, kann dir dabei wohl niemand helfen.

Inwieweit hast du dich denn bereits mit Relationalen Datenbanken beschäftigt?

vop

 

[SirOPIUM]

Hat leider etwas gedauert, bis ich wieder Zeit hierfür hatte ...

Ich hatte bisher leider wenige Gelegenheiten, mich mit relationalen Datenbanksystemen zu beschäftigen, daher sind meine Formulierungen zu dem Thema unter Umständen nicht immer optimal und die Fragen wirken teilweise trivial.
Ich hoffe, mir kann trotzdem noch geholfen werden

Wie gesagt: All zu genaue Informationen kann ich nicht geben, aber ich versuche es dennoch mit einem kleinen Beispiel:
Es sind mehrere Bereiche, in denen jeweils mehrere (unterschiedlich viele) Größen erfasst werden. Manche Bereiche sind seltener, andere häufiger aktiv. Ist ein Bereich aktiv, werden darin auch Werte der Messgrößen erfasst. In einem Bereich geschiet dies oft zum selben Zeitpunkt oder in kurzen Zeitabständen für viele oder gar alle darin erfassten Messgrößen. Da die einzelnen Bereiche nicht in konstanten und vorallem nicht in den selben Zeitabständen wie die anderen Bereiche Daten erfassen, scheint eine Unterteilung in mehrere Tabellen sinnvoll.

Ist zwar nicht sehr genau, aber ob das jetzt in einem Flugzeug, einem Auto oder einem komplexen Küchenmixer ist, sollte keine Rolle spielen.

... Zu den nicht klaren Daten
Du kannst natürlich in einer Tabelle auch weitere Spalten verwenden, die nur bei manchen Datensätzen verwendet werden und häufig leer sind. ...

Ich bin gerade nicht sicher, welche Daten du mit "nicht klare Daten" beschreibst...
Manche Messgrößen "entstehen" erst irgendwann, verschwinden aber kurz darauf bereits wieder (für immer). Diese Daten müssten eben auch erfasst werden. Sie in leeren Spalten, die eigentlich für andere Werte gedacht sind, abzulegen (so hab ich diese Aussage interpretiert), erscheint mir nicht sinnvoll, da nicht sichergestellt ist, dass nicht zufällig alle Werte zu diesem Zeitpunkt erfasst wurden und somit keine freien Spalten vorhanden sind.

Da die Zeit auch im späteren Verlauf als gemeinsames Element zur Verknüpfung der Daten dienen soll, ist dies ja im Prinzip der sinnvollste Schlüssel.
Da ich in ein Feld offenbar nicht mehrere Werte für die selbe Größe eintragen kann, obwohl die Werte alle zum selben "Zeitpunkt" (bzw im selben, kurzen Zeitbereich) erfasst wurden, wäre es denkbar, die Daten als zusätzliche Werte in der Reihenfolge ihrer Entstehung abzulegen?
Der Schlüssel liefert für dieses Element dann zwar keinen eindeutigen Wert mehr, sondern eine feste Folge von Werten, aber mit entsprechenden Operationen im Anschluss sollte dies ohne weiteres verarbeitet werden können, denke ich.

Wenn ich das so zusammenfasse, bräuchte ich eine Datenbank, die:
- eine große Menge an Daten verwalten kann (kann auch in mehreren Tabellen sein)
- es erlaubt in kurzer Zeit viele Daten einzutragen (ist natürlich auch abhängig von der Hardware)
- "leere Zellen" mit möglichst niedrigem Speicherbedarf ablegt
- dynamisch annähernd beliebig erweitert werden kann, um zusätzliche Werte (sind in ihrer Struktur genauso wie alle anderen Werte) abzulegen

Ich hab das Gefühl, als hätte ich was vergessen

Wird das von den Vorschlägen immernoch abgedeckt, oder ist es ratsam etwas selbstgestricktes zu verwenden?

 

[ronaldh]

Entschuldigung, aber da fehlt mir einiges.

Nach allem, was Du bisher geschrieben hast, willst Du Daten irgendwo ablegen, und irgendwann wieder löschen, damit es nicht zu viel Daten werden. Da geht am schnellsten mit einer simplen Textdatei, da hierbei keinerlei Overhead eines Datenbanksystems benötigt wird. Da würde dann z.B. pro Tag, oder auch pro Stunde, eine neue Datei erstellt werden, die man sich dann bei Bedarf mal ansehen könnte. Oder aber mit jeder x-beliebigen Datenbank, denn das können sie wohl alle.

Jedoch wird dies sicherlich nichts bringen, weil man Daten in der Regel ja nicht nur dazu speichert, um sie bald wieder zu löschen. Du musst schon mal sagen, wie, wo, wann und in welcher Form die Daten wieder abgerufen werden sollen.

Dann kann man sich Gedanken darüber machen, welche Datenbank optimal wäre, und wie das Datenbank-Design sinnvoll wäre.

Interessant wäre auch, mit welcher Programmiersprache Du das erledigen willst, denn auch da gibt es Unterschiede in Bezug auf die optimale Datenbankanbindung.

Darüber hinaus würde ich bei einem Projekt, welches anscheinend eine wichtige geschäftliche Basis hat, zunächst mal davon ausgehen, dass die Datenbank wohl auch etwas kosten wird. Wenn es so geheim ist, wie Du hier erzählst, könnten dann auch Punkte wie Datensicherheit, Backup-Fähigkeit während des Betriebs, Verschlüsselungsmechanismen usw. eine Rolle spielen.

Wenn es vorrangig um hohe Geschwindigkeit geht und die Programmiersprache keine Rolle spielt, kann ich z.B. Pervasive empfehlen. Pervasive ermöglicht den Zugriff über SQL, wie auch MSSQL oder MySQL. Darüber hinaus bietet Pervasive jedoch den so genannten transaktionalen Zugriff, das heißt, man kann über API-Funktionen oder ActiveX-Komponenten direkt auf die Tabellen zugreifen. Dies ist gegenüber jeder mir bekannten Datenbank extrem schnell, da hier auf die Daten direkt und ohne Umweg über eine immer interpretativ ablaufende SQL-Engine zugegriffen wird. Allerdings erfordert dies natürlich Lern- und Einarbeitungsaufwand. Und zu Deinen Kenntnissen in der Programmierung hast Du bisher leider auch noch nicht viel geäußert.