Was mache ich wenn meine Tabelle voll ist?

[vagtler]

Zitat von Dejan Vu:

[...] Zur Grenze, eine Beispielanwendung: In einer Fabrik wird pro Sekunde ein Bauteil mit 500 Messwerten durchgemessen, die Fabrik läuft 24/7. Das sind am Tag 43 Mio Zeilen, wenn ich mich nicht verrechnet habe. Da ist die Tabelle im Nonstopbetrieb nach 49 Tagen voll. Das ist keine Phantasie, sondern im Solarzellenbereich Realität. Da lob ich mir doch eine DB, der es wurscht ist, wie viele Zeile in die Tabelle passen.

Wobei ich mir bei solchen Anwendungsfällen nicht die Frage stellen würde, ob man hier nicht in besser eine entsprechend leistungsfähige Key-Value-Store-Datenbank einsetzt.

[Bernhard Geyer]

Zitat von vagtler:

Zitat von Dejan Vu:

[...] Zur Grenze, eine Beispielanwendung: In einer Fabrik wird pro Sekunde ein Bauteil mit 500 Messwerten durchgemessen, die Fabrik läuft 24/7. Das sind am Tag 43 Mio Zeilen, wenn ich mich nicht verrechnet habe. Da ist die Tabelle im Nonstopbetrieb nach 49 Tagen voll. Das ist keine Phantasie, sondern im Solarzellenbereich Realität. Da lob ich mir doch eine DB, der es wurscht ist, wie viele Zeile in die Tabelle passen.

Wobei ich mir bei solchen Anwendungsfällen nicht die Frage stellen würde, ob man hier nicht in besser eine entsprechend leistungsfähige Key-Value-Store-Datenbank einsetzt.

Genau. Oder ist es wirklich nötig das man in 2 Jahren noch weis was vor 2 Jahren diese 500 Messwerte genau waren? Hier ist eher zu überlegen diese Daten mit der Zeit (automatisiert) Einzdampfen um hier nur die Statitischen Daten der Messwerte über die Zeit zu haben.

[Dejan Vu]

Gewährleistung, Rückverfolgbarkeit, Fehlersuche. Die Herstellungsverfahren sind neu und insofern muss das ein paar Jahre gesichert werden. Ob nun alle 500 oder nur die Eckwerte sei mal dahingestellt.

[Bernhard Geyer]

Zitat von Dejan Vu:

Gewährleistung, Rückverfolgbarkeit, Fehlersuche. Die Herstellungsverfahren sind neu und insofern muss das ein paar Jahre gesichert werden. Ob nun alle 500 oder nur die Eckwerte sei mal dahingestellt.

Dann würde ich alle Messwerte einer Geräts in eine Datei/einem (Blob-)Feld speichern.
Da du jetzt nicht weiß was damit gemacht wird ist es m. E. noch nicht sinnvoll diese normalisiert einzeln in eine DB zu speichern.

[Dejan Vu]

Für die Archivierung könnte man das durchaus machen. Aber es ist auch so, das TB-Platten weitaus billiger sind, als die Manpower, um eine Archivierung und ein entsprechendes Retrieval zu implementieren.

Ehrlich gesagt weiß ich nicht, was die mit den alten Daten machen, aber beim Aufbau der Fabrik und in den ersten 2-3 Jahren hat man sich Daten der letzten 6-10 Monate durchaus angeschaut und das waren dann eben so viele. Was die heute damit machen? Vermutlich liegen die frustriert in einer Partition rum und werden nie selektiert. Nie! Die armen Daten. Komplett vergessen. Opfer der Sammelwut.

[p80286]

Zitat von Bernhard Geyer:

Zitat von Dejan Vu:

Gewährleistung, Rückverfolgbarkeit, Fehlersuche. Die Herstellungsverfahren sind neu und insofern muss das ein paar Jahre gesichert werden. Ob nun alle 500 oder nur die Eckwerte sei mal dahingestellt.

Dann würde ich alle Messwerte einer Geräts in eine Datei/einem (Blob-)Feld speichern.
Da du jetzt nicht weiß was damit gemacht wird ist es m. E. noch nicht sinnvoll diese normalisiert einzeln in eine DB zu speichern.

Anfrage meines Chefs: "vor drei jahren sollten an Akte X folgende Änderungen gemacht worden sein, kann man das nachvollziehen?"
Das konnte ich verneinen, da die gefragte Änderung nicht protokolliert wird. Andere hingegen schon.

Im Zweifel werden solche Daten gebraucht, bis das die Verjährungsfrist bzw. Aufbewahrungsfrist abgelaufen ist. Und manchmal nicht "irgendwo" sondern "at your fingertip".

Gruß
K-H

[mkinzler]

Das ist keine Frage, die man so einfach auf die Schnelle beantworten kann.

Sind es einzelne unabhängige Werte oder Sätze ( z.B. verschiedene Messwerte zu einem Zeitpunkt/Werkstück)?/Muss auf die einzelnen Werte zugegriffen werden oder auf einen "Satz"?
In einen Blob könnte man problemlos jeweils einen Satz ablegen, könnte dann aber nicht mehr so einfach (per SQL) auf die einzelnen Werte zugreifen. Einfache Statistiken per SQL Aggegate würden also nicht mehr funktionieren.

[Bernhard Geyer]

Zitat von mkinzler:

In einen Blob könnte man problemlos jeweils einen Satz ablegen, könnte dann aber nicht mehr so einfach (per SQL) auf die einzelnen Werte zugreifen. Einfache Statistiken per SQL Aggegate würden also nicht mehr funktionieren.

Die Frage ist wie schnell eine "übliche" SQL-Datenbank auf Aggregatfunktionen reagiert wenn hier jetz Mrd-Datensätze drin liegen.
Solche Auswertungen macht man ja üblich in einer "OLAP-Optimierten" Struktur.

[stahli]

Ich denke auch, man könnte für diesen Zweck eine NoSQL-DB in Erwägung ziehen.
Kann man einfach alles mehr oder weniger unstrukturiert reinwerfen und bei Bedarf wieder danach suchen.