Firebird ist de facto eine gute Wahl für Blobs in der Datenbank, Referenzen ins Filesystem speichern ist lustig, aber Unsinn, wenn man mit richtig großen Datenmengen zu tun hat.
Auch die schönste Directory Struktur, die vermeidet das man 1 mio Dateien in einem Verzeichnis hat, ist durch den Super DAU User mit der Maus schneller verschoben als man denkt und dann findet man nix wieder. Es hindert auch nur ein Readonly Verfahren oder NAS Techniken einen daran, davon einfach Dateien zu löschen. Speziell die NAS Technik geht dabei extrem auf die Performance. Von interessierter Verschlüsselungstrojanern, die gerne mal alle erreichbaren Dateien in allen Laufwerken encrypten rede ich da jetzt noch mal gar nicht.
Wir haben in einer Produktivdatenbank beim Kunden ca 300 GB PDFs und passende Png Previews der erste Seite, sind insgesamt ca. 900000 Images und 900000 Pdfs.
Sicherlich lässt sich die
DB nicht so einfach backup/restoren, aber wir haben die auch aufgeteilt in Daten bis inkl 2017 (die
db ist readonly, hat ca 250GB und muss nur ein mal pro Jahr gesichert werden) und in eine aktuelle Jahres
DB, in der alle Dateien aus dem aktuellen Jahr landen. Diese wird täglich gesichert (und durch Replikation transaktionsecht auf 2 Servern gespeichert, aber das ist ein anderes Thema). Ende 2018 werden wir dann ggf die
DB von Ende 2017 wieder Readwrite machen, die Daten aus der 2018
DB dahin verschieben und danach die große als neue 2018
DB wieder Readonly setzen.
Den Zugriff auf die Inhalte machen wir immer über eine Stored Procedure und diese sucht dann den Blobinhalt per execute statement on external zunächst auf der aktuellen Jahres
DB und wenn da nix zu finden ist, dann eben auf der Archiv
DB. Per Updatable View kann man das in der Produktionsdatenbank auch direkt einbinden, so das die Blobsspalte in der Tabelle zwar so aussieht, als ob die dazu gehören würden, in Wirklichkeit aber die SP zum Abruf nutzt und eine schreibende SP benutzt, um die daten in die aktuelle Jahres
DB zu packen.
Die Datei Metadaten (also welche Blob Dateien existieren denn überhaupt) bleiben in der Produktionsdatenbank, die Blobs landen immer schon beim Schreiben gleich in der Jahres
DB.
Mit dem Updatable View lassen sich sogar Programme austricksen, die gar nicht wissen das die Blobs woanders sind. Das haben wir gerade für einen Kunden in USA so gemacht und realisieren das auch für einen Softwareanbieter in Deutschland. Dabei wird unter dem alten Tabellennamen ein updatable view erzeugt und die Blobspalte kommt aus einer anderen
db und wird auch da geschrieben, im Programm muss nichts geändert werden.
Bei dem Kunden in Deutschland steht übrigens dann auch immer in der Produktionsdatenbank in der Tabellen mit den blob metadaten das Erstellungsdatum und wir benutzen da die Jahreszahl, um pro Jahr jeweils eine
DB zu haben. Das sind dann zwar ein paar mehr dateien auf dem Datenbankserver, aber man ist sehr flexibel und da alle alten dbs readonly sind, muss man das nicht ständig sichern.
Mein Erfahrung damit ist übrigens das die Blob daten sehr schnell aus der
DB geholt werden. egal ob eine
db oder mehrere, wenn du aber eine Übericht von zB 300 Bilder darstellen willst, verbraucht die meiste zeit gar nicht das Laden vom Blob, sondern das decodieren von png oder jpg. Das war bei uns ein Unterschied von 0,2 sekunden (in der zeit waren alle blobs geladen, aber nicht angezeit) und 10 Sekunden (das war Laden der Blobs aus der
DB und Anzeigen von 300 150*250 pixel pngs jeweils in 50*75 images auf einer scrollbox. Das können verschiedene Image Komponenten sehr unterschiedlich schnell oder lahm)