Welche Server-DB bei großer Datenmenge

[DataCool]

Hallo zusammen,

ich mache mir gerade Gedanken über das passende DBMS für ein Projekt.

Ausgangssituation:

- Client/Outlets:
Es gibt N Clients/Outlets örtlich getrennt in ganz Deutschland verteilt. (momentan ist N = 80-90)
Im einem "Outlet" gibt es zu 90% nur einen PC(= lokale DB) die anderen 10% sind mit 2 oder 3 PCs vertreten.
In einem "Outlet" hat die eigentliche DB eine Größe von ca. 20-50 MB(soweit alles easy),
hinzukommen aber täglich zwischen 2 und 10 MB Bewegungsdaten, aus einer externen Datenquelle.
Diese Bewegungsdaten wird zu 95% nur für spätere Auswertungen/Statistiken benötigt.
Bei jedem "Outlet" wird mit hoher Wahrscheinlichkeit eine Firebird 2.5.x zum Einsatz kommen

- Server:
Hier sollten die Daten von allen "Outlets" in einer Datenbank zusammen laufen.
Wenn wir zum einfachen rechnen mal 100 "Outlets" annehmen wären wir das bei der reinen Programm-DB,
bei einer Größe von ca. 5GB (100 * 50 MB). Diese Datenmenge sollte jede der gängigen Datenbanken
ohne Probleme abbilden können.
Bei den Bewegungsdaten sieht es aber schon wieder ganz anders:
365 Tage * 10 MB * ca. 100 Outlets = ca. 365 GB
Wunsch ist es die Daten für mind. 2 Jahre rückwirkend zu halten;
wo wir dann schon 730 GB wären.
Diese riesen Datenflut verteilt sich momentan auf nur 3 Tabellen,
Größenverhältnis ist hierbei 60%, 25% u. 15%

Das ganze Szenario wirft für mich folgende Fragen auf:
- Welche DB kann das auf einem Server überhaupt sauber verwalten ?
- Welche DB-Techniken würdet Ihr verwenden/empfehlen um Auswertungen
auf diesen Datenmengen zeitnah durchführen zu können ?
- Table Partitioning ?
- ?? was noch ??

Datenbanken die ich bis jetzt im Auge halte:
- Firebird, arbeite ich gerne & gut mit, allerdings verfügt Firebird nicht über "Table Partitioning" und fällt somit leider wohl durchs Raster. Oder hat jemand der Firebird Experten hier im Board eine Idee wie Firebird die oben genannten Datenmenge stemmen kann ?
- MySQL, habe ich auch einiges mit gemacht; Allerdings gefällt mir das unklare Lizenzmodell nicht wirklich.
- MsSQL, ist mir auch nicht unbekannt; Allerdings die letzten 4 Jahre in keinem Projekt verwendet. Somit bin ich was Version & Geschwindigkeit & Stabilität nicht ganz auf dem Laufenden
- PostgreSQL: Ehrlich gesagt noch in keinem realen Projekt verwendet nur ein wenig damit rum gespielt.
Aber von dem was man so hört auf jeden Falle eine mögliche Alternative.


So, jetzt seid Ihr dran;
Freue & bedanke mich für jedes Feedback,

Greetz Data

[Bernhard Geyer]

Zitat von DataCool:

- Welche DB kann das auf einem Server überhaupt sauber verwalten ?

Eigentlich jede die aktuell weiterentwickelt wird. Der MS-SQL-Server kann z.B. 524,272 terabytes pro DB verwalten.

Zitat von DataCool:

- Welche DB-Techniken würdet Ihr verwenden/empfehlen um Auswertungen

Definiere Technik? Also bei großen DB-Mengen wird es nötig sein die Indizes und Abfragen so zu gestalten das du nicht versehentlich versuchst 2 GB zum Client zu übertragen.

Zitat von DataCool:

- auf diesen Datenmengen zeitnah durchführen zu können ?
- Table Partitioning ?
- ?? was noch ??

Es gibt verschiedene Ansätze. Eine ist z.B. eine Vorkomprimierung der Daten (z.B. zum Monatsabschluss über das Wochenende laufen lassen).

Zitat von DataCool:

- MySQL, habe ich auch einiges mit gemacht; Allerdings gefällt mir das unklare Lizenzmodell nicht wirklich.

Mir auch nicht. Aber wenn die Lösung eine Nur Inhouse (als nur im eigenen Unternehmen) so dürfte es nix kosten.

Zitat von DataCool:

- MsSQL, ist mir auch nicht unbekannt; Allerdings die letzten 4 Jahre in keinem Projekt verwendet. Somit bin ich was Version & Geschwindigkeit & Stabilität nicht ganz auf dem Laufenden

Also wenn man keine eigene fehler in der Logik gemacht hat spielt der MS SQL-Server in der ersten Liga mit.

[mjustin]

Bei zirka 1 Terabyte ist es schon eine sehr große Datenbank. Joins können sehr langsam werden (wieviel Terabyte RAM hat der Server, und wie schnell und groß ist sein Festplatten-Speichersystem?).

Von den genannten Datenbanken würde ich mir vor allem PostgreSQL genauer ansehen. Je nach Anforderungsprofil kommt aber auch eine NoSQL Datenbank in Frage. Viele NoSQL-Implementierungen unterstützen verteilte Datenbanken mit redundanter Datenhaltung auf vielen Servern, beispielsweise unter Nutzung einer verteilten Hashtable. Damit können die Systeme einfach skalieren und Ausfälle einzelner Server überstehen.

Firebird ist für die kleinen Installationen IMHO eine gute Lösung. Es kann unter Linux installiert werden und ist wartungsarm.

[Daniela.S]

Zitat:

- Welche DB-Techniken würdet Ihr verwenden/empfehlen um Auswertungen
auf diesen Datenmengen zeitnah durchführen zu können ?
- Table Partitioning ?

Vielleicht wäre es auch eine Idee darüber nachzudenken die Daten der Großen Tabelle mit 60% aufzuteilen? Wenn Berechnungen nicht alle Felder benötigten, könnte man die Tabellen aufteilen und somit die Geschwindigkeit der Berechnungen etwas erhöhen.

Anhand der Größe würde ich auch eher zu MSSQL greifen. Bei der Größe bedarf es natürlich einer Lizenz, da die Express Version nur (korrigiert mich) max. 2GB und eine CPU unterstützt. Eventuell wäre auch Oracle interessant...

[Furtbichler]

Imho ist das ein klassisches DWH (Datawarehouse): Tägliche Bewegungsdaten => ETL. Sehr wenig Tabellen => Star-Design.

Die Frage, die sich hier stellt ist: Müssen alle Daten als quasi Rohdaten vorliegen? Kann man sinnvoll verdichten? Wenn ja, wird das alles schon viel einfacher. Wenn nein, auch egal.

Über PostGres habe ich nur Gutes gehört, ein (Ex-)Kollege hat das mal eingesetzt und mit der Zunge geschnalzt (täglich).

Google mal nach "PostGres DWH" und "Postgres ETL", da findest Du reichlich Stoff.

[sh17]

MongoDB wäre ein gutes NoSQL-Exemplar.

[franktron]

Um Die MySQL Problematik mal zu entspannen hier ein Fork von MYSQL läuft ohne Probleme mit UNIDac
http://de.wikipedia.org/wiki/MariaDB
und ist GPL

[p80286]

Zitat von Bernhard Geyer:

Eigentlich jede die aktuell weiterentwickelt wird.
....
Also wenn man keine eigene fehler in der Logik gemacht hat spielt der MS SQL-Server in der ersten Liga mit.

Dem ist eigentlich nichts hinzuzufügen.
Du brauchst
a) ein vernünftiges Design
Eine Datenbank ist nun mal keine Blackbox in die sinnlos Daten hinein schaufelt und auf mysteriöse Weise werden diese dann geordnet und platz und zeitsparend wieder zur Verfügung gestellt.

b) einen Admin, der weiß was er tut.

Was hast Du von einer Oracle DB wenn der Admin damit nicht umgehen kann.

Selbst ein CD-Verzeichnis ist mit 3 Tabellen wahrscheinlich nicht optimal designed. Da steht Dir wohl noch etwas Arbeit bevor.

Gruß
K-H

[Patito]

Also für mich klingt die Datenmenge jetzt nicht so groß, dass man da schon
zwingend Tabellen partitionieren muß. Es könnte schon reichen wenn man
einfach nur die größte Tabelle in einen anderen Tablespace legt - das
sollten selbst die weniger guten Datenbanken beherrschen.

Firebird: Ist in Delphi-Kreisen recht beliebt, aber bei Google-Trends zeigt
der Trend konstant abwärts - würde ich nicht nehmen.

MySQL: Ist gut wenn man eine schnelle Installation braucht, aber ich finde
für eine Firmendatenbank sollte man was besseres nehmen.

MSSQL: Ist ganz gut.

Postgres: Würde ich zuerst probieren. Falls es nicht geht wäre MSSQL für mich eine Alternative.
Zum Table-Partitionieren hab mal in die Doku von Postgres geschaut - so wie das dort funktioniert
würde ich die Finger davon lassen. Wenn man Table-Partitioning wirklich braucht, ist es vermutlich
Zeit sich mal die Preislisten von Oracle zukommen zu lassen.

Techniken:
a) gutes Datenbank-Design
b) vernünftige Indizes

[mjustin]

Bekannte Beispiele für spaltenorientierte (statt dokumentenorientierte) NoSQL Datenbanken sind laut Wikipedia diese Erweiterungen von Hadoop, einer in Java geschriebenen Datenbank:

HBase

HBase ist eine skalierbare, einfache Datenbank zur Verwaltung sehr großer Datenmengen innerhalb eines Hadoop-Clusters. Die HBase-Datenbank basiert auf einer freien Implementierung von Google BigTable. Diese Datenstruktur ist für Daten geeignet, die selten verändert, dafür aber sehr häufig ergänzt werden. Mit HBase lassen sich Milliarden von Zeilen verteilt und effizient verwalten. (Hervorhebung durch mich)

Hive
Hive erweitert Hadoop um Data-Warehouse-Funktionalitäten, namentlich die Anfragesprache HQL und Indizes. (Die von Facebook verwendete Hadoop-Datenbank gehört mit etwas mehr als 100 Petabyte (Stand: August 2012) zu den größten der Welt.)


Ein nicht auf Hadoop basiertes NoSQL System der Apache Foundation ist

Apache Cassandra
Cassandra ist ein einfaches, verteiltes Datenbankverwaltungssystem für sehr große strukturierte Datenbanken. Cassandra wird bei Twitter, Digg und Reddit genutzt. Auch bei Facebook bediente es bis Mitte 2011 hunderte Millionen von Mitgliedern. (Es ist ebenfalls in Java geschrieben.)


p.s. sind in der Kalkulationen nur die Rohdaten enthalten oder sind Indexdateien schon berücksichtigt?