Was ist der beste Ort, Bilder hochgeladen zur Speicherung, SQL-Datenbank oder Disk-Dateisystem?

https://stackoverflow.com/questions/348363

20-08-2019
|

Frage

Ich schreibe eine Anwendung, die Benutzer Bilder auf den Server hochladen kann. Ich erwarte, dass etwa 20 Bilder pro Tag alle JPEG und wahrscheinlich nicht bearbeitet / angepasst. (Dies ist eine andere Frage, wie die Bilder auf der Serverseite, um die Größe vor dem Speichern. Vielleicht kann jemand dann schreiben Sie eine .NET-Ressource für die im Kommentar oder so). Ich frage mich jetzt, was der beste Platz für hochgeladene Bilder zu speichern ist.

Speichern Sie die Bilder als Datei im Dateisystem und einen Datensatz in einer Tabelle mit dem genauen Pfad erstellen zu diesem Bild.
Oder speichern Sie das Bild selbst in einer Tabelle ein „Bild“ oder „Binärdaten“ Datentyp des Datenbankservers.

Ich sehe Vor- und Nachteile in beiden. Ich mag a) weil ich einfach die Dateien verlagern kann und muß nur den Tabelleneintrag ändern. Auf der anderen Seite mag ich nicht von Geschäftsdaten auf dem Web-Server zu speichern und ich will nicht wirklich den Web-Server zu jeder anderen Datenquelle verbinden, die Geschäftsdaten hält (aus Sicherheitsgründen) Ich mag b), weil alle Informationen an einem Ort befinden und leicht zugänglich durch eine Abfrage. Auf der anderen Seite wird die Datenbank sehr schnell sehr groß werden. dass Daten Outsourcing könnte schwieriger sein.

Lösung

Ich speichere im Allgemeinen Dateien auf dem Dateisystem, denn das ist, was seine dort, obwohl es Ausnahmen gibt. Für Dateien, die Datei-System die flexibelste und performante Lösung (in der Regel).

Es gibt ein paar Probleme mit Dateien in einer Datenbank zu speichern - Dateien sind in der Regel viel größer als ein durchschnittlicher Reihe - Ergebnis-Sets viele große Dateien enthält, wird viel Speicher verbrauchen. Auch, wenn Sie eine Speicher-Engine verwenden, die Tabellensperren für Schreibvorgänge (ISAM zum Beispiel), um Ihre Dateien Tabelle oft abhängig gesperrt werden könnte, beschäftigt von der Größe / Rate von Dateien, die Sie dort sind, zu speichern.

In Bezug auf Sicherheit -. Ich speichere in der Regel die Dateien in einem Verzeichnis, das außerhalb des Document-Root ist (nicht zugänglich durch eine HTTP-Anforderung) und dienen sie durch ein Skript, das zunächst für die entsprechende Berechtigung überprüft

Andere Tipps

Der einzige Vorteil für die Option B ist mit allen Daten in einem System, aber es ist ein falscher Vorteil! Sie können argumentieren, dass der Code auch eine Form von Daten und kann daher auch in der Datenbank gespeichert werden - wie würden Sie es mögen

Es sei denn, Sie haben einigen einzigartigen Fall:

Die Geschäftslogik gehört in Code.
Strukturierte Daten gehören in der Datenbank (relational oder nicht-relational).
Bulk-Daten gehört in Speicher (Dateisystem oder einer anderen).

Dateien, Code, Daten

Es ist nicht notwendig Dateisystem zu verwenden, um Dateien zu halten. Stattdessen können Sie Cloud-Speicher (wie Amazon S3 ) oder Infrastructure-as-a-Service oben drauf verwenden (wie zB Uploadcare ):

https://uploadcare.com/upload-api-cloud-storage-and-cdn/

Aber Dateien in der Datenbank zu speichern ist eine schlechte Idee.

Flickr verwendet das Dateisystem -Sie die Gründe diskutiert hier

Wir hatten Kunden bestehen auf Option B (Datenbankspeicher) ein paar Mal auf ein paar verschiedene Backends, und wir immer endete schließlich geht zurück auf Option A (Dateisystem Speicher).

Große BLOBs wie das eben nicht gut genug, um auch von SQL Server 2005 behandelt worden, das ist die späteste wir es anprobiert.

Insbesondere sahen wir ernst aufblasen und ich denke, vielleicht Probleme sperren.

Ein weiterer Hinweis: Wenn Sie NTFS-basierte Speicher verwenden (Windows-Server, etc) Sie könnten einen Weg, um Tausende und Tausende von Dateien in einem Verzeichnis zu finden betrachten setzen. Ich bin nicht sicher, warum, aber manchmal das Dateisystem bewältigen nicht gut mit dieser Situation. Wenn jemand mehr darüber weiß, würde ich gerne hören.

Aber ich versuche immer Verzeichnisse zu verwenden, die Dinge ein wenig zu brechen. Erstellungsdatum oft funktioniert gut für diese:

Bilder / 2008/12/17 / .jpg

... Dies stellt ein annehmbares Maß an Trennung und hilft auch ein wenig während des Debuggens. Kunden Explorer und FTP gleichermaßen kann ein wenig drosseln, wenn es wirklich große Verzeichnisse sind.

EDIT: Nur eine kurze Notiz für 2017 in neueren Versionen von SQL Server gibt es neue Möglichkeiten für viele BLOBs Handhabung, die die Nachteile vermeiden, soll ich diskutiert.

Ich habe vor kurzem einen PHP / MySQL-App, die PDF-Dateien / Word-Dateien in einer MySQL-Tabelle (so groß wie 40 MB pro Datei bisher).

speichert

Vorteile:

Hochgeladene Dateien auf Backup-Server zusammen mit allem repliziert werden sonst keine separate Backup-Strategie erforderlich ist (innere Ruhe).
, um den Web-Server einrichten ist etwas einfacher, weil ich brauche keine uploads / Ordner haben und alle meine Anwendungen sagen, wo es ist.
Ich erhalte Transaktionen für Änderungen zu verwenden, die Datenintegrität zu verbessern - ich habe nicht über verwaist zu kümmern und fehlende Dateien

Nachteile:

mysqldump nimmt nun eine looooong Zeit, weil es 500 MB Dateidaten in einem der Tische ist.
Insgesamt nicht sehr Speicher / CPU effizient im Vergleich zu Dateisystem

Ich würde meine Implementierung ein Erfolg nennen, es kümmert sich um Backup-Anforderungen und vereinfacht das Layout des Projekts. Die Leistung ist in Ordnung für die 20-30 Personen, die die App verwenden.

Ich weiß, dass dies eine alte Post ist. Aber viele Besucher auf dieser Seite werden immer nichts in Bezug auf die Frage. Vor allem für einen Neuling.

Wie zum Hochladen und Speichern von Bildern oder eine Datei auf unserer Webseite:

Für eine statische Website gibt vielleicht kein Problem, da der Dateispeicher für einige Aktien Hosting immer noch ausreichend. Das Problem kommt von einer dynamischen Website, wenn es größer wird. Bigger in der Datenbank bearbeitet werden kann, aber größer in der Datei wie zum Beispiel Bilder ist ein Problem. Es gibt zwei Arten von Bildern in einer Webseite:

Bilder stammen vom Administrator für dynamischen Blog. Normalerweise sind diese Bilder wurden vor dem Hochladen optimiert.
Bilder von den Benutzern bei den Benutzern erlaubt Bilder hochladen wie Avatar. Oder Benutzer können Blog-Inhalte erstellen und einige Bilder aus Texteditor gestellt. Diese Art von Bildern ist schwierig, die Größe vorherzusagen. Benutzer können große Bilder nur für kleine Inhalte hochladen, indem die Größe Ansicht der Größe, aber die Bildgröße nicht ändern.

Durch das Ignorieren Artikel-Nr. 1 oben, schnelle Lösung für Artikel-Nr. 2 kann durch die folgenden Tipps gelöst vorübergehend sein, wenn wir nicht Bild-Optimierer Funktionalität in unserer Website:

Sie Benutzer nicht erlauben, direkt aus Texteditor zu laden, indem sie auf die Bildgalerie umleitet. Auf dieser Seite müssen die Benutzer-Datei im Voraus laden, bevor sie in den Inhalt eingebettet werden. Diese Methode wird als Dateimanager genannt.
Verwenden Sie eine Ernte Bildfunktion für die Nutzer Bilder hochladen. Dadurch wird die Bildgröße selbst Benutzer laden sehr große Datei begrenzen. Das letzte Bild ist das Ergebnis des beschnittenen Bildes. Wir können die Größe in Server-Seite definieren und nehmen nur zum Beispiel 500Kb oder niedriger ist.

Nun, das ist nur vorübergehend. Für die endgültige Lösung wird die Frage wiederholt:

Wie eine große Bilder Lagerung zu handhaben?
Ändern Sie die Größe oder die Erweiterung ändern.
Wie eine große oder mittlere Website oder E-Commerce übernehmen die Speicherung von Dateien für ihre Bilder?

Was wir tun können, dann:

Migration von Aktien Hosting VPS. Nicht genug? Dann mehr höher zu Dedicated aktualisieren.
Erstellen Sie Ihren eigenen Server für die Dateispeicherung. Googeln, es zu tun. Das ist nicht so schwierig, wie Sie denken. Manche Menschen tun es für ihre Website.
Der einfachste Weg ist die Datei-Storage-Service CDN verwenden.

Okay, 1 und 2 ist etwas teuer. Aber nein 3 Ich denke, ist die beste Lösung.

Einige CDN-Dienste ermöglichen es Ihnen, viele Web-Dateien zu speichern, wie Sie wollen.

Frage: "Wie Datei zu CDN von unserer Website hochladen?"

Keine Sorge, wenn Sie sich registrieren, in der Regel kostenlos, werden Sie Anleitung erhalten, wie Datei laden und ihre Verbindung erhalten von / auf Ihre Website. Sie erhalten eine API erhalten und vieles mehr. Es ist einfach.

Einige Anbieter geben uns einen kostenlosen Service für 14 Tage mit begrenztem Speicherplatz und Bandbreite. Aber das wird für Ausgangspunkt in Ordnung sein. Das einzige Problem ist, weil ‚die Menschen nie versuchen‘.

Hoffe, dass es für Anfänger helfen.

Ich verwende hochgeladene Bilder auf meiner Website und ich würde auf jeden Fall sagen Option a).

Eine andere Sache, die ich sehr empfehlen würde sofort ändert den Dateinamen aus, was der Benutzer das Foto genannt hat, zu etwas mehr überschaubar. Zum Beispiel etwas mit dem Datum und die Zeit eindeutig jedes Bild zu identifizieren.

Es hilft auch, die Benutzerdateinamen von irgendwelchen seltsamen Zeichen abzustreifen zukünftige Komplikationen zu vermeiden.

Auf jeden Fall die Größe des Bildes, und überprüfen Sie es Format, wenn Sie können. Es wurden Fälle von bösartigen Dateien durch unwissende-Hosts zum Beispiel hochgeladen und serviert wird, die Gifar Verwundbarkeit erlauben Ihnen ein bösartiges Java-Applet in einer GIF-Datei zu verstecken, die dann in der Lage sein würden, diese Option in dem aktuellen Kontext zu lesen und sie für einen Cross-Site-Scripting-Angriff auf einem anderen Seite zu senden. Ändern der Größe der Bilder verhindert in der Regel diese, da sie den eingebetteten Code munges. Während dieser Angriff durch JVM Patches behoben wurde, naiverweise binäre Dateien dienen, ohne sie schrubben öffnet Ihnen eine ganze Reihe von Schwachstellen auf.

Denken Sie daran, die meisten Virenscanner nur gegen das das Dateisystem ausführen, wenn Sie Ihre Binärdateien in der DB speichern, werden Sie nicht in der Lage sein, einen Scanner gegen sie sehr leicht ausgeführt werden.

Die meisten Implementierungen sind Option A.

Mit der Option B, öffnen Sie eine ganz große Dose whoop4ss wenn Sie marshall diese Bits aus der Datenbank in etwas, das auf einem Browser angezeigt werden kann ... Auch wenn der db nach unten ist, werden die Bilder nicht verfügbar sind.

Ich glaube nicht, dass der Raum zu sehr ein Problem ist ... Terabyte-Laufwerke sind ein paar hundert Dollar jetzt.

Wir sind mit Option A setzen, weil wir Option B nicht über die Zeit oder Ressourcen zu tun haben.

Für Auto Redimensionierung, versucht imagemagick ... es für viele großen Open-Source Content / Foto-Management-Systeme verwendet wird ... und ich glaube, dass es einige .net-Erweiterungen für es.

Es ist irgendwie ein hybrider Ansatz in SQL Server 2008 die Filestream-Datentyp das war auf spricht RunAs Radio # 74 , die wie das beste aus beiden Welten Art ist. Die meisten Menschen haben nicht die 2008 otion, aber wenn Sie das tun, sieht diese Option ziemlich cool

Dies ist im Grunde das tue ich.

Speichern Sie ein hochgeladenes Bild in temporäres Verzeichnis oder Speicher.
Ein Prozess, Bild, bevor sie dauerhaft zu speichern. 2.1. Farbkorrekturen 2.2. Komprimieren 2.3. Erstellen Sie mehrere Kopien auf Basis von Bildabmessungen 2.4. Umbenennen mit .xl, .lg, .md, .sm usw. Suffixe
Packen Sie alle verarbeiteten Bilddateien (aus einer einzigen Datei) in einem Ordner mit Ordnernamen als id, die zusammen mit image file name für jede Zeile / Dokument in der Datenbank gespeichert werden (oder zufällige Namen als Bildname sein kann).
Erstellen yyyy / mm / d path Ordner, wenn nicht vorhanden ist. Zum Beispiel 2016.08.21. Denken Sie daran, dass der Pfad und speichert in der Datenbank für gleiches Dokument und Zeile.
Verschieben Bild id Ordner path Ordner. (Path Ordner in / var / Web-Content-Ordner befindet.)
Flush Speicherpuffer oder löschen temporäre Datei.

Wenn Sie ein beliebiges Bild in einem Dokument erwähnt zugreifen müssen, müssen Sie den Pfad und ID des Ordners als Bilder enthält. Zum Beispiel /var/web-content/{{path}}/{{id}}/image-file-name.sm.jpg

Auf diese Weise, wenn Sie alle bearbeiteten Bilddateien löschen müssen, nur den Ordner löschen und es ist rekursiv Inhalt.

Wir verwenden A. Ich würde es auf einem gemeinsam genutzten Laufwerk setzen (es sei denn, Sie auf laufen mehr als ein Server nicht planen).

Wenn die Zeit kommt, wenn dieser nicht skaliert wird für Sie, dann können Sie Caching-Mechanismen untersuchen.

Absolut positiv Option A. Andere haben erwähnt, dass die Datenbanken im Allgemeinen befassen sich nicht gut mit BLOBs, ob sie dazu bestimmt sind, so zu tun oder nicht. Dateisysteme, auf der anderen Seite, leben für dieses Zeug. Sie haben die Möglichkeit, RAID-Striping verwenden, Bilder auf mehrere Laufwerke verbreitet, auch sie über geographisch getrennten Servern zu verbreiten.

Ein weiterer Vorteil ist die Datenbank-Backups / Replikation ungeheuerlich wäre.

Option A.

Nachdem das Bild geladen ist, können Sie das Format überprüfen und die Größe vor dem Speichern. Es gibt eine Reihe von Code-Beispielen .Net, um die Größe von Bildern auf http://www.codeproject.com . Zum Beispiel: http://www.codeproject.com/KB/cs/Photo_Resize.aspx

Aus Gründen der Sicherheit ist es auch Best-Practice-Probleme zu vermeiden, die durch IE Content Sniffing , die es Angreifern erlauben, können Sie JavaScript innerhalb Bilddateien hochladen, die im Rahmen Ihrer Website ausgeführt bekommen könnte. So könnten Sie die Bilder (crop / Größe ändern) irgendwie verwandeln, bevor sie zu speichern, diese Art von Angriff zu verhindern. Diese Antwort einige andere Ideen hat.

Nun, ich habe ein ähnliches Projekt, bei dem die Benutzer Dateien auf den Server hochladen. Unter meiner Sicht Option a) ist die beste Lösung, weil es flexibler ist. Was Sie tun müssen, ist, Bilder in einem geschützten Ordner Unterordner klassifiziert zu speichern. Das Hauptverzeichnis vom Administrator als Inhalt einrichten müssen keine Skripts ausführen (sehr wichtig) und (Lesen, Schreiben) geschützt für nicht erreichbar in HTTP-Anforderung werden muß.

Ich hoffe, das hilft dir.

Wenn sie sind kleine Dateien, die bearbeitet werden nicht müssen dann B Option ist keine schlechte Option. Ich ziehe diese Logik zu Schreiben von Dateien zu speichern und mit verrückten Verzeichnisstruktur Fragen. Mit viel von Dateien in einem Verzeichnis ist schlecht. emkay?

Wenn die Dateien sind groß oder erfordern eine ständige Bearbeitung, insbesondere von Programmen wie Office, dann Option A ist die beste Wahl.

In den meisten Fällen ist es eine Frage der Präferenz, aber wenn Sie die Option A gehen, machen gerade wieder die Verzeichnisse haben nicht zu viele Dateien in ihnen. Wenn Sie die Option B wählen, dann stellen Sie die Tabelle mit den Daten BLOBed sein in seiner eigenen Datenbank und / oder Dateigruppen. Dies wird bei der Wartung helfen, vor allem Sicherungen / Wiederherstellungen. Ihre regelmäßigen Daten sind wahrscheinlich ziemlich klein, während die Bilddaten werden große im Laufe der Zeit.

Es hängt von Ihren Anforderungen, speziell Volumen, Anwender und die Häufigkeit der Suche. Aber für kleines oder mittleres Büro, die beste Option ist eine Anwendung wie Apple-Fotos oder Adobe Lighroom zu verwenden. Sie werden speichern spezialisiert, Katalog, Index und organisieren diese Art von Ressource. Aber für große Unternehmen, mit starken Anforderungen an Lagerung und hoher Anzahl von Benutzern ist es instantiate einen Content Management plataform mit einem Digital Asset Management, wie Nuxeo oder Alfresco empfehlen; beide bieten sehr gute Ressourcen managen sehr große Datenmengen mit vereinfachten Methoden, um sie retrive. Und, sehr wichtig. Es ist eine freie (Open Source) Option für beide Plattformen

Lizenziert unter: CC-BY-SA mit Zuschreibung

Nicht verbunden mit StackOverflow