Binäre Daten in DB

[albrecht]

Moin,

> Die Frage unsererseits ist halt nur, ob das Sinn macht und was die Nachteile
> sind.

Es _ergibt_ Sinn und es hat erhebliche Nachteile.

- Performance: Wie beschrieben sollte hier sehr genau abgewogen werden, 
wie groß die BLOBs sind, wieviele genutzt werden, wie hoch die 
Änderungsrate (Fragmentierung der DB-Datei) ist etc
- Dateisystem: Wenn kein mySQL mit automatischem RAID verwendet wird, 
stößt man bei Bild-Daten sehr schnell an Filesystem-Begrenzungen
- Sicherheit: Es ist in vielen Setups aufwendiger, wenige SEHR GROßE 
Dateien zu sichern als mehrere kleine, nicht zuletzt, weil die Sicherung 
übers Netz erfolgt und so instabile Lösungen wie NFS verwendet

Eines unserer Bild-DB Systeme nutzt BLOBs für Thumbnails (und nur für 
diese, die MAG-, PREV-, HIRES- und Original-Daten liegen auf 
EMC-Quadraten und HP Jukeboxen). Das hat sich als _sehr_ performant und 
in dem konkreten Setup als deutlich flexibler und flotter herausgestellt 
als 500.000 Thumbnail-Dateien im Filesystem. Daraus eine Pauschalaussage 
abzuleiten wäre aber falsch. Die Argumentation über die Konsistenz ist 
lückenhaft, denn die Verbindung "Dateiname in SQL"-"Datei auf Platte" 
ist ja nur eine von vielen Relationen in einer Bild-DB: Systematiken, 
Gruppierungen, Rechte, Verzeichnisse, temporäre Listen etc verweisen 
alle auf Thumbnails, Bild-Daten etc. Eine grundlegene 
Design-Entscheidung aufgrund eines EINZELNEN Links zu fällen, halte ich 
für verkehrt.

Es kommt hier (leider) auf die tatsächliche Anwendung an... also wieder, 
wie oben: Wie viele Blobs, wie groß, welcher Zugriff, von wie vielen 
Nutzern (Flaschenhals SQL-Interface) etc.

> Ok.. DB wird gross. Das ist klar. Aber kein Argument auf Seiten der
> Programmierung.

Doch, das ist ein Argument, denn Performance und oben angedeutete 
Probleme spielen für den Programmierer immer eine Rolle.

> Die DB benötigt eh einen starken Server für evtl. Lösungen.
> Rechtevergabe, ok.. ansonsten muss halt, wenn erwünscht, noch der Username
> gespeichert werden, wo jeweils immer die Userrechte überprüft werden.

Naja, zu einem Bild-DB System gehört noch ein bisschen mehr. Wir 
entwickeln seit rund acht Jahren Bild-Datenbanken für Verlagshäuser und 
Agenturen, auch auf mySQL Basis - und die Erfahrung zeigt, daß 
schnell-schnell Lösungen sehr schnell-schnell zu Frust führen ;-)

> Jetzt geht es halt um Vor-/Nachteile der Lösung mit richtigen Argumenten.
> Die Lösung soll hinterher evtl. auch auf MySql laufen. Bevorzugt wird von
> uns eher die DB PostGreSql.

PostGRESQL haben wir - zuletzt vor zwei Jahren - getestet und es schied 
sofort wegen der massiven Performance-Nachteile gegenüber mySQL aus. 
Zwar sind wir auch bei mySQL sehr schnell an SEHR große 
Performance-Grenzen gestoßen (die ich hier zu lösen versuchte, ohne 
Ergebnis), aber wenn man die Probleme von mySQL umschifft, sehe ich 
keinen Grund (speziell für Bild-Datenbanken), auf postgresql zu setzen.

Marc Albrecht
A.C.T. / Level-2

-- 
Infos zur Mailingliste, zur Teilnahme und zum An- und Abmelden unter
-->>  http://www.4t2.com/mysql