von unserer Seite aus mit Dateien, insbesondere PDF als auch Images, haben wir als auch diverse Kunden sehr gute Erfahrungen gemacht.
Beispielsweise nutzt ein Kunde eine Firebird
DB mit mittlerweile mehr als einem Terabyte an pdf Dokumenten. Bei unseren Kundenprojekten sind das meistens aber 50 bis 100 GB.
Wir nutzen gescannte pdfs schon seit mehr als 10 Jahren, um die in eine Firebird
DB zu packen und haben ein kleines viewer programm da drauf, mit dem man im extrahierten Text in einer zweiten Blobtabelle mit fk auf den PDF in der PDFBlob Tabelle eine Volltextsuche machen kann.
Meine persönlichen Erfahrungen mit NTFS Filesystemen unter Windows haben mir gezeigt, das die nun mal nicht für große Anzahl von Einzeldateien geeignet sind. Durch ein Programm, das eine große Menge kleiner Dateien im filesystem in einem Pfad erzeugt hatte, habe ich festgestellt, das die mittlerweile ca. 2mio dateien das filesystem nahezu unbenutzbar gemacht haben. Der Eplorer war dabei schon lange nicht mehr benutzbar, aber auch ein simples DOS Fenster, das einen dir Befehl in dem Pfad ausführen sollte, hab ich nach mehreren Minuten abgebrochen. Angeblich soll das mit 4mrd dateien pro ordner gehen, das halte ich aber für ein Gerücht. Ich hab nachher die Platte formatiert, nachdem ich mehrere Stunden versuchte, die Ordnerinhalte zu löschen.
Zurück zur Ausgangsfrage: Warum also pdfs lieber in der
DB (mit Fokus auf Firebird)?
1. Trigger: Wenn jemand was löscht kann ich das trotzdem Programmgesteuert in dieser
db oder auch in einer anderen
DB speichern und archivieren
2. Datensicherung: Firebird hat ein Hot Backup Verfahren, d.h. obwohl dutzende User vielelicht gerade irgendwas lesen und/oder schreiben, kannst du die Daten sichern und es werden nicht wie bei Dateikopien offene Dateien einfach ignoriert. Bei Bedarf kannst du mit einer Datei auf deinem Laptop oder einer Wechselplatte alle PDF Dateien mitnehmen.
3. Archivierung: Wenn eine Datenbank ziemlich groß wird, ist natürlich ein Vollbackup aufwändig. Wir arbeiten daher immer mit den Dateien in zwei Datenbanken. In der Produktionsdatenbank, die meistens auf einer SSD liegt, werden alle neuen PDFs eingefügt. Bei uns wird aber ein mal monatlich ein großer Teil der Dateien (die die 30 Tage oder älter sind), in eine zweit
DB übertragen. Diese ist normalerweise Read Only und wird nur während der Übertragung der Daten zeitweise auf Readwrite gestellt. Während der Übertragung liest eine SP die PDF und Bildinhalte in der Tabelle der Produktions
DB au, überträgt die per ... execute statement on external ... an die Archiv
DB, wo mit gleichem PK die Inhalte in eine strukturgleiche Tabelle eingetragen werden. Anschliessend wird der Blobinhalt in der Produktions
DB auf NULL gesetzt. Das das ganze unter Transaktionskontrolle läuft, geht garantiert nicht verloren, das geht per Firebird direkt von
db zu
db. Nach der Übertragung wird dann die Archiv
DB wieder auf Readonly gesetzt. Wenn ich nun ein Backup der Archiv
DB mache, brauch ich den Rest des Monats kein weiteres Backup machen, kann sich ja nichts geändert haben, ist ja Readonly. Für das Auslesen der
DB nutze ich eine SP, die einfach die Blobs aus der Produktions
DB zu einem PK ausliest und wenn die dort nichts gefunden hat, dann sucht die eben per execute statement on external auf der Archiv
DB.
Ob man die Archivierung nun monatlich macht oder wöchentlich, oder jedes Jahr eine weitere Archiv
DB anlegt, ist aus der Sicht der Applikation egal, da diese immer über den Umweg der SP Blobs holt. Die Archiv
DB liegt dann auch durchaus auf einer normalen Festplatte, weil der Speed beim Auslesen einzelner Blobs nun wirklich keine Zauberei ist und die Blobs ja auch immer nur dann geholt werden, wenn irgendjemand die ansehen will. Überschreiben alter Blobinhalte mache ich generell nicht, lässt sich aber durch das Verfahren auch problemlos umsetzn.
4. Skalierbarkeit: Fragt euch einfach mal, warum das suchen einer Datei, ohne das auch nur irgendwas vom Inhalt untersucht wird, auf durchschnittlichen Laufwerken mehrere Minuten dauert? Filesysteme sind keine Datenbank, sondern bekommen durch irgendwelche Index Funktionen dann nach und nach mehr oder weniger akzeptable Geschwindigkeiten bei solchen Suchvorgängen. Die Architektur von Filesystemen und Datenbanken unterscheiden sich aber erheblich. Die Datenbankvariante kann die Archiv Datenbank auch auf verscheidene Laufwerke oder unterschiedliche Server verteilen. Beim Schrieben der Dateien knnt ihr via trigger in der gleichen Transaktion der PDF Inhalt in mehrere
DB Server eintragen. Das geht alles mit Firebird in wenigen Zeilen Quelltext ab Version 2.5
5. Transaktionssicherheit: Du kannst den Inhalt deiner
DB löschen und machst danach einen Rollback und schon ist wieder alles da. Das geht im Filesystem nur sehr begrenzt, in Netzwerkumgebungen auf Netzwerkshares dann schon gar nicht.
6. Isolierung gegen Fremdzugriffe: Wer eine PDF Datei in der
DB ändern oder löschen will, muss die
DB Schnittstelle benutzen. Irgendwelche amoklaufenden Antivirenscanner oder Backuptools können höchstens die Gesamte
DB zerlegen, nicht aber Teil davon, in denen so ein blödes Antivirenprogramm mal wieder meinte, was verdächtiges zu finden und das dann einfach mal ungefragt in die Quarantäne zu verschieben, um es von dort nach 30 Tagen ganz zu löschen, ohne das es jemand gemerkt hat
7. Weitere Vorteile, die wir noch dazu nutzen, sind zum Beispiel Replikation von Blobinhalten und diverse andere mehr. Neben PDFs sind auch Excel dateien, dxf zeichnungen uvm in der
DB, für die nach einer Änderung automatisch auch alte Versionen gespeichert werden, so das man ein nahezu unbegrenztes Undo zur Verfügung hat.
Ich könnte noch diverse weitere Punkte aufführen, aber dafür ist es mir jetzt zu spät ....
