Was mache ich wenn meine Tabelle voll ist?

[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 von 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.

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 von 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.

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.