Bilderarchiv in Sql-Datenbank

[fOV]

Hi,

SQL2005/2008 bietet die Möglichkeit, Bilder als Binary Large Objects (BLOB) in einer Datenbank abzulegen.
Dies bietet u.a. den Vorteil, dass es keine verwaisten Bilder mehr geben sollte, da die entsprechenden Referenzen mit in der Datenbanktabelle enthalten sind. Des weiteren ist das Handling einfacher, wenn die Bilder von einem System zum nächsten weitergereicht werden sollen. Schließlich und endlich, sollen die Bilder auf einem Webserver zur Verfügung gestellt werden.
Plattenplatz sollte kein Thema sein, so dass die DB ruhig ein paar TB groß werden kann.
Performance ist ebenfalls gewährleistet.

Hat jemand Erfahrung im Bereich MSSql und Blobs gesammelt und kann ein paar Nachteile nennen ?

 

[Gast_129296]

Frage ist erstmal, was der Vorteil sein soll, Schlagwörter etc kannst Du ja auch jetzt im Bild speichern.
Das verwaisen muss man vermeiden, indem man nur strikt über das User Interface löscht.

Weiterer Nachteil, eine DB erfordert immer gewissen administrativen Aufwand, hier kommen gg noch Lizenzkosten hinzu und wenn das ganze im Web sein soll musst Du vermutlich gleich zumindest einen virtuellen Server anmieten.

Da ist eine Lösung, die auf Tools aufsetzt, die auch so mit Webspace zu haben sind eventuell günstiger ( z.B. Gallery mit mySQL und PHP ).

Umzug ist bei MS SQL natürlich insofern ein Problem, als Du auf Windows festgenagelt bist.

BLOBS sowie Tabellen mit BLOBS sind zumindest bei Oracle einigen Beschränkungen ausgesetzt, die die Verwendung dieses Types schwiereig machen ( Import / Export , suchen, Replikation etc )

 

[Gast_108416]

Ich würde nie Binärdateien in eine DB schreiben, wenn es nicht sein muss. Wird die DB korrupt, sind die Bilder weg. Ich verwende Imabas - das funktioniert super.

 

[fOV]

der Vorteil würde darin bestehen, dass 1:n Beziehungen von Bildern zu einem Schlagwort, oder überhaupt Beziehungen innerhalb der Datenbank ablaufen würden.
Um dieses Archiv herum ist/wäre eine "MSSQL-Welt". Lizenzkosten sind erst einmal egal und eine eigene virtuelle Maschine steht ebenfalls schon im Netz.

Könnte es Performanceprobleme geben, wenn die DB mal 10,20 oder 100TB große ist ? Sauber gesetzte Indizies mal vorausgesetzt.

Import/Export ist bei MSSQL ziemlich simpel. Das Quellverzeichnis würde über einen Cursor ausgelesen und die Bilder nebst Informationen in die DB verfrachtet.
Schlagworte wären im Bildnamen enthalten.

 

[fOV]

Wird die DB korrupt, sind die Bilder weg.

Full-Backup lautet das Zauberwort.
Imabas sagt mir (bisher) noch nichts. Mal Tante Google bemühen.

 

[BadBoogeyMan]

der Vorteil würde darin bestehen, dass 1:n Beziehungen von Bildern zu einem Schlagwort, oder überhaupt Beziehungen innerhalb der Datenbank ablaufen würden.

Und warum sollte man deswegen gleich die kompletten Bilder mit in die DB packen wollen?
Du kannst auch die Bilder im Original in irgendeinem Verzeichnis aufbewahren und nur den Dateinamen/Pfad abspeichern. Das reicht vollkommen aus, um die Beziehungen zu verwalten.

 

[Gast_108416]

Full-Backup lautet das Zauberwort.
Imabas sagt mir (bisher) noch nichts. Mal Tante Google bemühen.

Aber aus einem Full-Backup eine Datei, weil es schnell gehen muss, zu retten, ist fragwürdig.

Ich sichere auf zwei externe Platten alle meine Bilder. Mein Imabas-Dump ist 22 MB groß (bei ganz knapp unter 50000 Bildern).

 

[Krysztof]

auf die idee, bilder in die db zu schreiben, würde man heute wohl ohne not nicht kommen. keine ahnung, was deine seite machen soll. am ende wohl bilder anzeigen. und die willst du dann immer erstmal aus der db auslesen? auch beim browsen? dann fängt man ganz schnell an, sich wieder einen schönen großen cache zu schaffen, damit das nicht zu lahm wird... außer die verweisten bilder kenne ich keinen grund dafür (und da darf man halt einfach ordentlich programmieren).

 

[talpi]

Ich sehe das auch so, Blobs bindet man sich (und der DB) nur ans Bein wenn es sonst noch häßlicher wird. Binärdateien sind im FS eigentlich immer besser aufgehoben, es sei denn Historisierung ist ein Thema.

Dem Problem verwaister Dateien würde ich andersherum entgegentreten.

Also in der DB eine Tabelle Bild mit Link und Metainformationenen speichern und sich einen kleinen Batchjob schreiben der regelmäßig läuft und einem die Leichen reported. Da es sich um ein Serversystem handelt sollte der Fall das da jemand von Hand Bilder löscht eher selten sein..

 

[fOV]

I...Blobs bindet man sich (und der DB) nur ans Bein wenn es sonst noch häßlicher wird. ....

bei der Abwägung der Vor- und Nachteile geht die Tendenz momentan immer noch Richtung Blob.
Schaun wir mal wie lange

 

[CarstenK.]

Ich kann dir auch nur von den Blobs abraten, generell würde ich auch immer raten die Originaldateien nicht anzutasten.

Ich weiß zwar nicht von welchen Datenmengen wir da reden, aber wir haben mehrere Grosskunden, die > 100.000 Bilddaten/Videos ( in ihren/unseren Webdatenbanken haben. Wenn ich die Datenmengen alle in die DB schreiben würde hätte ich noch ganz andere Sorgen.

Einfach eine Tabelle für die Objekte anlegen, die ID aus der DB nehmen und Hexadezimal umrechnen, sodass maximal 256 Dateien jeweils in einen Ordner kommen.

Bsp.
ID 123342 = 1e1ce
Pfad der Datei im Dateisystem /00/00/01/e1/ce

Auch so kannst du 1:n Beziehungen aufbauen und wirst von der Geschwindigkeit und Handling immer einen Vorteil haben.

Wir jemand anderes gerade schon sagte, wenn du alles über dein Programm laufen läßt, hast du auch keine Schwierigkeiten mit verweisten Bilddaten.

Wenn z.B. die Storage voll ist, kannst du z.B. ganz einfach auf einer anderen weiterarbeiten. Bei DBs geht sowas auch, ist aber deutlich komplizierter.

Ich kenne wirklich einige MAM-Systeme im Enterprisebereich, wovon keines die Bilddaten in der DB speichert.

Wenn du ein modulares, professionelles System in dem Bereich suchst, kannst du dich auch gerne bei mir per PM melden!

Edit: Alleine das ausliefern der Bilder aus der DB und Darstellung im Browser wird ein vielfaches an Performance benötigen.
Wenn es nur wenige User sind ist das überhaupt kein Problem, sollten es doch einige zeitgleich sein, so würde ich es auf keinen Fall so machen.

 

[talpi]

Ich kann dir auch nur von den Blobs abraten, generell würde ich auch immer raten die Originaldateien nicht anzutasten.

Seh ich auch so, gerade bei was Selbstgebautem, besteht immer das Risiko eines sehr unangenehmen (weil z.B. schleichend und nicht sofort bemerkten) Datenverlustes.

Einfach eine Tabelle für die Objekte anlegen, die ID aus der DB nehmen und Hexadezimal umrechnen, sodass maximal 256 Dateien jeweils in einen Ordner kommen.

Bsp.
ID 123342 = 1e1ce
Pfad der Datei im Dateisystem /00/00/01/e1/ce

Auch wenn wir jetzt vom Hölzchen aufs Stöckchen kommen.

Man kann darüber diskutieren, ob ein technischer Schlüssel (du meintest doch den PK aus der Datenbank oder?) zur Indizierung von Objekten ausserhalb einer DB sinnvoll ist. Sieht man oft und manchmal bringt es auch Vorteile, aber hier denke ich nicht.
Der Performanceverlust für einen explizit gespeicherten Pfad dürfte praktisch nicht vorhanden sein und man ist frei in der Strukturierung (interessant für eine Fallbacksituation) und hat keine Probleme bei einer zukünftigen Migration (auf eine andere DB z.B.).


Waren bei mir zwar andere Themengebiete, aber ich hab mit Blobs auch nur Ärger gehabt bis jetzt. Es ist einfach ein Konzeptbruch, die eigentlichen Vorteile der DB hat man nicht, dafür die Nachteile. Für Binärdateien ist das Dateisystem da (das ist sein Job), für Metadaten ist die DB der richtige Ort.
Wenn ich daran denke wie ich allein schon Probleme mit der (De-)Serialsierung der Daten erlebt habe.

 

[CarstenK.]

Auch wenn wir jetzt vom Hölzchen aufs Stöckchen kommen.

Da hast du wohl recht ;o)
Aber ich denke ein paar Vorschläge/Ideen helfen vielleicht doch den TO umzustimmen alles in der DB zu speichern

Man kann darüber diskutieren, ob ein technischer Schlüssel (du meintest doch den PK aus der Datenbank oder?) zur Indizierung von Objekten ausserhalb einer DB sinnvoll ist. Sieht man oft und manchmal bringt es auch Vorteile, aber hier denke ich nicht.

Ja, genau den Primary Key.

Der Performanceverlust für einen explizit gespeicherten Pfad dürfte praktisch nicht vorhanden sein und man ist frei in der Strukturierung (interessant für eine Fallbacksituation) und hat keine Probleme bei einer zukünftigen Migration (auf eine andere DB z.B.).

Bzgl. Performance gebe ich dir absolut recht, das wird nichts zur Sache tun.
Bei uns ist das mit den 256 Dateien/Verzeichnis gewachsen, da damals (noch unter Windows) der Zugriff irgendwann deutlich langsamer wurde, wenn unendlich viele Files im Ordner lagen.

Ausserdem läuft bei uns halt auch Kundenseitig alles über den Primary Key, der halt auch zwangsläufig die eindeutige Objektid ist. Ich brauch mir so auch keine Sorgen wegen doppelten Dateinamen usw. in einem Verzeichnis machen, da ich einfach alles hexadezimal ablege und auf Abruf mit dem Originalnamen die Datei an den Client ausliefere.

Wenn die DB natürlich tot ist hat man verloren, aber dafür gibts ja ne vernünftige Backupstrategie.

Für Binärdateien ist das Dateisystem da (das ist sein Job), für Metadaten ist die DB der richtige Ort.

Das sehe ich auch so, ansonsten kannst du beim ausliefern die Dateien immer noch um Metadaten/IPTC anreichern und so lange die Dateien unverändert lassen.

Warum hat talpi ja schon geschrieben.

...besteht immer das Risiko eines sehr unangenehmen (weil z.B. schleichend und nicht sofort bemerkten) Datenverlustes.

@TO
Handelt es sich eigentlich endgültig um eine Webapplikation?
Falls ja, in welcher Sprache? (interesse halber)