Was mache ich wenn meine Tabelle voll ist?

[Der schöne Günther]

Deppenfrage mit Deppentitel.

Meine hauptsächlich verwendete Datenbank erlaubt zwar Dateigrößen im Exabyte-Bereich, will aber nicht mehr als 2^31 (2 Milliarden) Datensätze pro Tabelle zulassen.

Da ich, wie oft betont, null Praxiserfahrung mit Datenbanken habe bin ich davon jetzt überrascht worden! Ja, so eine Menge kann durchaus anfallen. Und ja, eventuell werde ich mehr brauchen.

Ärgere ich mich jetzt über die blöde Datenbank oder hat man das Problem öfter? Was tue ich dagegen? Lege ich nach 1,9Mrd. Einträgen die nächste Tabelle mit einem _2 hinten im Namen an? Presse ich (entgegen Normalisierung) mehr (eventuell leer bleibende) Spalten an einen Datensatz?

Ich bin verwirrt. :|

[Dejan Vu]

Welche Datenbank bzw. welches RDBMS wäre das?
Und -ja- du müsstest dann einfach eine weitere Tabelle anlegen bzw. die volle Tabelle umbenennen oder 1x pro Jahr ne neue Tabelle nehmen bzw. umbenennen.

Oder die ältesten Daten per Trigger oder per COB (Close of Businessday) ins Archiv verschieben. Die Archiv-DB ist natürlich eine, der ein paar mehr Zeilen pro Tabelle ablegen kann.

[Uwe Raabe]

Oder eine Datenbank verwenden, die diese Begrenzung nicht hat. Allerdings konnte ich auch für ADS keinen Hinweis auf diesen Constraint finden. Kann es eventuell auch ein von dir verwalteter Integer sein, der da überläuft?

[Der schöne Günther]

An die Begrenzung bin ich noch nicht gestoßen, aber die Proprietary File Format Specifications sprechen von

Zitat:

Maximum number of records per table - 2 Billion

Der Typ AUTOINC ist komischerweise 4 Byte Unsigned (4Mrd) was aber auch nicht viel besser ist (Field Types and Specifications)

[Uwe Raabe]

Im amerikanischen Sprachgebrauch entspricht Billion der deutschen Milliarde.

[Der schöne Günther]

Natürlich. Hat doch niemand etwas anderes behauptet?

[Bernhard Geyer]

2 Mrd. ist schon viel.Für viele Anwendungen ist diese Grenze irrrelevant

[Uwe Raabe]

Zitat:

Zitat von Bernhard Geyer (Beitrag 1283144)

2 Mrd. ist schon viel.Für viele Anwendungen ist diese Grenze irrrelevant

Genau diese Grenze wird aber im ersten Post bemängelt:

Zitat:

will aber nicht mehr als 2^31 (2 Milliarden) Datensätze pro Tabelle zulassen.

[Perlsau]

Zitat:

Zitat von Der schöne Günther (Beitrag 1283122)

... will aber nicht mehr als 2^31 (2 Milliarden) Datensätze pro Tabelle zulassen.

Je nach Anforderung sollte man das passende DBMS wählen. Man nimmt kein DBMS mit derartigen Begrenzungen, wenn zu erwarten ist, daß die zu entwickelnde Anwendung weitaus mehr Datensätze zu verwalten hat, als das DBMS zuläßt. Ich kann hier nur mal wieder Firebird empfehlen, damit hättest du diese Probleme nicht.

[Dejan Vu]

Ich glaube, die Anzahl der RDBMS, die diese Beschränkung nicht haben, ist größer als die, die diese Beschränkung haben.

Ich persönlich würde eh nur SQL-Server, PostGres oder FB nehmen. mySQL kenne ich nicht, aber 100 Mio Fliegen können nicht irren. Die Teile sind weit verbreitet, stabil, werden weiterentwickelt usw usw.

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.

[franktron]

MySQL und auch die anderen DBMS sind durch das OS begrenzt.
Das heißt Dateisystem und Arbeitsspeicher begrenzen die Grösse der Tabellen.

[taveuni]

Wie lange werden denn die Daten gebraucht?

[Bernhard Geyer]

Zitat:

Zitat von franktron (Beitrag 1283177)

MySQL und auch die anderen DBMS sind durch das OS begrenzt.
Das heißt Dateisystem und Arbeitsspeicher begrenzen die Grösse der Tabellen.

Wie soll der Arbeitsspeicher die Größe der Tabelle beeinflussen?
Wenige Arbeitsspeicher bedeutet nur langsameres DB-System da das Caching von Daten (wie Indexe) im Arbeitsspeicher nicht oder nur eingeschränkt möglich ist.

Diverse DBMS können ihre DB-Dateien nur so groß machen wie eine Datei im entsprechenden Dateisystem möglich ist.
Gute DBs ist das egal. Sie teilen das dann einfach (u.U. ist hier Hilfe des Admins nötig) auf mehrer Dateien auf.

[Der schöne Günther]

Zitat:

Zitat von Dejan Vu (Beitrag 1283167)

Zur Grenze, eine Beispielanwendung: In einer Fabrik wird pro Sekunde

Genau so etwas ist es bei mir auch. Wenn jetzt jeder hier gesagt hätte "WAS!?! 2^31 haben bislang für jede Anwendung auf der Welt gereicht, und du willst die einzige Ausnahme sein!?!" hätte ich mich schluchzend unter den Tisch verkrochen aber jetzt bin ich wieder etwas beruhigter.

Zitat:

Zitat von taveuni (Beitrag 1283179)

Wie lange werden denn die Daten gebraucht?

Das wissen wir selber noch nicht so genau. Teilweise wird von Zeiträumen von zehn Jahren gesprochen, aber ein Ersetzen aller Messwerte durch eine Zusammenfassung nach ein bis zwei Jahren ist auch denkbar.
So oder so würde es momentan bei 2^31 maximalen Werten schon zu knapp werden.

[Medium]

Zumindest bei MySQL weiss ich, dass es Table-Partitioning gibt, wodurch Tabellen auf mehrere interne Tabellen aufgeteilt werden. Die Grenzen sind dabei frei definierbar. Das erhöht, wenn man Grenzen und Indizes auf die Abfragen hin günstig wählt, auch gewaltig die Geschwindigkeit. Andere DBMS bieten so etwas bestimmt auch.

[Dejan Vu]

Die Sammelwut von Messdaten wird nur durch die fehlende Intelligenz der sie fordernden Ingenieure übertroffen. Dezent OT: "Wir wollen ALLES messen, keine Ahnung, wieso, aber man kann nie wissen". Noch besser: "Bitte messen Sie das Gewicht des Motorblocks auf 8 Stellen hinter dem Komma. In Gramm. Wieso? Keine Ahnung wieso, aber man kann nie wissen." :wall:

So, zurück zum Thema: Heutzutage sind 2 Milliarden Datensätze keine große Sache mehr. Wer damit umgehen kann, ist in der freien Wirtschaft und dem Arbeitsmarkt ziemlich weit vorne.

[Lemmy]

Zitat:

Zitat von Der schöne Günther (Beitrag 1283182)

Das wissen wir selber noch nicht so genau. Teilweise wird von Zeiträumen von zehn Jahren gesprochen, aber ein Ersetzen aller Messwerte durch eine Zusammenfassung nach ein bis zwei Jahren ist auch denkbar.
So oder so würde es momentan bei 2^31 maximalen Werten schon zu knapp werden.

dann lass ADS ganz schnell liegen und beschäftige dich mit "richtigen" DBMS, angefangen von den hier genannten bis hin zu MS SQl und Oracle. Fang keinen Blödsinn an wie "Dann lege eine Tabelle_x an" wenn einen voll ist.. vergiss das ganz schnell wieder...

[Dejan Vu]

Zitat:

Zitat von Lemmy (Beitrag 1283186)

Fang keinen Blödsinn an wie "Dann lege eine Tabelle_x an" wenn einen voll ist.. vergiss das ganz schnell wieder...

Bitte mach ein Schild und vermarkte es. Ich bin der erste, der es kauft und vielen der DB-Spezialisten die ich kenne für die Rübe nagelt! Danke.

[himitsu]

Zitat:

Zitat von Dejan Vu (Beitrag 1283167)

mySQL kenne ich nicht, aber 100 Mio Fliegen können nicht irren. Die Teile sind weit verbreitet, ...

MySQL ist vorallem durch die unzähligen Apachen (besonders im kostenlosen Bereich) sehr weit verbreitet ... die haben es praktisch wie Windows auf'm PC gemacht.

Aber im sonstigen Softwarebreich kann es mit MySQL schnell teuer werden und dann die komischen Lizenzbedingungen, von denen man immer wieder hört.

[vagtler]

Zitat:

Zitat von Dejan Vu (Beitrag 1283167)

[...] 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:

Zitat von vagtler (Beitrag 1283193)

Zitat:

Zitat von Dejan Vu (Beitrag 1283167)

[...] 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:

Zitat von Dejan Vu (Beitrag 1283197)

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. :cry:

[joachimd]

Zitat:

Zitat von Der schöne Günther;1283182Wenn jetzt jeder hier gesagt hätte [I

"WAS!?! 2^31 haben bislang für jede Anwendung auf der Welt gereicht, und du willst die einzige Ausnahme sein!?![/I]" hätte ich mich schluchzend unter den Tisch verkrochen aber jetzt bin ich wieder etwas beruhigter.

Ich habe in meinen 15 Jahren als ADS Betreuer noch keinen getroffen, der auch nur annähernd an diese Grenze kam. das heißt jetzt nicht, dass es das nicht gibt - aber unter unseren Kunden eben bisher nicht. Und wir haben viele - die Dunkelziffer der ganzen Local Server Anwender mal ausgeschlossen.

[p80286]

Zitat:

Zitat von Dejan Vu (Beitrag 1283188)

Zitat:

Zitat von Lemmy (Beitrag 1283186)

Fang keinen Blödsinn an wie "Dann lege eine Tabelle_x an" wenn einen voll ist.. vergiss das ganz schnell wieder...

Bitte mach ein Schild und vermarkte es. Ich bin der erste, der es kauft und vielen der DB-Spezialisten die ich kenne für die Rübe nagelt! Danke.

Ich weiß ja nicht wen Du kennst, aber DB-Spezialisten sind das nicht!

Gruß
K-H

[Der schöne Günther]

Zitat:

Zitat von joachimd (Beitrag 1283215)

Ich habe in meinen 15 Jahren als ADS Betreuer noch keinen getroffen, der auch nur annähernd an diese Grenze kam. das heißt jetzt nicht, dass es das nicht gibt - aber unter unseren Kunden eben bisher nicht.

Glaube ich. Aber wenn ich für das Projekt einen anderen Server nehme werde ich diese Grenze ja natürlich auch nicht erreichen ;-)

Zitat:

Zitat von Dejan Vu (Beitrag 1283214)

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.

Ganz genau. Mich würden die Daten auch nicht interessieren aber es gibt Leute, die wollen sie haben.

[p80286]

Zitat:

Zitat von Bernhard Geyer (Beitrag 1283204)

Zitat:

Zitat von Dejan Vu (Beitrag 1283197)

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:

Zitat von mkinzler (Beitrag 1283227)

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.

[mkinzler]

Wenn sowieso ein Data Warehouse eingesetzt wird, besteht das Problem eh nicht, da man in diesem Fall durch die "Archivierung" im DW den "Aktivzeitraum" kleinhalten kann.
Mein Beitrag war auch nicht als "Kontra"-Beitrag gegen Blobs gemeint. Sondern sollte nur darauf hinweisen, dass man genauere Untersuchungen/Überlegungen treffen sollte und es "die" Lösung per se nicht gibt.

[mkinzler]

Zitat:

Zitat von stahli (Beitrag 1283229)

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.

Da die Daten doch sehr strukturiert sind, bringt m.E NO SQL keine Vorteile.

[stahli]

Ich hatte es so verstanden, dass es um Logs über einen längeren Entwicklungs/Produktionszeitraum geht.
Da könnten sich die zu speichernden Information auch durchaus noch ändern.

[himitsu]

Wenn man viele Daten hat und auch die Möglichkeit bieten will die auszuwerten (nicht all zu langsam), dann könnte man auch überlegen gleich ein DataCenter einzusetzen, welches auf große Datenmengen spezialisiert ist und wo man auch noch Funktionen für die Auswertung (inkl. Caching) bekommt.

Und dann wurde schonmal angesprochen, daß einige DBMS verschiedene Tabellentypen unterstützen, wo es auch welche für große Datenmengen gibt.
MySQL hat z.B. eine Tabelle, die ist für viele Daten ausgelegt (weniger Overhead, kein Index, keine Referenzen usw.), aber dafür halt schlecht/garnicht änderbar ist. (bestehende Datensätze ändern oder löschen).
Sowas wird gern für Logdateien verwendet, was man hier also quasi vor hat.

[Sir Rufo]

Auch wenn ich jetzt gleich Haue kriege, aber mit einer Zwischenschicht (hatten wir ja erst kürzlich) ist es schon wieder wurstegal, ob es diese Beschränkung auf der DB gibt.

Man bringt der Zwischenschicht bei, damit umzugehen entweder durch den Tausch der Datenbank oder entsprechendes Handling mit mehreren Tabellen.

[jobo]

DIE Zwischenschicht muss dann aber ALLES abfackeln, was rund um die Befüllung noch so ansteht. Weiß nicht, ob sowas effizient umsetzbar ist.
Wie verträgt sich das mit meinen Olap tools usw..?
Abgesehen davon, dass Dich ggF. die Admins erschlagen, die dann die Backups nach zusätzlichen kriterien verwalten müssen.
Ein RDBMS was da keine Beschränkungen hat und über Partitioning verfügt, ist sicher der bessere Ansatz.
Aufbewahrungszeiten von 10 Jahren sind eigentlich Industriestandard, beispielsweise bei sicherheitsrelevanten Komponenten (Airbag, Bremse, ..)

[Sir Rufo]

Hmmm, beim Pizzabringdienst interessiert es mich nicht, mit welchem Auto die vorbeikommen, allerdings glaube ich zu 100% zu wissen, dass bei einer anstehenden Reparatur oder Wartung an den Fahrzeugen weder ich noch die Pizza-Bestell-Hotline bemüht wird. Gleiches gilt für den Pizza-Ofen.

Also die Zwischenschicht legt die Daten in irgendeinem Datengrab ab. Für mich abstrakt für die Zwischenschicht konkret. Und dieses konkrete Datengrab wird gesichert. Die Zwischenschicht ist beim Sichern zu 0,00% involviert.

Und weil die Zwischenschicht nichts speichert muss da auch nichts gesichert werden (keine Daten in dem Sinne).

Maximal bekommt die Zwischenschicht die Info, dass jetzt nur ein lesender Zugriff möglich ist oder die Zwischenschicht signalisiert "bitte jetzt nicht sichern".

[jobo]

Zitat:

Zitat von Sir Rufo (Beitrag 1283301)

Hmmm, beim Pizzabringdienst interessiert es mich nicht, mit welchem Auto die vorbeikommen, allerdings glaube ich zu 100% zu wissen, dass bei einer anstehenden Reparatur oder Wartung an den Fahrzeugen weder ich noch die Pizza-Bestell-Hotline bemüht wird. Gleiches gilt für den Pizza-Ofen.

Schönes Beispiel.
Im Prinzip finde ich es ja ok, wenn die Zwischenschicht transparent ist. Aber wie transparent ist es denn? SQL Zugriff usw alles unproblematisch?

Mir fehlt die Kenntnis/Phantasie, wie es mit mehr als 2Mrd bestellten Pizzen aussieht. Und das sind ja noch zuwenig. Die vom Lieferdienst müssen dann irgendwie einen LKW nehmen, ok, ihr Problem. Ich brauch ggF. etwas Platz zum Einlagern, bevor ich sie gegessen habe.
Also an dem Bestellvorgang hat sich nichts geändert, die Umsetzung dürfte sich aber erheblich unterscheiden.
Und in dem Thread hier geht es ja um die Umsetzung und nicht um die Nutzung des coolen Produkts, das es mal werden soll.

Es kommt finde ich etwas auf die Anwendung an. Wenn es Tagesgeschäft ist, 2mrd ++ Datensätze durch die Gegend zu wuppen, muss das schon gut gemacht sein.
Ich sehe das einfach so, nichts ist so performant wie die direkte Nutzung eines DB Servers.
Das Kernproblem bspw. von dwh / olap Software ist immer der initiale Datentransfer und dann die Fortschreibung oder immer wieder neu usw.(bei großen Mengen natürlich).

[Dejan Vu]

Für mich ist z.B. ein OLAP-Cube auch eine Zwischenschicht, denn -ehrlich gesagt- habe ich keine Ahnung, woher die Daten kommen. Ich frage ab und bekomme meine Antworten in unglaublicher Zeit.

Ich habe mit Palo gespielt, und es als genau das angesehen, was Sir Rufo beschreibt, nämlich ein Tool, um Daten zu abstrahieren und aufbereitet anzuzeigen. Eine Zwischenschicht muss ja nicht notwendigerweise eine real existierende Blackbox sein. Eine Zwischenschicht ist -für mich zumindest- eine Abstraktion der dahinterliegenden Daten. Das kann eine Familie von Views und stored procedures sein, virtuelle Tabellen, ein App-Server (RDBMS <--> JSON/XML) oder ein Cube.