Welche Server-DB bei großer Datenmenge

[DataCool]

Zitat:

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?).

Die Server-Konfiguration kann mehr oder weniger frei bestimmt werden.

Zitat:

Von den genannten Datenbanken würde ich mir vor allem PostgreSQL genauer ansehen.

Höre von vielen Seiten nur gutes, nur möchte man in einem nicht kleinem Projekt auf eine
DB setzen, mit der man persönlich noch keine "richtigen" Erfahrungen gemacht hat ?!

Zitat:

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.

Glaube nicht das das in Frage kommt, denn es geht mir nicht darum die Daten verteilt zu halten
sondern zentral zusammen, damit die Auswertungen "Outlet-Übergreifend" durchgeführt werden können.
Das "Table Partitioning" habe ich jetzt einfach mal in den Raum geschmissen, weil ich mir bei den Bewegungsdaten
sehr gut eine Aufteilung nach Jahren vorstellen könnte. Sinn einer Aufteilung wäre aber nur eine schnellere Antwortzeit
bei der Datenauswertung.

Zitat:

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

Die Liste der Features und Maximal-Größen hatte ich mir auch schon im Vergleich angesehen.
http://en.wikipedia.org/wiki/Compari...gement_systems

^^ Demnach könnte Firebird (DB-Size unlimited; Max. Table-Size 32 TB) die Datenmengen auch "locker" bewältigen,
in meinen Augen besteht aber doch ein riesen Unterschied zwischen Maximal und performant.


@All:
Um es noch mal etwas genauer darzustellen. Bei den Bewegungsdaten handelt es sich um elektronische Bon-Rollen
von Kassen-Systemen. Für die die diese nicht kennen, da stehen dann Daten drin wie:
- Bon geöffnet
- Kellner xyz boniert Artikel xyz
- Artikel xyz wird storniert(Falscheingabe)
- Gäste haben sich umgesetzt von Tisch A nach Tisch B
- .....
- Bon wird geschlossen
- Bezahlung in X Arten

Bei der momentanen DB-Struktur gibt es somit eine Table für Verkaufstransaktionen(25% Datenmenge), Details zu einer Transaktion(65%) verknüpft über ID und noch Mwst Details(15%) zu einer Transaktion ebenfalls über eine ID verknüpft.

Primäre Auswertungen werden sein:
- Wie oft wurde Artikel ABCD im letzten Jahr zwischen 18:00 und 19:00 Uhr verkauft
^^ einmal für Standort A oder Standorte B, C und D oder generell

- Stornos / Summe / Anzahl

- Besondere Rabatte

uvw.

Hoffe das Ziel ist jetzt noch etwas klarer geworden.

Greetz Data