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:

Zitat von DataCool (Beitrag 1209946)

- 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:

Zitat von DataCool (Beitrag 1209946)

- 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:

Zitat von DataCool (Beitrag 1209946)

- 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:

Zitat von DataCool (Beitrag 1209946)

- 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:

Zitat von DataCool (Beitrag 1209946)

- 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:

Zitat von Bernhard Geyer (Beitrag 1209949)

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?

[mcinternet]

Nimm Oracle,

das Ding ist hochperformant, skalierbar und bietet aufgrund der Möglichkeiten viele Prozeduren, Function etc. direkt in der Datenbank ausführen da die beste Möglichkeit.


Gruss

McInternet

[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

[Furtbichler]

Table-Partitioning brachte bei MSSQL in einer Fallstudie (pro Monat eine Partition) einen Geschwindigkeitszuwachs um den Faktor 1000. Die Größe der DB war vergleichbar. Bringt also schon was.

Zitat:

Zitat von Patito (Beitrag 1209958)

MSSQL: Ist ganz gut.

Dafür, das der SQL-Server im TPC-E Benchmark alle Top-10 Plätze belegt, ist diese Einschätzung vielleicht etwas zu allgemein gehalten.

Zitat:

Zitat von Patito (Beitrag 1209958)

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

Auch ein wenig dürftig. Damit kommst Du bei TB-Datenbanken nicht weit. Table-Partitioning oder vielleicht ein in-memory OLAP server wäre eine Option. PALO ist frei und ganz lustig. Wenn Geld vorhanden ist, könnte Jedox (Freiburg) eine Möglichkeit sein. Ich weiß allerdings nicht, ob sich das bei TB-Größen lohnt.

In jedem Fall wäre die von mjustin erwähnten NoSQL-Systeme eine Betrachtung wert. Und die können verteilt abspeichern, müssen aber nicht. Persönlich würde ich (weil ich damit groß geworden bin) den SQL-Server verwenden.

[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

[MrSpock]

Zitat:

Zitat von Furtbichler (Beitrag 1209965)

Dafür, das der SQL-Server im TPC-E Benchmark alle Top-10 Plätze belegt, ist diese Einschätzung vielleicht etwas zu allgemein gehalten.

Wurde denn beim TPC-E irgendetwas anderes als MS SQL Server betrachtet?

[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 :dp:

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 :wink:

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:

Zitat von DataCool (Beitrag 1209996)

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

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

[Patito]

Zitat:

Zitat von DataCool (Beitrag 1209996)

Erstmal Danke für die rege Beteiligung :dp:
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:

Zitat von Nersgatt (Beitrag 1210001)

Zitat:

Zitat von DataCool (Beitrag 1209996)

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

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

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

Greetz Data

[DataCool]

Zitat:

Zitat von Patito (Beitrag 1210002)

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:

Zitat von tsteinmaurer (Beitrag 1210009)

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:

Zitat von tsteinmaurer (Beitrag 1210016)

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:

Zitat von p80286 (Beitrag 1210018)

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

[Bernhard Geyer]

Zitat:

Zitat von MrSpock (Beitrag 1209984)

Wurde denn beim TPC-E irgendetwas anderes als MS SQL Server betrachtet?

Das Problem an den TPC-Tests das sie nicht gerade billig sind (AFAIK 6stelligen €-Betrag sollte man schon einplanen) so das hier nur sehr wenige gültige Testdaten vorliegen. Also können nur die großen dieser Welt (MS, Oracle, IBM) diese Tests auch bezahlen. Wenn nun Oracle bei diesen Tests nicht dabei ist vermute ich das hier Oracle aktuell nicht mehr so gut dastehen würde.

[IBExpert]

und hier noch mal eine Meinung Pro Firebird!

Die größte Tabelle in einer Kunden DB hat 1,2 Milliarden Datensätze, Datenbanken um 100GB sind nicht so ungewöhnlich, da kenn ich einige im Livebetrieb. Die größte DB, von der mir ein Kunde berichtet hat, liegt bei 15 TB. Wenn deine Auswertungen auf so einer DB einen Full Table Scan über alle Tabellen macht dauert es eben, weil die Hardware normalerweise nicht hinterherkommt.

Seit fb25 speicht aber auch nichts dagegen, das du deine Daten zu den 100 Filialen in der zentrale in mehreren Datenbanken auf mehreren Serverinstanzen laufen lässt und deine Auswertungen im Batchbetrieb parallel alle Instanzen belästigt. FB25 wegen execute statement ... on external

Das kannst du auch nutzen, um asu der Datenbank heraus selbstständig eine oder mehrere Archivdatenbanken zu füllen und bei entsprechend intelligenter Programmierung der Auswertungen diese ohne Umwege einfach mit einzubinden. Mit einer Replikation zwischen den Datenbanken kannst du das auch unbegrenzt skalieren, wir haben mehrere Replikationen bei Kunden mit Firebird umgesetzt.

Ein IBExpert Kunde aus USA im Gastrobereich verwaltet mit einer simplen Datenbank die kompletten Daten einer Bar in Manhatten mit 800 Tischen und hat bisher laut eigener Aussage keine Gründe gehabt, historische Daten daraus zu löschen.

Bei solchen Datenmengen würde ich ggf. dem Kunden auch hardwareseitig schon mal klar machen, das so eine Lösung auf einem normalen Raid HDD System nicht empfehlenswert ist, Enterprise SSDs bieten da mit PCI Schnittstelle teilweise 10 fache Performance. Um 100GB von der Platte in den Speicher zu saugen braucht eine normale Platte schon mal leicht 1000 Sekunden, wenn die 100MB pro Sekunde Leseleitung hat. Bei einer PCI Enterprise SSD kommst du da mit 50 Sekunden aus. Und ganz wichtig: Bei den Anforderungen Finger weg von Virtualisierung!

Was meiner Meinung nach viel wichtiger ist als die Auswahl einer anderen DB ist wesentlich mehr die konsequente Umsetzung eines für solche Datenmengen geeignetes Datenmodell. Wenn du das zum Beispiel gleich mit updatable views und lieber mehr Tabellen, dafür weniger Spaltebreite, umsetzt, dann wirst du da noch lange Freude dran haben. Bei Abfragen solltest du nicht einfach kreuz und quer joins zusammenbasteln, nur weil dabei das richtige Ergebnis rauskommt. Bei solchen Datenmengen kannst du entsprechende Auswertungen mit geplanten Full table scans via Prozedur oder execute block auch sehr positiv in der Performance beeinflussen. Beim größten Kunden replizieren wir daten aus 8500 Datenbanken, haben aber nicht so viele Datensätze pro Tag und brauchen die auch nicht so lange aufbewahren.

ich würde mir anhand der Rahmendaten die Umsetzung mit Firebird ohne Einschränkungen zutrauen, ob dir das ohne externe Hilfe auch gelingt kann ich nicht sagen (aber ein paar Basics dazu gibt es nächste Woche in Hamburg auf einer Schulung von uns)

[tsteinmaurer]

Interessant wird der Umgang mit großen (Anzahl der Datensätze und nicht notwendigerweise in GB) Firebird-Tabellen dann, wenn man einen Index rebuilden möchte, der sich physisch gesehen, nur auf einen Teilbereich der zu indizierenden Daten bezieht, wenn man eine größere Anzahl an "älteren" Datensätzen aus der Tabelle "rauspurgen" möchte da hier dann die Garbage Collection zuschlägt etc.

Das sind Dinge die man vielleicht mit ultraflotter I/O und Firebird-seitigem RAM Tuning kaschieren kann, aber hier ist die Oracle Partitionierung echt hilfreich, da Indizes auf Partitionen kleiner und somit besser handhabbar sind. Rauspurgen ist ein einfaches DROP oder TRUNCATE auf einer Partition. Von einem unterschiedlichen Backupkonzept für ältere vs. neuere Daten in einer Tabelle spreche ich noch gar nicht.

D.h. so Easy-Cheasy kann sich der Betrieb vielleicht dann nicht darstellen. D.h. sollte man in Richtung Firebird gehen, wäre ev. eine Überlegung in Richtung Aging-Konzept mit der Pre-Aggregierung für analytische Abfrageanforderungen notwendig. In Sachen Eigenwerbung ala Holger, könnte dir mein Artikel hier eine Idee geben: http://www.ibphoenix.com/resources/d.../general/doc_1 (Poor-Mans Materialized Views) :-D

[Alfredo]

Ich habe mich von PostreSQL wieder verabschiedet, da die ständigen Versions-
wechsel mit sehr viel Aufwand verbunden sind. Wenn Linux als OS verwendet
wird ist das ganz besonders spannend, da der Admin aufpassen muss, dass
er nicht die neueste Version automatisch eingespielt bekommt und dann
kommt da richtig Freude auf.

Die Datensicherung im laufenden Betrieb ist nur für einen absoluten Fach-
man ohne Probleme zu realisieren. Firebird ist da wesentlich unkomplizierter.

[IBExpert]

Zitat:

Zitat von tsteinmaurer (Beitrag 1210039)

... In Sachen Eigenwerbung ala Holger, könnte dir mein Artikel hier eine Idee geben: http://www.ibphoenix.com/resources/d.../general/doc_1 (Poor-Mans Materialized Views) :-D

Danke für den Tip, sieht auf den ersten Blick schon mal ganz interessant aus, werde ich mir mal in Ruhe durchlesen.

Was mir immer nur aus der Erfahrung Angst macht, ist die Tatsache, das gerade im Oracle Umfeld auch ziemlich viele Blinde rumlaufen, die mal auf einer Schulung waren und sich nun für Schweinchen Schlau halten.

Wir haben für einen Kunden Firebird Daten in eine Oracle DB repliziert, jede Nacht kam das Delta per script über odbc, was zwischen 10000 und 20000 Transaktionen umfasste. Was 9 Monate auch problemlos lief, bis wir dann vom Kunden und "seinem Oracle Experten" eine Nachricht bekamen, das unsere Schnittstelle seit gestern den kompletten Oracle Server lahmlegt.

Als ich dann nach langem Bitten die konkrete Fehlermeldung von Oracle bekam und da was las von "materialized view" und sinngemäß "too many executions", war mir eigentlich schon klar, das da jemand vermutlich einen Materialized View mit refresh on commit definiert hat. Laut "Oracle Experten" des Kunden wurde da angeblich gar nichts innerhalb der letzten Tage geändert, nach intensiver Intervention von mir konnte man doch einen Schuldigen finden. Das ganze hat mit ein paar Stunden gekostet und dem Kunden nahezu einen Tag Ausfall, nur weil ein Vollidiot meinte, etwas zu optimieren, weil er in einem Forum gelesen hat, das das alles ganz doll ist .... .

Oracle bietet sehr gute Features, aber man braucht im High End Bereich jemanden, der sich damit auskennt und die Kenntnisse aufzubauen ist nicht mit hier und da mal im Internet surfen erledigt. Ich finde es ja alleine schon erschreckend, welche firebirdbasierende Datenbankanwendungen von Softwareherstellern ausgeliefert werden und wie handwerklich schlecht die umgesetzt wurden. Manchmal möchte man beim ersten Blick in die Monitortabellen schon heulend rauslaufen ...

Die Daten aus der urspünglich angefragten Anwendung sind ja nach der Erstellung ausgesprochen statisch, warum sollte man Kassenbons von vor x Jahren noch mal ändern. Daher lassen sich da größe Teile von Auswertung über solche Techniken wie du die beschreibst deutlich verbessern. Übrigens falls Ihr nächstes Mal beim Supermarktmetzger am Tresen steht und die Waage von Bizerba ist: Die benutzen auch Firebird in deren ERP und da kommen bei großen Lebensmittelketten sicherlich deutlich mehr Daten zusammen als in ein paar Kneipen .... ;-)

[tsteinmaurer]

Zitat:

Danke für den Tip, sieht auf den ersten Blick schon mal ganz interessant aus, werde ich mir mal in Ruhe durchlesen.

Solltest du das in einen deiner Workshops kommerziell verkaufen, dann wäre ein Copyright Notice eine feine Sache. :thumb:

Zitat:

... im High End Bereich jemanden, der sich damit auskennt

Gilt nicht nur für Oracle. Man braucht immer jemanden der sich auskennt, wenn es etwas ins Eingemachte geht.

Zitat:

Ich finde es ja alleine schon erschreckend, welche firebirdbasierende Datenbankanwendungen von Softwareherstellern ausgeliefert werden und wie handwerklich schlecht die umgesetzt wurden. Manchmal möchte man beim ersten Blick in die Monitortabellen schon heulend rauslaufen ...

Schlecht umgesetzte Datenbankanwendungen ist die eine Sache. Ich hab mittlerweile schon so viele Firebird-Umgebungen in Schwung bringen dürfen, weil Firebird "sorglos" mit dem Installer mit ein paar Mausklicks installiert wurde und das wars. Das ist leider etwas, was man durch die Einfachheit von Firebird einfach vorfindet. "Leider" ist relativ, ist auf der anderen Seite das Geschäft für uns Dienstleister. :thumb:

Oracle ist eine andere Liga, wenn man sich damit auskennt. Materialized Views und Paritionierung sind nur ein sehr kleiner Bereich. Aber in einem Projekt ginge es ohne diese Techniken einfach nicht, obwohl Materialized Views, vor allem wenn man in Richtung inkrementelle Nachaggregierung geht (gehen muss), wiederum mit einigen Einschränkungen leben muss bzw. diese genau kennen muss, sonst läuft man schnell mal in eine vollständige Aktualisierung der MV anstatt einer Inkrementellen. :-D