Expertenrunde: BLOBS als externe Dateien oder in der DB?

[alzaimar]

Hi

Nehmen wir an, ich hab ne Tabelle in einer Datenbank mit einer BLOB-Spalte. Dort drin sind Dateien abgelegt (Bilder, Dokumente, egal), die Größe variiert zwischen 1k und 10MB je Datei.

Es gibt nun zwei Möglichkeiten, das zu realisieren
A) Man kann einfach so lassen, wie sie ist, also den DB-Server die BLOB-Verwaltung überlassen (Auf dem Standpunkt steh ich).
B) Andere Coder meinen nun, es sei 'besser', die Dateien im Fileserver abzulegen und in der DB nur den Dateinamen zu speichern.

Wie würdet ihr die beiden Alternativen hinsichtlich

- Performance
- Sicherheit
- Wartbarkeit

des DBMS bewerten?

Wie würdet ihr so etwas implementieren?

Eure Meinungen würden mich interessieren.


Danke.

[mkinzler]

Ich bevorzuge auch die Verwendung von Blobs. Dafür benötigt aber das DBMS eine richtige BLOB-Unterstützung, damit meine ich das er Blobs nicht als Teil der Tabelle sondern in einem eigenen Tablespace ablegt, was bei Oracle und FB der fall ist. Bei den anderen DBMS weiß ich nicht, wie diese das händeln.

Performance: Bei BLOBS nur gut, wenn Speicherung getrennt von Tabelle
Sicherheit: Alles liegt in der Datenbank, kein Zugriff von außerhalb möglich.
Wartbarkeit: Es reicht die Datenbanken zu kopieren, kein Problem mit Pfaden.

[Codewalker]

Ich teile Deinen Standpunkt. Alleine im Hinblick auf Konsistenz und Sicherheit ist das Speichern der Namen der falsche Ansatz. Du bist dann sehr unflexibel, falls Dateien auf einen anderen Server umziehen und Fehlersuche (z.B. wenn "jemand" ein Verzeichnis umbenennt - man muss ja mit allem rechnen :mrgreen: ) ist deutlich schwieriger. Moderne Datenbanksysteme sind optimiert, mit großen Dateien zu jonglieren. Auf der Arbeit speichern wir Fotos der Mitarbeiter als BLOBs. Damit erreichen wir zwar nicht die 10 MB pro BLOB, aber man vergrößert die Datenbank schon deutlich. Trotzdem kann ich bei der Performance absolut nicht meckern.

[hanspeter]

Zitat:

Zitat von alzaimar

Wie würdet ihr die beiden Alternativen hinsichtlich

Unendliches Thema.
In manchen Bereichen ist die Speicherung als Blob (aus Gründen der Datensicherheit) gesetzlich vorgeschrieben.
Vorteil ist sicherlich das Daten und Information zusammen gehören und so abgespeichert sind.
Manipulationen an dem Datenbestand sind außerhalb der Datenbank nicht möglich.
Was nach meiner Meinung dagegenspricht ist das Aufblähen der Datenbank.
Bei Terrabyte wird die Datensicherung sicherlich auch ein Problem.
Aber auch darunter ist die Datensicherung mit einem File-gestützten System einfacher.
Ich könnte bei dem Datensatz z.B. angeben CD-Nr/ Dateinamen.
Ist die zugehörige Information nicht auffindbar, dann erfolgt die Aufforderung zum Einlegen einer CD.
Ein weiteres Argument für filegestütztes Speichern ist die Möglichkeit mit mehr als einem Datensatz auf das gleiche
Object zu verweisen. (z.B. unterschiedliche Suchkriterien)

Mit Gruß
Peter

[Ghostwalker]

Also..einfach mal eine Aufstellung der Vor-/Nachteile der System so wie ich das sehe (natürlich hinsichtlich der genannten Punkte :) )

Speicherung ausßerhalb des DBMS:

Vorteil:

- Blob-Daten können unabhängig von der DB aktualisiert werden. Ich muß als nicht immer die DB belästigen, wenn
ich z.B. an einem Textdokument etwas ändere.

- Im Falle eines DB-Crashes hab ich immernoch meine Blob-Daten und kann ggf. weiterarbeiten und muß nicht warten
bis die DB wieder zurückgesichert ist.

- Schnellere DB-Bearbeitung, da die Blob-Daten z.B. Bei Suchanfragen nicht mit berücksichtigt und auch nicht
mit übertragen werden müssen.

Nachteile:

- Es kommt zu Inkonsistenzen, da man z.B. ein Dokument löschen kann, ohne den entsprechenden Eintrag in der DB zu
entfernen.

- Die Daten sind nicht durch das DBMS abgesichert. D.h. Jeder der auf den Fileserver Zugriff hat kann an den Daten
rumfummeln.

- Erhöter Wartungsaufwand, da man die Daten konsistent halten muß ("manuell"). Auch müssen die Blob-Daten extra
gesichert werden.

Dementsprechend sind die o.g. Vorteile die Nachteile bei Speicherung in der DB und die Nachteile die Vorteile bei Speicherung in der DB.

Letztendlich würde ich das von Fall zu Fall entscheiden. Viel hängt davon ab, welche Anforderungen für die Bearbeitung gestellt sind, welche Resourcen (Hardware/Software) vorhanden ist, sowie welche Daten den gespeichert
werden sollen und wie sie Verknüpft sind.

[Codewalker]

Zitat:

Zitat von hanspeter

Bei Terrabyte wird die Datensicherung sicherlich auch ein Problem.

Das ist ja eigentlich egal: Ob ich jetzt die DB in Terabyte-Größe sichere oder eine kleine DB und muss dann den FileServer sichern - die zu sichernde Menge bleibt ja fast gleich (DB hat evtl. noch Overhead - aber bei der BLOBgröße eigentlich zu vernachlässigen)

[noidic]

Vor dieser Entscheidung stand ich auch schon einige male und werde auch noch häufiger entscheiden müssen, welchen Weg ich gehe. In den meisten Fällen entscheide ich das zusammen mit unserem DBA und als Faustregel haben wir gesetzt, dass wir auf die Fileserver-Lösung gehen, wenn die Gesamtgröße pro Monat 100MB übersteigt.

Eine generelle Aussage, was besser ist, wird man kaum treffen können, hier mal Vor- und Nachteile der Fileserverlösung (DB-Lösung entsprechend umgekehrt) aus meiner Sicht.

pro:
- Speicherkapazität kann leichter erhöht werden (zumindest nach Aussage unseres DBA)
- Bei Ausfall der Datenbank Zugriff auf die Dateien weiterhin möglich
- Dateien können direkt mit dem Standardprogramm geöffnet oder z.B. als Mailanhang verwendet werden.


kontra:
- Berechtigungen für Fileserver müssen zusätzlich gesetzt werden
- 2 Server, die ausfallen können
- 2 Zugriffsmethoden in der Anwendung nötig, damit mehr Codingaufwand und schlechtere Performance.

Was die Sicherheit angeht sehe ich da keinen Unterschied, wie aus den kontras ersichtlich hat eine Fileserver-Lösung meistens eine schlechtere Performance und ist aufwändiger zu warten.
Ich persönlich bevorzuge die DB-Lösung, aber in einigen Fällen macht Fileserver wohl mehr Sinn.

[hanspeter]

Zitat:

Zitat von Codewalker

Das ist ja eigentlich egal: Ob ich jetzt die DB in Terabyte-Größe sichere oder eine kleine DB und muss dann den FileServer sichern - die zu sichernde Menge bleibt ja fast gleich (DB hat evtl. noch Overhead - aber bei der BLOBgröße eigentlich zu vernachlässigen)

Ich meine nicht ganz.
Bei einem Fileserver kann ich Daten einfacher auf mehrere Medien aufteilen.
z.B. Bilder jahrgangsweise auf eine DVD.
Insbesondere wenn viele Daten gespeichert werden, die nur zu Archivzwecken interessant sind,
ist hier die Auslagerung einfacher.

Eine weitere Möglichkeit wäre für diese Daten eine eigene Datenbank zu verwenden und diese bei Erreichen einer
bestimmten Größe zu archivieren.

Die 4,5 Gbyte einer DVD sind immer noch eine Grenze und das Aufteilen eines Backup auf mehrere Medien ist auch nicht ganz trivial.

Gruß
Peter

[hoika]

Hallo,


Ich hatte mich das eine mal auch zusammen mit dem Admin
der Firma für FileServer entschieden (FB als DB).

Grund war die bessere Speicherung/Archivierung für den Admin.


Mal was anderes zu mkinzler.
TableSpace und FB ?
Seit wann geht das denn ?


Heiko

[mkinzler]

Zitat:

TableSpace und FB ?

War vielleicht die falsche Begrifflichkeit. Aber BLOBS werden in FB, wenn sie eine bestimmte Größe erreichen in einem eigenen Bereich der DB gespeichert und in der Tabelle nur noch einen Verweis auf den Blob

[alzaimar]

Ich hätte nicht gedacht, das wirklich jemand die Fileserver-Möglichkeit implementiert. Aber deshalb hab ich ja gefragt.

Angesichts der hier geposteten Meinungen muss man sagen: :dp:

Wirklich interessant.

Da es sich um Aufträge handelt könnte man bei einer Fileserver-basierten Lösung die Dateien für ältere und abgeschlossene (bezahlte etc.) Aufträge archivieren und in der Datenbank zusätzlich die Backup-Nummer (DVD-Nr etc.) mit ablegen.

Wenn die Backupproblematik nicht wäre, würde ich die BLOB-Version nehmen, eben weil man weniger Sorgen hat. Angesichts der Größe, die bei mehreren GB liegt, müsste man sich aber etwas ausdenken...

[hoika]

Hallo,

ja das stimmt.

Bezüglich Performance hatte übrigens xdancer mal nen Test gemacht
mit einer 2GB-Datei (FB1.5).
Die wurde spürbar langsamer bei vielen Blobs.

Unter Oracle war davon nichts zu spüren
(ohne Partitionierung)


Noch zu der Größe.
Natürlich braucht ein grosse DB sehr viel länger für ein Backup,
als eine kleine, wo die meistens Daten extern vorliegen.
Wenn ein Backup eine Stunde dauert und 2 GB als FBK erzeugt,
die dann noch archiviert werden will,
muss man sich halt was überlegen.

Lösung wäre dann vielleicht ein inkrementelles Backup.


Heiko

[hanspeter]

Zitat:

Zitat von alzaimar

Da es sich um Aufträge handelt könnte man bei einer Fileserver-basierten Lösung die Dateien für ältere und abgeschlossene (bezahlte etc.) Aufträge archivieren und in der Datenbank zusätzlich die Backup-Nummer (DVD-Nr etc.) mit ablegen.

Übrigens habe ich gerade mit einer Lösung zu tun, die genau dieses Problem hat.
Hier erfolgt die Speicherung auf einem Fileserver.
Allerdings wird jede gespeicherte Einzeldatei um einen Header ergänzt. Aus diesem kann man die in der Datenbank gespeicherte Zuordnung bei Bedarf regenerieren.


Gruß
Peter

[mschaefer]

Moin, moin,

Für die reine Speicherung sehe ich keinen wirklichen Nachteil von Blobs, aber auf einem Fileserver können Files auch einen externen Zugriff haben. Zum Beispiel direktes bearbeiten mittels Batchjobs oder direktes öffnen mit zugeordneten Applikationen.

Grüße // Martin

[Jelly]

Ich speichere meine Daten auf einem getrennten Fileserver. Die Dateien werden gezippt, und das ZIP Archiv mit einem Passwort versehen. Schreiben darf jeder in das verzeichnis, lesen auch, aber nicht löschen und nicht ändern. Die ZIP haben eine GUID als Name, so dass über den Namen selbst keine Rückschlüsse gezogen werden können.

Das Zip hat den Vorteil, dass es weniger Platz wegnimmt als ein Blob.

Persönlich bin ich mit der Lösung sehr zufrieden.

[QuickAndDirty]

Also ich würde das nicht als Blob speichern. Habe oft Schwierigketen mit zerstörten Blobs gehabt
wo ich die Aulagerungsdatei für die Blobs löschen muste, weil einer Kaputt war. Wenn darauf nicht verzichtet
werden kann würde ich alle Daten als Lange Strings speichern. Ich habe auch die Erfahrung gemacht das Datenbanken
mit Blobfeldern schwer in eine neue Datenbank zu überführen sind.

[Jelly]

Zitat:

Zitat von QuickAndDirty

Wenn darauf nicht verzichtet
werden kann würde ich alle Daten als Lange Strings speichern.

Das wäre ehrlich gesagt, das letzte was ich machen würde, weil dafür kein eigener Tablespace benutzt wird. D.h. deine Tabelle bläht sich immens auf.

[mkinzler]

Außerdem geht das dann auf die Performance bei Dokumenten bis zu 10MB! wenn das DBMS überhaupt VARCHARs in dieser Größe zulässt.

[QuickAndDirty]

Zitat:

Zitat von Jelly

Zitat:

Zitat von QuickAndDirty

Wenn darauf nicht verzichtet
werden kann würde ich alle Daten als Lange Strings speichern.

Das wäre ehrlich gesagt, das letzte was ich machen würde, weil dafür kein eigener Tablespace benutzt wird. D.h. deine Tabelle bläht sich immens auf.

Dafür scheint es dafür halbwegs einheitliche Standards zu geben. Ich mein Datenbanken verschwinden auch mal von jetzt auf gleich. z.B. Paradox.

[Jelly]

Zitat:

Zitat von QuickAndDirty

Dafür scheint es dafür halbwegs einheitliche Standards zu geben. Ich mein Datenbanken verschwinden auch mal von jetzt auf gleich. z.B. Paradox.

Diese Aussage verstehe ich nicht.
Welche Standards meinst du?

Natürlich muss das DBMS Blobs gescheit unterstützen! Wir reden ja also nicht von Paradox.

[mschaefer]

Mag sein das Paradox lausig wenig SQL konnte und die BDE brauchte, aber mit Blobs kam es gut zurecht und hat diese in Zusatzdateien zur eigentlichen Tabelle gespeichert. In dem Fall ist es sogar recht praktisch gewesen, dass es sich um ein Filebaisertes-System handelt :mrgreen: .

Grüße // Martin

[Dax]

Dateien, die nur mit der DB verknüpft sind und nirgendwo sonst gebraucht werden, würde ich definitiv in ein BLOB-Feld packen. Zumindest bei Postgres (das DBMS meiner Wahl) ist die BLOB-Unterstützung sehr gut geregelt: alle Daten, die eine gewisse Größe überschreiten - und dazu zählen auch lange TEXT-Felder - kommen eine eigene Tabelle, die die Daten enthält, und in der "echten" Tabelle stehen lediglich Referenzen.

Wird die Datei außerhalb der DB-App gebraucht und selten bis nie aktualisiert, würde ich weiterhin Blobs verwenden und die Datei für externe Zugriffe auf einem Fileserver cachen. Je öfter die Datei aktualisiert werden müsste, desto eher würde ich von den Blobs abrücken und in Richtung DBMS - getrennter Fileserver gehen...