Bilder in der Datenbank vermeiden? Wieso?
-
Also die Argumente gegen BLOBs die ich kenne sind
* gross -> backup dauert lange
* DB meist stärker fragmentiert als FS
* DB defragmentieren umständlicher/dauert länger
* zugriff auf die files nur über spezielle tools möglich
* DB server wird durch das rumschaufeln von grossen datenmengen zusätzlich belastetDas sind für mich aber alles keine absoluten KOs.
Ich speichere z.B. die Attachments in unserem Wiki als BLOBs, weil das Handling dadurch stark vereinfacht wird.
Da es nicht so massiv viele Attachments gibt ist das auch kein Problem.Und ab wann ist ein BLOB ein BLOB? Ist ein XML Schnippel mit 100 Byte ein BLOB? Ein XML Schnippel mit 1000 Byte? 10K? 100K? 1M?
-
Unix-Tom schrieb:
Wenn BLOBS so gut sind dann würde es auch nicht Filestreams geben.
Na Prima... Ich hoffe das willst du nicht verallgemeinern.
Wenn Glasflaschen so toll wären würde es keine Plastikflaschen geben? Und umgekeht?
Wenn Dosen so toll wärem, würde es keine Gläser geben? Und Umgekehrt?Und mal was was wirklich zum Thema passt:
Wenn LKW so toll wären, würde es keine Autos mehr geben? und umgekehrt.
Ich würd mal sagen es hängt stark vom Verwendungszweck ab...
-
Sqwan schrieb:
Ich würd mal sagen es hängt stark vom Verwendungszweck ab...
Jup.
Zum Beispiel kann ich bei Trennung die DB täglich vollbackuppen und die Bilder inkremetiell. Oder die Datenbank auf SSD haben und die Bilder auf Drehscheiben.
Ob ich das machen will, und damit die DB irgendwie uneinfacher wird, je nach dem.
-
Unix-Tom schrieb:
Filestreams sind ja nichts anderes als Dateien im Dateisystem und die Ref. darauf in der DB.
Nichts anderes ist es wenn man es händisch macht.Naja schon eigentlich. Thema Transaktionen und so.
Wenn BLOBS so gut sind dann würde es auch nicht Filestreams geben.
Und wenn mir jetzt ein passender blöder Spruch einfallen würde, würd ich ihn auch hier reinschreiben.
Möchte man die Rechte erhalten sollte man auch nicht über das ablegen in der DB nachdenken.
Vielleicht möchte man ja auch die Authorisierung selbst machen.
Bei Datenbanken ist es immer einzuhalten das Datenbankfile so klein wie möglich zu halten.
Hihi, schon wieder pauschalisiert.
Kann man aber noch weiter fassen: bei Daten ist es immer einzuhalten so klein wie möglich zu halten.
Ist dann aber genau so falsch (bzw. irreführend) wie wenn man es nur auf Datenbanken bezieht, zumindest wenn das dazugehörige "so gross wie nötig" fehlt.Was ich mir vielleicht noch bei MySQL vorstellen kann ist eine eigene Tabelle it 2 Spalten: BLOB und GUID und eine 2. Tabelle wo die Infos zum File stehen.
- Wird man das wohl meistens so machen und
- Würde das bei MySQL denn einen Unterschied machen? Abgesehen von der Möglichkeit zur Deduplication, also wenn man davon ausgeht dass es sowieso keine BLOBs mit gleichem Inhalt gibt. Bei MSSQL sollte das egal sein, denn da landen BLOBs sowieso "out of page" in ihrem eigenen Bereich, und müllen die Tabelle damit nicht zu.
Ein weiteres Thema ist Indexierung bzw. Volltextindex.
Wieso sollte das ein Thema sein? Verstehe ich nicht. Wenn man die BLOBs indizieren will dann indiziert man sie eben, wenn nicht dann nicht. Und wenn man will, dann sollte es doch wohl einfacher gehen mit BLOBs als mit (manuell) verlinkten Files. Nicht?
Im übrigen habe ich nichts pauschaliert sondern "SOLLTE" geschrieben.
"Man sollte immer" ist gleich pauschal wie "man darf nie" o.ä., es ist nur der "schwächere Imperativ"
Eine BLOBTABELLE ist langsam.
Hihi, SCHON wieder
-
Oder die Datenbank auf SSD haben und die Bilder auf Drehscheiben.
Dafür brauche ich kein Filesystem: ein Tablespace auf SSD, ein zweiter Tablespace (für Blobs) auf Drehscheibe. Konfigurationsaufwand eine Minute.
Einige unserer Kunden setzen ein High Availability Disaster Recovery System ein. Das ist ein zweiter Datenbankserver, der im Falle des Ausfalles des ersten Systems innerhalb weniger Sekunden einspringt (sämtliche Transaktionen des Online-Servers werden auch an den Backup-Server geschickt). Wäre ziemlich albern, wenn man zwar die Datenbank hätte, die Daten im Filesystem aber futsch wären.
-
Unix-Tom schrieb:
Ich spreche auch nicht von MSSQL. Dort ist es sowieso kein Thema mehr da eben Filestreams.
Die Filestreams unterliegen, soviel ich weiß, ebenso den Einschränkungen des Dateisystems wie eine direkte Ablage im Dateisystem. Je nach Anwendungsfall kann dies schlicht und ergreifend der verkehrte Weg sein. Und es gibt viele Argumente für und wieder der Ablage von Dateien in der Datenbank bzw. im Dateisystem.
Der beste Weg ist meines Erachtens die Ablage in der Datenbank zu ermöglichen, nicht aber aufzuzwingen (mit allen Vor- und Nachteilen die dazu gehören.
Unix-Tom schrieb:
Es hat eune guten Grund warum MS auf Filestreams setzt...
Wenn BLOBS so gut sind dann würde es auch nicht Filestreams geben...Hast du wirklich schon mit Anwendungen gearbeitet, wo der Zugriff auf Dateiebene stark eingeschränkt werden muss? Sprich wo für jede Datei einzeln die Rechte gesetzt werden können, wer den nun lesen/schreiben etc. darf? Und wo die Rechte auch über die Anwendung jederzeit angepasst werden können? Und ja, Datenbanken stellen zum Umgehen der Rechte zumindest eine größere Hürde da, als das Dateisystem. Gerade wenn man nach außen hin einer Tabelle keinerlei Zugriffsrechte gibt, sondern nur indirekt über eine STP, die dann die Rechte aus Anwendungssicht prüft.
Unix-Tom schrieb:
Rechtesystem gibt es in einer Datenbank überhaupt nicht solange man es nicht selbst macht.
Viele Datenbank unterstützen Rechtesysteme, die Rollen- oder Benutzerbezogen sind. In den oben genannten Fall muss man Hand anlegen, aber es geht wenigstens (im Gegensatz zum Dateisystem wo der Abgleich wesentlich schwerer wäre). Des weiteren können, je nach Datenbanksystem Blobs in eine andere Datei ausgelagert werden, so das sie nur dann für Zugriffe relevant werden, wenn auch auf diese zugegriffen wird. Von einer Versionierungsmöglichkeit der Dateien mal ganz abgesehen.
Unix-Tom schrieb:
Speichert man eine BLOB in der DB dann verliert die Datei alle Rechte...
Möchte man die Rechte erhalten sollte man auch nicht über das ablegen in der DB nachdenken.Es gibt Rechte die nichts mit Dateirechten zu tun haben, sondern Anwendungsbezogen sind (ist sogar eher der Fall in Unternehmensanwendungen). Und die weit über das hinaus gehen, was in einem Dateisystem möglich ist (Zumal eine große Anwendung meist noch eine wesentlich feingranuliertere Rechtevergabe hat).
Zudem müssen Dateien und Datenbank in der Regel absolut synchron sein (Thema: Transaktionssicherheit, Konsistenz...). Bei einer Trennung der Datenhaltung ist dies wesentlich schwerer zu garantieren.
Unix-Tom schrieb:
Mit SICHERUNG NUL Probleme meinte ich MSSQL.
Die wichtigsten Sicherungsprogramme im Firmenbereich kommen damit perfekt zurecht.
BackUP Exec.Dies ist auch bei allen anderen Datenbanken ohne Probleme möglich.
Unix-Tom schrieb:
Bei Datenbanken ist es immer einzuhalten das Datenbankfile so klein wie möglich zu halten.
Es kommt auf die Prioritäten an. Und es gibt einige gesetzliche Rahmenbedingungen die recht hohe Anforderungen an den Datenschutz stellen. Es darf jedenfalls nicht passieren, das man über das Dateisystem an Dateien kommt, die man über das Datenbanksystem nicht erreichen kann (wegen der Benutzerverwaltung der Anwendung). Und spätestens wenn eine Firma bei dir Regressansprüche anmeldet, würde ich stark überlegen wo die Prioritäten liegen...
Unix-Tom schrieb:
Ein weiteres Thema ist Indexierung bzw. Volltextindex.
Die man aber auch über Hilfstabellen lösen kann (vor allem, wenn viele verschiedene Dateiformate verwendet werden).
Unix-Tom schrieb:
Im übrigen habe ich nichts pauschaliert sondern "SOLLTE" geschrieben.
Und auch dieses sollte halte ich für problematisch. Dieses Thema ist sehr von den Rahmenbedingungen abhängig, und Anwendungsbezogen. Ein "sollte" besagt, das man es zwar anders machen kann, dies aber in der Regel nicht zu empfehlen ist. Dies ist hier in diesem Fall aber recht problematisch (wie ich selbst in Unternehmen erlebt habe), es hängt ganz stark davon ab, wie wichtig die Dateien sind, und ob diese stark reglementiert werden müssen.
Unix-Tom schrieb:
Eine BLOBTABELLE ist langsam.
Auch hier ist die Frage der Priorität und der Zugriffsmenge wichtig. Ein Dateisystem ist ganz davon abgesehen auch nicht das schnellste.
-
Möchte mich für die Anregungen noch bedanken. Danke.
Grüssli
-
Bei Webseiten wäre ein Nachteil das die Bilder bei jedem Aufruf aus der Datenbank geladen werden müssen. -> Jedes zu ladende Bild muss einen PHP-Prozess durchlaufen.
Dabei dauert jeder PHP Request wesentlich länger.
Gruss Sheldor
-
asc schrieb:
Unix-Tom schrieb:
Eine BLOBTABELLE ist langsam.
Auch hier ist die Frage der Priorität und der Zugriffsmenge wichtig. Ein Dateisystem ist ganz davon abgesehen auch nicht das schnellste.
Ein Dateisystem ist auf genau diesen Fall hin optimiert - deshalb ist es schneller. Eine DB ist auf BLOBs nähmlich kein bisschen hin optimiert - nicht in diesem Rahmen.
Desto größer die DB ist, desto langsamer ist sie. Das ist eine simple Regel. Selbst wenn nur über indizes zugegriffen wird, wird das System etwas langsamer wenn die Datenbankgröße explodiert ist. Und bei Full Table Scans sowieso...
auch tut sich der Server schwer die relevanten Datensätze zu cachen wenn sie so groß sind
Es ist also keine Frage von Dateien: Ja/Nein - sondern Abhängig von der größe der Dateien.
-
Ich halte die Größe der Datenbank für sehr relevant.
Sichere mal ein Monster von > 100 GB. Bei ein Paar GB kein
Problem ...
-
@Shade Of Mine:
Ich glaube nicht dass viele Datenbank-Server BLOBS "in row" abspeichern.Von daher ist es ziemlich egal ob die DB durch BLOBs extrem gross geworden ist, wenn man einen Full-Table-Scan macht. Die BLOBs werden dabei nicht gelesen, die eigentlichen Tabellen (=alle Spalten ausser BLOBs) werden dadurch nicht grösser.
-
Ich betreibe einen mischmasch aus beidem (Desktop Anwendungen). Ich speichere thumbnails in die db (<=500 kb) und die "richtigen" Files in verschiedenen Auflösungen landen auf dem Dateisystem.
Natürlich schaue ich vorher ob ich nicht doch lieber alles auf das Dateisystem lege. Bin kein großer fan von Files in die DB speichern.
-
- schon wieder der falsche knopf .. << löschen bitte ^^ sorry
