Datei in MySQL speichern oder auf der Festplatte!

[TriphunEM]

Ich mach jetzt gerade ein XML-Import. In der XML kommen auch Bilder und PDFs vor die base64 kodiert sind.

Jetzt überleg ich, speicher ich die Datei auf der Festplatte und trag in der DB den Dateinamen ein, oder speicher ich die Daten direkt in der DB.

Am liebsten würde ich die Dateien in der DB ablegen, aber ich hab ein schlechtes gefühl wegen den abfragedauer und der performance der DB, wenn ich solche große Daten in der DB ablege.

Oder könnt ihr mir tipps geben wie ich Dateien in einer DB speichern kann, ohne die Performance und Abfragedauer zu schwächen???

Ich zieh deshalb die DB-variante vor, da der Import weitgehenst dynmamisch sein soll, und ich nicht immer weiß welcher XML-Tag nur ein String ist oder einen Dateiinhalt beinhaltet.

[wahsaga]

Grössere Binärdateien gehören im Normalfall nicht in die DB, die sind im Dateisystem besser aufgehoben.

Ein Argument für die Ablage von Dateien in der DB wäre einfache(re) Durchsuchbarkeit - fällt bei Binärdateien (Bilder, Musik, Videos) natürlich eher unter den Tisch; bei XML hingegen könnte das schon relevant sein.

Ich zieh deshalb die DB-variante vor, da [...] ich nicht immer weiß welcher XML-Tag nur ein String ist oder einen Dateiinhalt beinhaltet.

Das muss sich doch aber irgendwie ermitteln lassen? Daten, deren Bedeutung unbekannt ist, sind doch eher unbrauchbar.


Das XML in die DB legen, und den base64-kodierten Kram aber extrahieren und ins Dateisystem verfrachten, wäre eine Möglichkeit, das ganze performanter zu halten. Natürlich beim Import etwas aufwendiger, aber auf Dauer beim Auslesen vermutlich besser (kommt natürlich im Einzelfalle darauf an, was mit den Daten anschliessend gemacht werden soll).

[TriphunEM]

Danke! Denke auch das ich es so machen werden. Das Problem ist, dass ich mein import so dynamisch halten will wie es geht, ohne groß feste regeln hard zu coden. Das problem ich erkenn nicht im XML wenn ein tag binärcode ht, und könnte diesen dann als file speichern. der binärcode ist base64 kodiert und das problem ist, dass es keine möglichkeit gibt eindeutig base64 kodierten code zu erkennen...das wäre wesentlich einfacher für mich!

[AmicaNoctis]

Du könntest die base64-codierten Daten auch als Data URI schreiben. Dann hast du erstens zusätzliche Merkmale, um es mit Regex zu prüfen und zweitens kannst du gleich den Content-Type noch mit ablegen. Wenn du ganz auf Nummer sicher gehen musst, könntest du mehrstufige Prüfungen machen, z. B.

1. Prüfen, ob "data:" am Anfang steht => false: kein binary
2. Regex prüfen "!^data:[a-z]+/[a-z0-9+-]+;base64,!i" => false: kein binary
3. Base64 decodieren => false: kein binary
4. decodiertes Base64 mit FInfo->buffer() auf richtigen Content-Type prüfen

[combie]

Ein Argument für die Ablage von Dateien in der DB wäre einfache(re) Durchsuchbarkeit -

Das wichtigste pro Argument ist meines bescheidenen Erachtens nach die referenzielle Integrität der Daten. Seit InnoDB kein Problem mehr.
Z.B. nur 1 Datensicherung und nicht MySQL Daten und Dateien getrennt.
Irgendwelche Performance Probleme lassen sich durch cachen mildern.

Allerdings bieten normale Webspaces nicht immer die Möglichkeiten mit so riesigen Datensicherungen umzugehen.

[Lennynero]

Das wichtigste pro Argument ist meines bescheidenen Erachtens nach die referenzielle Integrität der Daten. Seit InnoDB kein Problem mehr.
Z.B. nur 1 Datensicherung und nicht MySQL Daten und Dateien getrennt.
Irgendwelche Performance Probleme lassen sich durch cachen mildern.

Allerdings bieten normale Webspaces nicht immer die Möglichkeiten mit so riesigen Datensicherungen umzugehen.

Das mit der einzigen Datensicherung fand ich auch sehr interessant, musste dann aber bei unserer DB feststellen, dass die Größe explodiert ist.

Einen Tipp bzgl Performance hatte ich gelesen, da wurde vorgeschlagen die BLOB_Felder in eine eigene Tabelle zu legen (die dann 1zu1 mit der Tabelle mit den restlichen Dateiinformationen verknüpft ist), denn selbst wenn man die BLOB-Felder nicht abfragen würde, könnte es wohl passieren dass diese beim Abfragen der Tabelle das Ganze ausbremsen.

[combie]

denn selbst wenn man die BLOB-Felder nicht abfragen würde, könnte es wohl passieren dass diese beim Abfragen der Tabelle das Ganze ausbremsen.

Dazu habe ich bei mir noch keine Indizien gefunden.
Darum: Das Auslagern in extra Tabellen ist, nunja, recht sinnfrei.

Das dümmste, was man mit solchen Tabellen(mit fetten Blobs) machen kann ist "SELECT [COLOR="red"]*[/COLOR] FROM ...."

[Lennynero]

SQL-Optimierung: Tabellen und Spalten anpassen - Teil 3: MySQL 4 - Optimierung von Anfragen | Vermeiden Sie, große BLOB-Werte zu suchen, wenn das nicht unbedingt erforderlich ist | TecChannel.de

Sammeln Sie BLOB-Werte in einer separaten Tabelle
Manchmal kann es sinnvoll sein, BLOB-Werte aus einer Tabellenspalte in eine separate Tabelle zu verschieben, wenn Sie dadurch die Zeilen der ursprünglichen Tabelle in ein
Format fester Länge umwandeln können. Damit wird die Fragmentierung der
ursprünglichen Tabelle reduziert, und Sie können die Leistungsvorteile von Zeilen fester Länge nutzen. Außerdem können Sie bei dieser Vorgehensweise Anfragen vom Typ SELECT * in der Primärtabelle ausführen, ohne umfangreiche BLOB-Werte über das Netzwerk zu holen.

"SELECT *" sollte man imo generell vermeiden.

Das war jetzt auch die schnellste Quelle die ich gefunden habe... bin mir aber sicher das ich das auf einer englischsprachigen Seite etwas ausführlicher begründet gelesen habe.

[combie]

Habs gerade noch mal getestet.

Tabelle mit ca 20000 Rows
Mysql 5.1.30-community
innodb
In den Blobs liegen PDF Dateien verschiedenster Größe.


Ein SELECT, welcher ca 100 Rows daraus per where selektiert.
Die BLOB Spalte nicht mit ausgewählt.


Erst mit Blobspalte, danach Blobspalte entfernt, und das gleiche select Statement verwendet.

Kein Unterschied/Tendenz festzustellen.

[unset]

Also, ich persönlich speicher Daten seit einigen Jahren nur noch in der Datenbank –*auch wenn ich dafür schon oft blöd angeguckt worden bin. So wirklich triftige Argumente dagegen konnte mir niemand nennen. Und nennenswerte Geschwindigkeitseinbußen konnte ich auch nicht feststellen. IMHO spricht nix dagegen.

[h3ll]

Also, ich persönlich speicher Daten seit einigen Jahren nur noch in der Datenbank –*auch wenn ich dafür schon oft blöd angeguckt worden bin. So wirklich triftige Argumente dagegen konnte mir niemand nennen. Und nennenswerte Geschwindigkeitseinbußen konnte ich auch nicht feststellen. IMHO spricht nix dagegen.

Wenn du mit externe Programme auf die Dateien zugreifen willst, musst du sie jedesmal aus der Datenbank holen und abschließend wieder zurückspeichern. Ziemlich umständlich und verbraucht unnötig Ressourcen.

Außerdem wird dadurch eine Synchronisation unnötig kompliziert. Auf Dateisystemebene reicht einfach ein rsync und fertig ist die Geschichte. Wenn du jetzt aber anfängst Binärdaten zwischen zwei Datenbanken abzugleichen, geht die Performance der Server schnell in die Knie.

Dateien auf Dateiebene kannst du übrigens problemlos mit HTML verlinken. Wenn die Dateien allerdings in der Datenbank sind, brauchst du ein Script, das jedesmal die Daten aus der Datenbank zieht. Das kann bei einer großen Menge schon zu einem ziemlichen Problem werden. Stell dir ein CMS vor wo Bilder auf der Seite verlinkt sind. Angenommen auf einer Seite sind 50 Bilder, dann werden pro Seitenaufruf 51 PHP-Prozesse gestartet (einer, der HTML liefert, und 50 andere, die Bilder aus der Datenbank holen). Wenn jetzt 10 Leute gleichzeitig aufrufen hast du statt 10 PHP-Prozesse 510 PHP-Prozesse.

[unset]

Wie ich schon angedeutet habe, dass sind Rechenspielchen und Zahlen, die in der realen Welt dann gar nicht mehr so ein Gewicht haben. Ich mache das seit Jahren so und habe damit noch nie Probleme gehabt. Wobei: Es handelt sich dabei tatsächlich auch nur noch um Daten, die (dort) nicht mehr nachbearbeitet werden –*d.h. das externe Öffnen fällt flach. Obwohl ich mal angefangen habe, mir für so einen Fall einen FUSE-Wrapper zu bauen –*aber wo kein Kläger, da kein Richter, und ohne Motivation einfach nur aus Spaß war mir das dann doch zu schwer.

[PHP-Desaster]

Wir nutzen das intern auch so für verschiedene Systeme. Hintergrund ist jedoch die verteile Ausführung der Anwendung mit der Datenbank als einzigen gemeinsamen Datenspeicher. Sicherlich auch irgendwie über einen entsprechenden Fileserver zu lösen, jedoch ist die Datenbank eh immer vorhanden, erlaubt auf jeden Fall Locks, etc. Der Einrichtungsaufwand ist einfach geringer.

[onemorenerd]

Ich habe noch niemals ernsthaft Dateien in einer DB gespeichert und sehe das auch bei der Arbeit nie.
Was speichert ihr denn da bitte für Dateien? Warum eigentlich in der DB?
Nur weil das Backupscript dann eine Zeile kürzer ist?