Bildergalerie: Datenbank- oder Dateibasierend

Hallo zusammen!

Ich möchte eine Online-Bildergalerie auf Basis der neuen MS-Technologie Silverlight umsetzen.
Die ersten Anforderungen stehen fest, doch bevor ich erste nähere Planungen beginnen kann, muss die Frage geklärt werden, ob die Bilder in einer Datenbank oder in einer Datei (XML) abgelegt werden sollen.
Dazu wollte ich gerne mal eure Meinung hören. Habt ihr bereits mit einer der beiden angesprochenen Möglichkeiten Erfahrungen gesammelt? Habt ihr gar andere Umsetzungsmöglichkeiten?

Hallo msycho,

ein nettes Thema. wäre auch interessant für mich zu hören was die anderen dazu sagen.
Hier ein Link wie man Bilder in der DB speichert. Klick mich

Wenn du dir die Datenabnk aussuchen kannst würd ich mal beim sql 2008 server gucken ... der bietet irgendwie die möglichkeit so große datenmengen sehr gut zu verwalten ... hab nur leider vergessen wie man das thema nennt...

Gruß
Michael

Hallo msycho,

Du kannst die Bilder in der Datenbank speichern :

Vorteile :

• Bilder werden bei Backup mitgesichert
• Es kann niemand (der Zugriff auf den Rechner hat) von extern auf die Bilder zugreifen oder diese manipulieren.
• Du kannst die Rechteverwaltung vom SQL-Server auch für die Bilder verwenden.
• Du kannst Daten und Bilder replizieren

Nachteile :

• Die Datenbank bläht sich schnell auf.
• Eine große Datenbank wird unhandlich

Oder Du kannst in der Datenbank nur den Namen bzw. Namen und Pfad des Bildes speichern und die Bilder in einem oder mehreren Verzeichnissen.

Microsoft hat das Problem erkannt und bietet im SQL Server 2008 eine Option die die Vorteile von beiden Systemen verbindet. Hab den Namen aber auch vergessen.

Ich würde den Namen und Pfad in der Datenbank speichern.

XML ist für große Datenmengen nicht geeignet.

Grüße Bernd

Der gesuchte Name ist: FILESTREAM

FILESTREAM ist ein neuer Datetyp, welcher die Daten auf das NTFS Dateisystem ablagert. In der Spalte selber steht nur eine GUID drin.

Vorteil daran ist, das die DB wesentlich kleiner bleibt. Beim Backup der DB werden dann auch die Teile des NTFS mit gesichert und beim Wiederherstellen mit entpackt. Das unabhängig vom System.

Ist auf jeden Fall ein Blick wert.

Geile Sache das ...... 😁
Mal was googeln .....

wenns datenbankunabhängig bleiben soll: Bilder auf jeden Fall ins Dateisystem. Datenbanken werden ziemlich langsam, wenn große Mengen Binärdaten darin abgelegt werden. Wir haben bei uns ein DMS (Celum Imagine, wen's interessiert) im Einsatz, das als DB einen MySQL-Server nutzt. Anfangs waren die Bilddaten in der Datenbank, bei einer Datenbankgröße von knapp 10 GB hat das Teil schon ziemlich geächzt. Mit dem (leider optionalen) Filesystem-Modul kann man die Bilddaten aufs Dateisystem auslagern, was einen extremen Performanceboost gebracht hat. Von daher: Metadaten in die Datenbank, Bilddaten aufs Dateisystem.

Und genau darum gehts beim Filestream Datentyp.
Wieso die Datenbank großartig langsamer sein soll ob da jetzt 10gb Binärdaten drin sind oder nicht ist mir auch nicht klar.

Wieso die Datenbank großartig langsamer sein soll ob da jetzt 10gb Binärdaten drin sind oder nicht ist mir auch nicht klar.

Je größer die Datenbank, desto langsamer: basta! 😉

Das hat sehr viele Faktoren. Gerade bei einem MS SQL-Server.
Zum einen liegt es an der Speicherposition. Es werden für Tabellen Speicherplätze vorreserviert um auf der/den Platten die Daten schneller lesen zu können.
Wird der Speicherplatz überstiegen, werden die Daten umgeschichtet, ect.

Desweiteren führt so ein SQL Server Statistiken, die den Zugriff beschleunigen sollen.
Das kann natürlich (gerade bei Dateien) zum Gegenteil ausarten.

Hat man nur eine Indexierung in der Datenbank und die Dateien auf der Platte, sollten nicht so viele Nebentätigkeiten ausgeführt werden.

Und genau darum gehts beim Filestream Datentyp.
Wieso die Datenbank großartig langsamer sein soll ob da jetzt 10gb Binärdaten drin sind oder nicht ist mir auch nicht klar.

anscheinend greift das Caching da nicht mehr. MS warnt aber selber davor, zu viele und zu große binäre Daten in seinen SQL-Servern abzulegen. Für Sharepoint gibt es da zwar keine fertige Lösung (auch der FileStream wird da bisher nicht unterstützt), aber ein Interface für einen externen Storageprovider.

Naja dann legt man die Binärdaten eben in ne extra Tabelle und holt die bei bedarf über ein join mit.

Binärdaten sollte man eh immer in separate Tabellen auslagern. Im besten Fall sieht so eine Tabelle einfach so aus

ID INT
Data VARBINARY(MAX)

Und gut ist. Vielleicht noch eine Spalte die Aussagt, um was für Daten es sich eigentlich handelt. Mehr aber auch nicht. Dann gibt es auch keinerlei Probleme mit der Größe der Datenbank.

Naja dann legt man die Binärdaten eben in ne extra Tabelle und holt die bei bedarf über ein join mit.

auch suboptimal. SQL-Datenbanken sind generell einfach nicht dazu gedacht, große binäre Datenmengen zu handhaben. Die dafür nötige IO-Leistung geht auf die Performance, der Cache wird belastet und generell ist die Geschwindigkeit ein Witz, da diese Blobs halt keine feste Größe haben und der Server für jeden Datensatz in der Tabelle rumspringen muss. Lad mal spasseshalber ein paar 20 MB-Elemente (in Mediendatenbanken landen ja meist die HQ-Dateien, die dann bei Bedarf ins gewünschte Format runtergerendert werden) vom Dateisystem und vom SQL-Server und schau dir an, was schneller ist. Das Dateisystem kann mehr oder weniger die volle Leistung des Plattensubsystems abrufen, der SQL-Server sucht erstmal den Datensatz und fängt dann an, den Blob-Inhalt zu suchen und nachzuladen. Und Mediendatenbanken haben neben den großen Bildern auch die Thumbs irgendwo abgelegt, um in Verzeichnissen eine Vorschau anzubieten. Die müssen dann zwangsweise in größeren Paketen runtergeladen werden. Auch jeweils "nur" 5-10 kb pro Thumb, das sind im Vergleich zu "normalen" Datenzeilen aber trotzdem ganz ordentliche Datenmengen. Und bei einer Anzeige von 20 Thumbs auf einer Seite müssen nur ein paar Anwender parallel ein bisschen rumblättern, um den Server ganz ordentlich ins Schwitzen zu bringen.

Nebenbei gehts bei sowas ja meist auch nicht um das Laden eines einzelnen Elements. Belaste so ein System mal etwas stärker, am besten mit Batchkonvertierung mehrerer Images oder als Webserver-Backend. Der Server geht bei vielen Anfragen derart in die Knie, das muss man sich nicht antun.

Hallo zusammen

Ich würde in fast jedem Fall die Lösung mit dem Dateisystem bevorzugen, siehe auch:

• http://www.karsan.de/ASPNETBilderInDieDatenbankOderInsDateisystem.aspx

Zum schreiben und lesen von grossen Dateien (ASP.NET, aber sicherlich auch sonst relevant):

• http://www.aspnetzone.de/blogs/juergengutsch/archive/2008/11/22/gro-e-dateien-in-hochladen-und-in-eine-datenbank-schreiben.aspx
• http://www.aspnetzone.de/blogs/juergengutsch/archive/2008/11/22/gro-e-dateien-aus-einer-datenbank-lesen-und-zum-download-bereitstellen.aspx

Gruss Peter

Interessant, dass es keine Lösung à la "best practice" gibt.
Ich muss in diesem Zusammenhang immer wieder lesen, dass die Datenbank ab einer größeren Datenmenge und einer hohen Zugriffszahl in die Knie geht. Doch was heißt "größere Datenmenge" und "hohe Zugriffszahl"? Speziell in meinem Fall spreche ich von ca. 15.000 Bildern. Wobei ein Routine beim "Hochladen" zu greifen beginnt, die das einzelne Bild a) verkleinert (800x600px und Qualitätsminderung auf 80%) und b) ein Thumbnail erstellt. Die Anzahl der Unique Users liegt im Durchschnitt bei ca. 100 Besuchern (es handelt sich um eine "private" Seite).

Hier auch mal ein (kleines) Beispiel wo Grafiken bzw. dessen Speicherort und Name in einer XML abgelegt sind. Es handelt sich zwar um wesentlich weniger Bilder (und auf DeepZoom verzichte ich in dem Fall sowieso), aber letztlich ist es meiner Bildergalerie schon ähnlich.

OODB Erfahrungen - Think outside the Grid!

Mein Senf, ich kann das so nicht stehen lassen:

Je größer die Datenbank, desto langsamer: basta! 😉

Gerate Relationale Datenbanksystem können auch riesige Menge an Daten speichern. Und die Speicherung von BLOB's läßt die Performance auf keinen Fall einbrechen.

Sollte dies so sein, ist nicht das Datenbanksystem schwach, sondern der Datenbankdesigner hat das Konzept der Relationalen Datenbank nicht verstanden.

Ich kann trotz knapp 30.000 Bilder/Datenblätter in dem Katalog, den wir zu unserer Anwendung keine Performanceverluste (mal vom längeren Backup) feststellen. Denn BLOB's liegen auf separaten Seiten, die die von der Abfrage erst berührt werden, wenn die Daten benötigt werden.

Das hat sehr viele Faktoren. Gerade bei einem MS SQL-Server.
Zum einen liegt es an der Speicherposition. Es werden für Tabellen Speicherplätze vorreserviert um auf der/den Platten die Daten schneller lesen zu können.
Wird der Speicherplatz überstiegen, werden die Daten umgeschichtet, ect.

Seit wann werden Daten umgeschichtet? Eine Datenbank wird physisch in Segmente unterteilt, wo ein einzelnes Segment auf der Platte liegt, kann heutzutage sowieso keine Anwendung mehr beeinflussen. Die Zugriffsposition hängt ebenfalls von zu vielen Faktoren der Festplatte hab, das sich darum auch kein DB-Entwickler mehr Gedanken macht. Eher versucht man die Segmente so weit wie möglich zu verteilen.

Desweiteren führt so ein SQL Server Statistiken, die den Zugriff beschleunigen sollen.
Das kann natürlich (gerade bei Dateien) zum Gegenteil ausarten.

Was haben Zugriffsstatistiken mit BLOBs zu tun? Wieso sollen Sie diese negativ beeinflussen?

Hat man nur eine Indexierung in der Datenbank und die Dateien auf der Platte, sollten nicht so viele Nebentätigkeiten ausgeführt werden.

Indexe erhöhen die Abfrageperformance, vermintern aber die Upsert-Performance. Was das schon wieder mit Blobs zu tun hat möchte ich ebenfalls wissen?
Zweitens seit dem SQL 2005 sind Indizes nicht mehr so eine Belastung für die Datenbank bei Upserts.

anscheinend greift das Caching da nicht mehr. MS warnt aber selber davor, zu viele und zu große binäre Daten in seinen SQL-Servern abzulegen.

Das Caching hat nicht mit großen Datenbanken zu tun. Denn meist werden nur Datenseiten, selten BLOB-Seiten gecacht.
Definition Größe und Verwendung seitens MS: MSDN

Binärdaten sollte man eh immer in separate Tabellen auslagern.

Es gab Zeiten, da war dieses vorgehen sinnvoll. Z.b. beim iAnywhere kleiner Version 9. Aber bei modernen DBMS ist es völlig irrelevant.