Benchmarking (Objekte in DB vs. Objekte als Dateien)

[Daniel]

Moin,

der eine oder andere mag es wissen, dass ich mich mit einem Foren-Projekt befasse. In den einschlägigen Supportforen wird eine Frage immer wieder diskutiert: Legt man binäre Daten (in diesem Fall Attachments) lieber als Dateien im Dateisystem ab oder steckt man sie mit in die Datenbank.

Da gibt es einmal die, die sagen "Daten in die DB, Dateien ins Filesystem". Ich halte die Aussage für zu pauschal, da Anhänge und Bilder in diesem Zusammenhang sehr wohl Daten sind. Auf einem popeligen Shared-Webhosting mit 5.000+ Nutzern auf einem DB-Server und einer limitierten DB-Größe von maximal 30 MBytes würde ich ebenfalls davon abraten, dort noch Anhänge unterbringen zu wollen - logisch.

Bei Backups ist das Hantieren mit Verzeichnisstrukturen, die 30.000+ Dateien enthalten, auch nur bedingt spaßig. Da lasse ich lieber die DB kopieren, die dann halt um 7 GBytes groß ist. Die Verbindung zum Backup-Server ist schnell, das juckt mich eigentlich nicht.


Wie könnte ich jetzt zu sinnvollen Aussagen darüber kommen, welche Vorgehensweise mit der mir zu Verfügung stehenden Hardware und dem zu erwartenden Nutzeraufkommen die geeignetere ist? Was bedeutet es konkret für ein DBMS wie MySQL, wenn es Dateianhänge in der Größe von ein paar KBytes bis hin zu max. 5 Mbytes zu verwalten hat? Da niemand erwartet, dass alle Records gleichzeitig im Speicher liegen, würde ich es wagen, die These aufzustellen, dass ein aktuelles DMBS (selbst MySQL...) damit zurecht kommen MUSS. Wie kann ich also herausfinden, wie mein DBMS beeinflusst wird, wenn eine Tabelle existiert, die "wirklich groß" (30.000+ Records, 6 GBytes) ist?

[mkinzler]

Du hast ja die wesentlichen Aspekte schon angesprochen. Beide Varianten haben Vorteile und Nachteile. Wobei hier auch die Wahl des DBMS (was ja durch MySQL schon vorgegeben ist) auch eine Rolle spielt.
Die Variante, in der die DB nur den Index enthält, dürfte bei MySQL etwas schneller sein ( andere DBMS wie Oracle oder FireBird kommen mit Blobs besse zurecht). Diese Version würde man auch wählen, wenn der Zugriff auf die Datein auch unabhängig von der DB Anwendung möglich sein soll.
Bei der anderen Variante ist der Backup bzw verschieben der Daten natürlich leichter

[himitsu]

Wie wäre es mit einer Mischung?

Vorallem kleine und aktuelle Dateien in die DB
und die sehr großen, sowie Dateien, auf welche schon länger nicht mehr zugegriffen wurde ins Dateisystem auslagern.

So oder so ... im Dateisystem sollte besser nicht alles in ein und das selbe Verzeichnis, damit die jeweiligen Verzeichnisse nicht all zu umfangreich werden.


Bei meinem kleinen CMS plane ich es so, da die Dateien im Dateisystem sind, aber aktuelle Dateien mit in der DB-Cache landen.

Wenn du genug Speicher hast, dann könntest du die Dateien auch gleich noch mit fertig komprimiert vorhalten, falls z.B. der Browser (was die heutzutage ja meistens machen) eine komprimierte Datenübertragung zulassen.
> spart ein bissl Traffic
> und beim Verschicken RAM und CPU-Last, da sie dann direkt rausgeschickt werden könnten



PS: Wenn die Datei vom Dateisystem kommt, dann kann man den Dateiinhalt doch direkt Stück für Stück raussicken lassen (z.B. PHP bietet da ja nette Befehle dafür), wärend es von der DB erstmal (vermutlich in den RAM) geladen werden muß, bevor es rausgehn kann und solange bis es verschickt wurde.



Ein weiterer Vorteil an der DB-Variante wäre auch, daß hier die Dateien und die sonstigen Daten direkt verbunden wären, was für ein Backup doch wohl auch nicht schlecht ist. Also Alles am selben Ort.

Wärend die einzelnen Dateien erstmal wild im Dateisystem umliegen und somit physisch getrennt von den verlinkenden Foren-Beiträgen sind.

[SirThornberry]

Wenn man davon ausgeht das große Dateien die Datenbank langsamer machen würde ich auch eine Mischlösung bevorzugen. Wenn du Daten in der Datenbank speicherst hast du den Vorteil das du per Datenbankabfrage auch nach dem Inhalt von Dateien suchen kannst.
Den Punkt der Datensicherung würde ich vernachlässigen je nachdem wie der Zugang zum Server aussieht. Wenn man ein Script hat ist es eigentlich unerheblich ob es ein Verzeichnis sichert (wo die mysql-Daten liegen) oder ob es noch zusätzlich ein weiteres Verzeichnis ins Backup hinzufügt.

[Daniel]

Die Dateien wären im Dateisystem qualitativ nicht schlechter aufgehoben. Das vBulletin strukturiert das ganz anständig und die Verbindung zu den jeweiligen Beiträgen lässt sich auch immer herstellen. Aber das ist nicht der Punkt...

Die Frage ist ja eben, OB die Datenbank langsamer wird.

[mkinzler]

Bei einem DBMS, in dem die Blobs nicht getrennt von den restlichen Feldern gespeichert werden führt das zu einem Performanceverlust

[SirThornberry]

Unseren Nutzern würden wir immer schreiben. "Probier es doch einfach aus".

[s.h.a.r.k]

Wie simuliert man da allerdings ein relativ hohe Nutzer-Aufkommen? Ich denke nicht, dass man das Verhalten sinnvoll nachstellen kann. Aber bei ausreichender Leistung (vor allem aber RAM) sollte es eigentlich kein Problem sein.

Wobei ich den Punkt der Sicherung schon als wichtig erachte, denn dann ist das Ganze etwas konsistenter imho.

[franktron]

Also ich habe das mal so gemacht alle Daten in einer Extra Tabelle und die dann nur geladen wenn nötig.

Das gab keine Performance Probleme.