Welche Server-DB bei großer Datenmenge

[mcinternet]

Wir setzen hier bei Datenmengen > 20T Oracle auf ner AS400 ein. Ca. 5000 Clients greifen laufend darauf zu und es werden viele größere Imports und Exports gefahren. Eine Oracle kann sowas schneller liefern als jede andere SQL.
@Data: Wir können gern mal telefonieren.

Das einzig noch performantere ist TeraData ...

Gruss

McInternet

[tsteinmaurer]

Ich würde hier in der Zentrale ganz klar eine Trennung zwischen OLTP und OLAP machen, weil du da ev. auch unterschiedliche Anforderungen in Bezug auf Verfügbarkeit, Indexierung, Ressourcen, Änderungshäufigkeit etc. haben könntest. D.h. aus meiner Sicht kommst du dann auch für die OLTP Datenbank serverseitig mit einem "Mid-Range DBMS" aus und hättest dann zum Beispiel die Möglichkeit die Client-DBs und die OLTP Server-DB mit einer Technologie (z.B. Firebird) zu handhaben, was kein Nachteil wäre, wenn man hier nur ein DBMS im Einsatz hat.

Bzgl. OLAP kann man sich dann genauere Gedanken machen, welche Anforderungen man für das Reporting bzw. der Analyse tatsächlich erfüllen muss. Technologisch gesehen kann das dann zum Beispiel mit ROLAP erfolgen (OLAP Server auf eine relationale Datenbank) oder halt MOLAP als Microsoft Analysis Services. Hier hat bereits die Standard Edition einiges zu bieten. Tabellenpartitionierung ist eine feine Sache, um eine Tabelle mit sehr vielen Datensätzen in kleinere Häppchen physisch zu unterteilen. Aber dieses Feature lassen sich die Hersteller auch bezahlen, da dies in der Regel erst in den höchsten Editionen und im Falle von Oracle nochmals als zusätzliche, kostenpflichtige Option auf die bereits teure Enterprise Edition verfügbar ist. Aber die Oracle-Partitionierung ist eine feine Sache. Hab sie selber im Einsatz. Man muss sich halt die Frage stellen, ob man Partitionierung wirklich benötigt, oder ob man Datensätze in eine "Archiv" Datenbank auslagern kann, die eigentlich kaum mehr geändert/angegriffen wird.

NoSQL ist in aller Munde, aber eine ganz andere Denkweise ist hier notwendig (fängt schon mal an, dass weg ist vom guten alten relationalen Modell) und besitzt auch ganz andere Anforderungen an den Betrieb, um die Skalierbarkeit bei großen Datenmengen ausnutzen zu können. Sprichwort: Cluster. War selbst in Projekten mit HBase (darunterliegendem Hadoop) und auch Cassandra involviert und für die Anforderungen dort, war eine RDBMS Lösung nicht denkbar. Wir hatten es hier aber auch nicht mit einer OLTP Umgebung zu tun, wo wir ACID benötigten.

[DataCool]

Erstmal Danke für die rege Beteiligung

Oracle, kenne ich auch; Kommt für mich in diesem Fall aber nicht in Frage!
Das ganze Projekt soll nach Fertigstellung auch ohne Extra-Admin auskommen

Eine Trennung der verschiedenen Datenbanken(Programm-DB z.B. Firebird; Bewegungsdaten mit XYZ)
ist eventuell möglich. Diesbezüglich muss ich nochmal in Ruhe nachdenken,
ob in dieser Konstellation trotzdem alle Informationen ohne "großes verbiegen" abfragbar sind.

Weiterhin ist noch zu erwähnen das die Tabellen der Bewegungsdaten nur wachsen
und der Begriff Archiv es ziemlich genau trifft.
Auf die Tabellen laufen immer nur "INSERT" Statements und diese Daten
werden dann nachher nach Bedarf "selektiert".

Greetz Data

[Nersgatt]

Zitat von DataCool:

Das ganze Projekt soll nach Fertigstellung auch ohne Extra-Admin auskommen

Kling für mich wie "wir wollen ein 100-stöckiges Hochhaus bauen - das soll aber nach Fertigstellung ohne Hausmeister auskommen"...

[DataCool]

Zitat von Nersgatt:

Zitat von DataCool:

Das ganze Projekt soll nach Fertigstellung auch ohne Extra-Admin auskommen

Kling für mich wie "wir wollen ein 100-stöckiges Hochhaus bauen - das soll aber nach Fertigstellung ohne Hausmeister auskommen"...

Natürlich soll und wird es eine Betreuung geben!
Aber keinen Extra ODBA der nur diese DB/Server betreut.

Greetz Data

[Patito]

Zitat von DataCool:

Erstmal Danke für die rege Beteiligung
Weiterhin ist noch zu erwähnen das die Tabellen der Bewegungsdaten nur wachsen
und der Begriff Archiv es ziemlich genau trifft.
Auf die Tabellen laufen immer nur "INSERT" Statements und diese Daten
werden dann nachher nach Bedarf "selektiert".

Greetz Data

Wenn in die Log-Tabelle nur Inserts kommen, kann man z.B. auch leicht
eine Tages-Statistik-Tabelle per Trigger befüllen. Dann hat man schon mal
wesentlich weniger Daten, die man analysieren muß.

Schau Dir auch genau an wie effizient Du deine Daten speicherst. (Normalisieren...)
Die Kantine in meiner Datenbank verursacht gerade mal 1 MB an Daten im Jahr.
Wenn man im Jahr 100 GB voll kriegen will muß man schon viel Hunger haben.

Manchmal müssen auch nicht alle Log-Informationen in die Datenbank - die können ruhig in
irgendwelche Log-Files bleiben - nur die interessanten Daten braucht man in der Datenbank.

[DataCool]

Zitat von Patito:

Wenn in die Log-Tabelle nur Inserts kommen, kann man z.B. auch leicht
eine Tages-Statistik-Tabelle per Trigger befüllen. Dann hat man schon mal
wesentlich weniger Daten, die man analysieren muß.

Schau Dir auch genau an wie effizient Du deine Daten speicherst. (Normalisieren...)
Die Kantine in meiner Datenbank verursacht gerade mal 1 MB an Daten im Jahr.
Wenn man im Jahr 100 GB voll kriegen will muß man schon viel Hunger haben.

Manchmal müssen auch nicht alle Log-Informationen in die Datenbank - die können ruhig in
irgendwelche Log-Files bleiben - nur die interessanten Daten braucht man in der Datenbank.

Erstmal reden wir hier nicht von einer Kantine, sondern ca. 100 Läden.
Der springende Punkt ist aber das die Daten aus dem Kassensystem um ein vielfaches komplexer sind,
als die bei einer Kantine.
Du bekommst zu jedem Bon mitgeliefert, welcher Kellner den Bon geöffnet, welcher Kellner den Bon
geschlossen hat, an welchem Tisch gestartet/bezahlt wurde(umsetzen),
war vielleicht gerade Happy Hour und Cocktails wurden mit einen Extra-Rabatt verkauft.
Hat ein Mitarbeiter sich selbst was mit Personalrabatt verkauft.
War der Verkauf mit 7% Mwst oder 19% (variiert pro Artikel innerhalb eines Bons)

Auf Basis dieser Daten sind nachher unzählige Auswertungen denkbar und gewünscht,
die Daten schon verdichtet aufzubereiten wird da an manchen Stellen schwierig.

Greetz Data

[tsteinmaurer]

Wie lange muss dieser Detailierungsgrad der Daten für Auswertungen zur Verfügung stehen?

[DataCool]

Zitat von tsteinmaurer:

Wie lange muss dieser Detailierungsgrad der Daten für Auswertungen zur Verfügung stehen?

- Minimum 2 Jahre zurück(Kunden Vorgabe)
- Gut wären 3 Jahre (schon mehr als gewünscht)
- 4 Jahre hervorragend( mehr als 4 Jahre auf keinen Fall)

[Morphie]

Kannst du mal so eine Beispieltabellenstruktur posten?
Meine Erfahrung: Die Größe der Datenbank ist relativ egal, das Design macht den Unterschied.

Notfalls schreibst du dir halt ein Programm mit dem du so große Datenbestände simulieren kannst... Ich vermute aber mal, dass kein aktuelles RDBMS aufgrund der Größe schlappmachen wird.