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)