✔ Für und wider: Speichern von Dateien in Datenbanken

Q

qsrs

Erfahrenes Mitglied
Hallo,

ich schreibe dieses Thema absichtlich im PHP-Forum, da es keine primär technische Frage ist, sondern es soll für und wider aufzeigen, Vor- und Nachteile beim Speichern von Daten in einer MySQL-Datenbank und v.a. der Umgang mit den Daten mittels PHP.

Angenommen ein Dateimanager, mit einigen tausenden von Dateien, würde alle Daten, die hochgeladen werden, statt in einem Verzeichnis direkt in der Datenbank ablegen. Es gibt ja durchaus Vorteile, mit dem Feldtyp LONGTEXT könnten ja theoretisch bis zu 4 GB große Dateien abgelegt werden, das Handling im Umgang mit den Dateien fände ich praktischer. Nun aber die Fragen. Wird die Datenbank bei dieser Größe noch handlebar, sprich, wird sie langsam, schränken Provider die Größe der DB ein, oder gilt hier grundsätzlich immer das Volumen des Webspace, also ist es egal, ob die DB oder die Verzeichnisse das Volumen belegen? Was wären denn richtige Nachteile?
 
Zuletzt bearbeitet:
Ich persönlich würde alle Infos über die Datei in einer Datenbank speichern, die Dateien selber allerdings irgendwo in einen Ordner speichern. Liegt aber auch daran, dass mein Freehoster (http://kilu.de) die Datenbankgröße auf 50 MB beschränkt hat.
 
Meiner Meinung nach wäre das Thema grundsätzlich besser im Datenbanken-Unterforum aufgehoben, da es keinen großen Unterschied macht, ob man via PHP, .NET oder C aus einer Datenbank liest - Viel wichtiger wäre eine passende Engine, wie zB die MyISAM-Engine in MySQL-Datenbanken, die sehr hohe Performanz hat beim Lesen von Datensätzen. Des Weiteren sollte darauf geachtet werden, dass auf 32bit Systemen eine (unkomprimierte) Datenbank aus rein technischen Gründen nicht mehr als 4 Gigabyte an Datenvolumen handhaben kann (Bitte um Korrektur, falls die Größenangabe inkorrekt ist), auf 64bit Systemen können dann doch aber schon mehrere Terabyte-große Daten abgespeichert werden.

Vielleicht solltest du jedoch auch nochmal einen Blick darauf werfen, wie die meisten Datenbankapplikationen arbeiten: Die meisten, mir geläufigen Systeme speichern alle Datensätze in einen bestimmten, oft abgeriegelten Teil der Festplatte und lesen diese entweder direkt von dieser oder im performanteren aber auch "instabileren" Fall aus einem Zwischenspeicher, wie zB dem Arbeitsspeicher. Also macht es aus dieser Sicht wenig Sinn, Daten in eine Datenbank zu speichern, da sie auch nur im Filesystem landen (und dort aber als einzelne Datei nicht in den Zuständigkeitsbereich des Filesystems fallen). Lediglich die Methodik, mit der die Datenbank arbeitet, könnte eventuell zu Performance-Pluspunkten führen, die der Festplattengeschwindigkeit überlegen sind. Dennoch spricht ein weiterer Punkt gegen die Speicherung: Die "Clustergröße" der Datenbankfelder ist bei weitem nicht so flexibel wie die eines Filesystems, obwohl das auch immer eine Sache der Organisation ist. So kann es passieren, dass eine 1kB große Datei in der DB ein paar kB Kapazität "verschwendet", wo mit einer Clustergröße von 1024 Byte auf der HDD kein "Verlust" entstünde.

Ein wohl vor allem für mich relevanter Nachteil ist bei einer datenbankbasierenden Filesystem-Alternative, ist die schlechte Handhabbarkeit, und die stetigen und eventuell unnötigen Zugriffe. Bei jeder Operation an und mit einem Datensatz muss dieser schließlich erstmal komplett durch die Datenbankstrukturen verarbeitet werden, was den ureigenen Funktionen des Filesystems höchstwahrscheinlich nicht das Wasser in Sachen Last und Effizienz reichen kann.

Die Frage,die mich interessiert ist, warum du Daten in eine Datenbank speichern möchtest? Grundsätzlich steigt die Rechenlast und -zeit mit der Größe der zu verarbeitenden Datensätze auch an, und gleicht jeden Vorteil in Sachen Zugriffseffizienz aus, den ein Datenbanksystem haben könnte.
Das soll jedoch nicht heißen, dass Datensätze in einer Datenbank nicht komfortabler zu bearbeiten wären als einzelne Dateien im Filesystem, zumal die Fragmentierung der HDD im Falle einer Datenbank wohl gegen Null geht, da es ein abgeschlossenes System ist. Jedoch bilden die zusätzlichen Zugriffs- und Evaluierungsprozeduren eine große Mehrlast.

Nun nochmal zur Sache: Datenausgabe mit PHP oder anderen Programmier- / Scriptsprachen: Zwar ist zB PHP sehr schnell, was die Verarbeitung von Ein- und Ausgabesignalen angeht, jedoch bedarf es bei einigen MB bis GB dann doch schon Sekunden bis Minuten oder gar Stunden, bis alle Daten verarbeitet wurden, wenn nicht der Server vorher schlappmachte, weil der zur Verfügung stehende Arbeitsspeicher einfach "exhausted" ist oder die CPU sich totgearbeitet hat :)
Also sollte schon gut überlegt sein, ob nicht die Dateizugriffe etwas undynamischer gemacht werden könnten oder anderweitig organsiert werden können um die dynamisch generierte Last auf die Grundfunktionen des Webservers abrollen zu können - Der Zugriff auf Dateien im Filesystem direkt und statisch (direct passthrough) generiert bei weitem weniger Last als eine dynamische Lösung (input, handle, read, handle, output), bei der erst in den Arbeitsspeicher geschrieben wird oder in einen anderen Buffer.
 
Ich speichere Datein und so immer direkt auf Space und schreib die Daten, die ich brauche (Dateiname/größe...) in die DB...
Datein als ganzes haben, finde ich, in einer DB nix verloren, da die zum tabellarischen erfassen von Informationen ist und halt nich zum speichern von Datein... Dafür gibts den Space...
 
Danke an alle für die Antworten, insbesondere maeTimmae für die lange Ausführung. Genau deshalb hatte ich diese Frage gestellt, da mir die Nachteile noch nicht ganz so bewusst waren.
Die Frage,die mich interessiert ist, warum du Daten in eine Datenbank speichern möchtest?
Zum Vergrößern anklicken....
Du hast es schon angesprochen. Die Methodik und der Umgang mit den Daten. Beispiele: Man könnte relativ einfach (einfacher als bei Ablage im Filesystem) Daten auf verteiltem Webspace nutzen. Exporte und Backups sind einfacher zu realisieren, der Umgang mit den Dateien wird grundsätzlich "einfacher". Daten, die gelöscht werden, werden über DB-Abfragen gelöscht. Es bleibt bei theoretisch einem Arbeitsschritt, egal wie der handle aussieht. Aber ein richtiger Nachteil ist wohl die Performance. Ein Programm, das zum Filehosting verwendet wird, und einige hundert User gleichzeitig daran arbeiten, und auch große Datenmengen verarbeiten, lasten die DB mit jeder Anfrage aus. Das ist ein wirklicher Nachteil, der u.U. das ganze System lahmlegen kann.
 
Irgendwie ließ mich die Frage im Schlaf nicht in Ruhe, und mir ist tatsächlich ein relevanter Vorteil einiger Datenbankarchitekturen eingefallen, der wohl in keinem Filesystem so existiert(es sei denn, es ist vollständig indexiert... In einer Datenbank(ähnlichen)-Struktur ;) ):
Die schnelle Suche nach Zeichensequenzen in sowohl binären als auch anderen Daten(fragmenten) und deren Bearbeitung. Dieser Vorteil geht aber zu Lasten eines erhöhten Speicher- und Indexierunsaufwands. Technischer Hintergrund ist, dass die Datensätze in einem Rutsch zugrifsbereit sind, wohingegen Operationen im Filesystem von der Clusterröße der Partition aber auch vor allem von dem Zugriff auf die entsprechenden Inodes abhängig sind.
 
Um antworten zu können musst du eingeloggt sein.

Neue Beiträge

Zurück