Obergrenze bei MySQL-Datenbanken für Bilder

Tundra

Tundra

Aktives Mitglied
Thread Starter
Dabei seit
20.12.2006
Beiträge
1.064
Reaktionspunkte
48
Hi,

ich möchte eine Bilder-Datenbank mit MySQL Community für ein Grafikstudio erstellen.
Jedes Jahr wird die Datenmenge um 3-5 GB vermutlich steigen.

Wo liegt eine vernünftige Obergrenze für die Datenbank, um nicht in Schwierigkeiten zu kommen (Performance, zerschießen, etc.)?

Soll ich lieber InnoDB oder MyISAM benutzen? Ich habe jetzt einiges zu den beiden Typen gelesen und bin jetzt etwas verwirrt?
Die Datenbank wird auf einen Mac laufen. Es gibt vor Ort keinen Datenbankadministrator, daher nützen auch irgendwelche Transaktionsprotokolle oder ähnliches nichts. Die Datenbank soll dann vermutlich jeden Tag gesichert werden, notfalls wird die Datenbank wieder mit mysqldumper hergestellt, falls er überhaupt das in dieser Größenordnung kann. Oder könnt Ihr mir andere Tools dafür vorschlagen.
Wie gesagt, vor Ort muss die Datenbank umproblematisch laufen und notfalls wieder hergestellt werden können.

Grüße und Danke
Guido
 
Je nach Zugriff würde ich evt. sogar auf PostgreSQL ausweichen.

Nach ERfahrung (habe mal im Intranet eine Bilddatenbank erstellt mit Mysql) war bei einer Datenmenge von ca. 1 GB und 3 Benutzern gleichzeitig schluß. mysqldump sollte zwar mit großen Datenbeständen kein Problem haben, allerdings kann es beim Rückspielen evt. schwierigkeiten geben.
Desweiteren solltest Du, falls es performant sein sollte, auf folgende Methode ausweichen.

a) Bilderpfad anlegen
b) Bilder beim hochladen/ablegen mit einer Indexnummer versehen
c) in die DB die Indexnummer und Pfad speichern
d) bei Zugriff die DB auf die PFadabfrage beschränken und das Bild dann über den Pfad einbinden
 
Genau, beachte Nachtschatten's Tipps. Bilder in einer DB haben immer als Folge, dass die DB sehr langsam wird mit der Zeit.
 
Danke für die schnelle Anwort. Mit PostgreSQL habe ich leider keine Erfahrung.
Mit MySQL habe ich schon viel umgesetzt, aber nichts in der Datenmenge.

Dann werde ich mich wohl eher am Dateisystem halten.
Danke für die Tipps dazu.
 
Noch zu der Sachen MyISAM oder InnoDB:

Bei InnoDb kannst du Fremdschlüssel anwenden (foreign keys auf englisch), bei MyISAM ist das nicht möglich. InnoDB brauch aber glaub ich ein bisschen mehr Speicherplatz. Wieviel das weiss ich jetzt jedoch nicht so genau, habe noch nie mit Datenmengen gearbeitet dass das wichtig geworden wäre.
 
Richtig, habe ich auch gelesen InnoDB soll schneller sein, braucht aber mehr Plattenplatz. Zahlen dazu habe ich nicht gefunden.
Bislang war ich mit MyISAM sehr zufrieden gewesen, auch ein Join hat immer problemlos funktioniert.
 
JOIN's sind ja auch ein Teil des normalen Befehlssatzes von SQL :)

Fremdschlüssel sind keine Befehle. Die werden dazu genutzt um eine Tabelle mit anderen zu verbinden. z.B. wenn du eine Tabelle hast mit Fotos, welche gekennzeichent sind durch eine unique foto_id, kanns du in der Tabelle der Kommentare die foto_id als foreign key angeben, und ausserdem dann noch was passiert wenn ein Foto aus der Tabelle gelöscht wird. z.B. können dann automatisch alle dazugehörigen Kommentare mit gelöscht werden. Ohne dass man sich selbst darum kümmern muss später.

Das ist das Prinzip von Foreign keys.
 
Danke für die Erklärung, ich wußte noch was mit fremden Tabellen, aber ich habe es nicht mehr auf die Reihe bekommen.
 
Ganz wichtig ist das Fazit, das große BLOBs wie Bilder nichts in einer DB zu suchen haben! Das wird schlicht unperformant. Die performanteste DB für Dateien ist nach wie vor ein Dateisystem. Also Pfad zur Datei und Meta-Daten in die DB, den Rest ins' Filesystem!
 
Kommt auf die Datenbank an.

Gute SQL-DBs legen bei BLOBs lediglich die Adresse des Blobs in der DB ab und nicht mehr, übrigens analog zu varchar Feldern. Probleme bereiten zumeist die lange Verwendung einer Connection - also einen grossen Pool verwenden.

Und, bei Webanwendungen, niemals direkt das BLOB in die Response schreiben!

Ich werwalte grosse Datenmengen mit FrontBase und darin befinden sich Bilder, PDFs etc. Bisher ohne keine Performance-Probleme.

Gegen eine Ablage im Filesystem spricht, dass der Pfad nicht verändert werden darf. Kann man natürlich mit relativen Pfaden lösen, finde ich aber stressig und natürlich ist die Sicherung erheblich aufwendiger.
 
gishmo schrieb:
Gute SQL-DBs legen bei BLOBs lediglich die Adresse des Blobs in der DB ab
Zum Vergrößern anklicken....

hier ist aber die Rede von mysql!

gishmo schrieb:
Bisher ohne keine Performance-Probleme
Zum Vergrößern anklicken....

der war hübsch :D , verstehe aber nat. was Du meinst.

gishmo schrieb:
Gegen eine Ablage im Filesystem spricht, dass der Pfad nicht verändert werden darf.
Zum Vergrößern anklicken....

Naja - es muß nat. klar sein das der Teil des Filesystemes der Anwendung/ der DB gehört. Manuelle Änderungen sind dort unzulässig. Da DB's meist auch ins Filesystem gedumpt werden sehe ich dort keinen Nachteil, man kann beides zeitgleich sichern und muß es nat. auch!

gishmo schrieb:
Gute SQL-DBs legen bei BLOBs lediglich die Adresse des Blobs in der DB ab
Zum Vergrößern anklicken....

MS SQL 2000 tut das glaub ich nicht!? Tut postgres das?
 
"ohne keine" ... einfach zu früh <= 3 Tassen Kaffee ... :)

Unter uns, mysql ist für mich keine Datenbank .. ;-) ist ganz nett, aber für performante und sichere Businessanwendungen nicht akzeptabel. Im Mac-Bereich gibt es mit FrontBase eine sehr gute SQL-DB mit einem guten Manager, sehr gut skalierbar, mit Volltextsuche und der Möglichkeit zu clustern. Einfach mal anschauen -> www.frontbase.com. Übrigens auch kostenfrei ... einzig der Support ist kostenpflichtig, hab ich aber bis data nicht gebraucht. Und da selbst Apple mit Frontbase arbeitet, kann Frontbase nicht sooo schlecht sein.

MS SQL 2000 ist zwar ganz nett, aber freiwillig einen Windows Server zu betreiben ... och noe ... muss nicht sein. :)

Mit PostGres hab ich noch nicht gearbeitet.

Ich habe in der Vergangenheit bei dem einem oder anderen Projekt BLOBs im FileSystem abgelegt, was aber immer wieder zu Problemen geführt hat. Angefangen von verbogenen Rechten, Verschiebungen, etc.
 
Datencontainer ... sehr gute Bezeichnung. Werde ich übernehmen ... ;-)

Nicht abschrecken lassen, dass man vor dem Download ein Kundenkonto anlegen soll, bzw, dass der download der Licence unter BUY liegt. Kostet definitiv nix ... :)

Nach dem ich Frontbase gefunden hatte, gab es keinen Grund mehr weiter zu suchen.

So, jetzt brauch ich erst mal wieder einen Kaffee ... :)
 
Zuletzt bearbeitet:
Ich habe mir jetzt mal FrontBase heruntergeladen.
Wie hast Du Dich in Frontbase eingearbeitet, Tabellen erzeugt und mit php darauf zugegriffen?
 
Johnyg schrieb:
Noch zu der Sachen MyISAM oder InnoDB:

Bei InnoDb kannst du Fremdschlüssel anwenden (foreign keys auf englisch), bei MyISAM ist das nicht möglich. InnoDB brauch aber glaub ich ein bisschen mehr Speicherplatz. Wieviel das weiss ich jetzt jedoch nicht so genau, habe noch nie mit Datenmengen gearbeitet dass das wichtig geworden wäre.
Zum Vergrößern anklicken....

V.a. unterstützt InnoDB Transaktionen, was meines Wissens MyISAM nicht kann...oder hab ich das falsch im Kopf?
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben Unten