Welche Server-DB bei großer Datenmenge

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

[DataCool]

Das alte System sieht in etwa so aus:

Code:

DROP TABLE IF EXISTS `transaktion`;
CREATE TABLE  `transaktion` (
  `SORT_ID` int(11) NOT NULL,
  `IMPORT_ID` int(11) NOT NULL,
  `ID` int(11) NOT NULL,
  `JOURNAL_NR` int(11) DEFAULT NULL,
  `START_DT` timestamp DEFAULT NULL,
  `ENDE_DT` timestamp DEFAULT NULL,
  `KASSEN_NR` int(11) DEFAULT NULL,
  `TISCH_NR` int(11) DEFAULT NULL,
  `BEDIENER_START` int(11) DEFAULT NULL,
  `BEDIENER_ENDE` int(11) DEFAULT NULL,
  `BON_NR` int(11) DEFAULT NULL,
  `BON_TYP` int(11) DEFAULT NULL,
  `TOTAL` double DEFAULT NULL,
  `TOTAL_TYP` varchar(10) DEFAULT NULL,
  `TOTAL_NETTO` double DEFAULT NULL,
  `FINANZWEG` int(11) DEFAULT NULL,
  `ZAHLGELD` double DEFAULT NULL,
  `AUSLAGEN` double DEFAULT NULL,
  `INFOREC_TYPE` int(11) DEFAULT NULL,
  `INFOREC_VALUE` int(11) DEFAULT NULL,
  `EXPORT_DT` timestamp DEFAULT NULL,
  `GUTSCHEINNUMMER` varchar(50) DEFAULT NULL,
  PRIMARY KEY (`SORT_ID`,`IMPORT_ID`,`ID`),
  KEY `idx_BON_TYP` (`BON_TYP`),
  KEY `idx_FINANZWEG` (`FINANZWEG`),
  KEY `idx_START_ENDE_DT` (`START_DT`,`ENDE_DT`)
) ENGINE=MyISAM DEFAULT CHARSET=latin1;

DROP TABLE IF EXISTS `transaktiondetails`;
CREATE TABLE  `transaktiondetails` (
  `SORT_ID` int(11) NOT NULL,
  `TRANSAKTION_ID` int(11) NOT NULL,
  `ID` int(11) NOT NULL,
  `PARENT_JOURNALNR` int(11) DEFAULT NULL,
  `JOURNALNR` int(11) DEFAULT NULL,
  `GEBUCHT_DT` timestamp DEFAULT NULL,
  `ABGERECHNET_DT` timestamp DEFAULT NULL,
  `ARTIKEL_NR` int(11) DEFAULT NULL,
  `ANZAHL` int(11) DEFAULT NULL,
  `PREIS` double DEFAULT NULL,
  `ILEVEL` int(11) DEFAULT NULL,
  `MODIFYER` int(11) DEFAULT NULL,
  `SOFORTSTORNO` double DEFAULT NULL,
  `RUECKNAHME` smallint(6) DEFAULT NULL,
  `STORNO` smallint(6) DEFAULT NULL,
  `MOD_NR` int(11) DEFAULT NULL,
  `MOD_TYPE` int(11) DEFAULT NULL,
  `MOD_FACTOR` int(11) DEFAULT NULL,
  `ISTAUSLAGE` smallint(6) DEFAULT NULL,
  PRIMARY KEY (`SORT_ID`,`TRANSAKTION_ID`,`ID`),
  KEY `idx_TRANSAKTION_ID` (`TRANSAKTION_ID`)
) ENGINE=MyISAM DEFAULT CHARSET=latin1;


DROP TABLE IF EXISTS `transaktionmwst`;
CREATE TABLE `transaktionmwst` (
  `SORT_ID` int(11) NOT NULL,
  `TRANSAKTION_ID` int(11) NOT NULL,
  `ID` int(11) NOT NULL,
  `PARENT_JOURNALNR` int(11) DEFAULT NULL,
  `JOURNALNR` int(11) DEFAULT NULL,
  `TIMESTAMP_DT` timestamp DEFAULT NULL,
  `ITYPE` int(11) DEFAULT NULL,
  `SUMME` double DEFAULT NULL,
  `TAX_ONLY` double DEFAULT NULL,
  `MWS_NR` int(11) DEFAULT NULL,
  PRIMARY KEY (`SORT_ID`,`TRANSAKTION_ID`,`ID`)
) ENGINE=MyISAM DEFAULT CHARSET=latin1;

Das neue steht natürlich noch nicht fest, aber diese Art der Informationen müssen gespeichert & logisch verknüpft sein.

Greetz Data

[tsteinmaurer]

MyISAM Storage Engine, d.h. du/ihr verwendet keine ACID-Transaktionen? Wäre in einem OLTP System IMHO etwas gefährlich, um in Inkonsistenzen rein zu laufen? Oder unterstützt MyISAM in neueren Versionen Transaktion? Hab da schon länger nicht mehr draufgeschaut.

[DataCool]

Zitat von tsteinmaurer:

MyISAM Storage Engine, d.h. du/ihr verwendet keine ACID-Transaktionen? Wäre in einem OLTP System IMHO etwas gefährlich, um in Inkonsistenzen rein zu laufen? Oder unterstützt MyISAM in neueren Versionen Transaktion? Hab da schon länger nicht mehr draufgeschaut.

Du hast schon recht MyISAM unterstüzt keine Transaktionen.
Wie gesagt, es handelt sich hierbei um eine alte Struktur,
die sicherlich nicht 1:1 übernommen wird.
Ob allerdings wirklich bei den "Kassendaten" Transaktionen benötigt werden,
muss näher betrachtet werden.
Schließlich handelt es sich immer nur um ein INSERT.
Danach werden die Daten nicht mehr verändert oder gelöscht.

Greetz Data

[p80286]

Im großen und ganzen nichts auffälliges.
Nur was soll das mit Transakt_ID,Sort_ID und ID ?
Und statt "double" "currency" für die Beträge, falls es geht.

Gruß
K-H

[jobo]

Ich kann mir gut vorstellen, dass die 10MB aus der "externen Datenquelle" relativ redundant gehalten sind.
In einem guten Modell hast Du für die Bewegungsdaten fast nur noch Zahlen/ID, damit kommt man vielleicht auf einen deutlich geringeren Wert als die von Dir insgesamt berechneten 730 GB. Bei großen Datenmengen lohnt auch die Überlegung, ob die Zahl als Byte, Word oder Double gespeichert werden muss. Letztlich sollte das Thema aber keinen großen Einfluss auf das gewählte DB System haben.

Ein Bekannter von mir verwaltet ein vergleichbares System für einen großen Lebensmitteldiscounter- nicht der mit A-
Zentraler Server und lokale alles Oracle DB.

Für Deine Fragestellung ist m.E. nicht so sehr entscheidend, wieviel Daten das System der Wahl halten kann, sondern jegliche Art von performanter und robuster Datenverarbeitung, die das System bietet.
Das beginnt mit dem Deployment (Datenmodell), geht über täglich/nächtlich/online Datenaustausch, Robustheit, Backupverfahren und Pflege (Datenmodelländerung*)

Oracle verfügt über sehr mächtige Synchronisierungsfunktionen inkl DDL und verteilte Transaktionen und dürfte im Bereich Performance/Robustheit führend sein. Auch im Detail gibt es schon in der Standard Version (seit V8) viele (Analyse-)Funktionen, die die Konkurrenz seit dem nachbaut. OLAP / DWH kann es natürlich auch, ist eigentlich ein extra Thema.
Postgres "kenne" ich erst kurz. Verhält sich etwas störisch bei Installation und Zugriffskonfiguration (oder sagen wir, es bietet sehr viele Möglichkeiten), soll sehr Oracle kompatibel sein, konnte ich aber noch nicht verifizieren.
Zu den anderen System habe ich keine nennenswerte bzw. aktuellen Erfahrungen.

* Datenmodelländerung & Co.
Das System (der zentrale Server) muss die gesamte, tägliche Transaktionslast schlucken, entweder über VPN oder über Standleitungen. Internetverbindungen/VPN sind dabei wahrscheinlich noch Dein Freund. Standleitungen eher nicht, gibt's auch außerhalb DE Standorte?
Wie auch immer, man braucht serverseitig viel Bandbreite und muss ein smartes, fehlertolerantes Replikationsverfahren bauen. Und jetzt zum *: Eine Modelländerung kann in solch einem System ziemlich kniffelig werden. Die Master DB muss die Änderung kennen/können (z.B. auch inkl. aller Auswertungen), die Modelländerungen müssen zeitnah, planbar auf alle Clienten ausgerollt werden können und fehlerfrei durchlaufen. Die Synchronisation muss danach wieder fehlerfrei weiterlaufen. Alternative wäre- aufwändiger, aber vielleicht unkritischer- ein Verfahren, das mit 2 Modelversionen und schrittweisem Upgrade der Standorte arbeit.
Und der Admin sollte von diesen Dingen auch irgendwie Ahnung haben finde ich.

[DataCool]

Zitat von p80286:

Im großen und ganzen nichts auffälliges.
Nur was soll das mit Transakt_ID,Sort_ID und ID ?
Und statt "double" "currency" für die Beträge, falls es geht.

Gruß
K-H

SORT_ID = Standort/Outlet ID , diese wurde mitgeführt damit es beim PK keine Collisionen gibt
TRANSAKTION_ID = Verknüpfung zum übergeordneter Transaktion
ID = AutoInc ID in DETAILS Table

Es würde natürlich vieles erleichtern,
wenn es möglich wäre/ist die ankommenden Daten in eine einfache
"flache" Struktur von verkauften Artikel zu bekommen.
Diese Möglichkeiten prüfe ich auch gerade ....

Greetz Data