Welche Server-DB bei großer Datenmenge

[Bernhard Geyer]

Zitat von MrSpock:

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)

[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 von tsteinmaurer:

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

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.

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.

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.