Bereitstellung von Images aus SQL Server vs. Dateisystem vs. S3 etc

Meine Anwendung (klassisches asp yay!) Hat ungefähr 2,1 Millionen Bilder bei 25 GB und das entspricht nur 90 Tagen Daten, und ich möchte mindestens auf 365 gehen. Ich muss diese unter Kontrolle bringen und erwäge alle Optionen. Was denken Sie über die Vor- und Nachteile der folgenden Praktiken:

• SQL Server-Vorteile: Einfache Sicherung Nachteile: Leistung?
• Dateisystem-Vorteile: Geschwindigkeit Nachteile: Redundanz, Sicherung ist langsam (derzeit wird nach synthetischen vollständigen Sicherungen gesucht, die dies möglicherweise verbessern)
• S3 und ähnliche Vorteile: Die Bandbreite wird von meinem Rechenzentrum zu Amazon verlagert, praktisch unbegrenzter Speicherplatz. Nachteile: Kosten, Kostenanalyse ist schwierig (geschätzte 80% meiner Bandbreite sind Bilder für ROI-Zwecke)

Beschäftigt sich noch jemand mit der Multi-Millionen-Image-Herausforderung und wie haben Sie sie angegangen?

Wir haben nicht Millionen von Bildern, aber Hunderttausende, und wir verwenden den Hybridansatz - mysql für Metadaten, Bilder, die zur Sicherung auf der lokalen Festplatte gespeichert und an Amazon s3 gesendet werden, wo sie den Benutzern bereitgestellt werden. Wir hatten keine Probleme mit Amazon und der Verfügbarkeit. Der Umstieg auf Cloudfront ist in unseren Plänen, wir müssen nur die Zeit finden.

Diese Diskussion kann für Sie bei Ihrer Entscheidung hilfreich sein:
http://ask.metafilter.com/59635/Millions-of-images

Ich würde mit Metadaten in SQL Server und Dateien auf dem Dateisystem (oder S3 oder Cloudfront) gehen. Die beste Antwort hängt jedoch von einigen anderen Verwendungsmustern ab:

• Ändern sich die Bilder oft?
• Können Sie die Bilder direkt aus dem Dateisystem bereitstellen (d. h. img src="...") oder benötigen Sie eine Zugriffskontrolle? In letzterem Fall ist eine Datenbanklösung am besten geeignet
• Liefern Sie die meiste Zeit eine kleine Anzahl von Bildern (die letzten 10%) oder ist die Verteilung relativ weit verbreitet?

Backups für Millionen von Images werden kompliziert, egal wie Sie sie anordnen - es sind nur viele Daten. Ich möchte eine gute Fallstudie zum Sichern von Blobs in SQL Server finden, bevor ich mich für diese Lösung entscheide. (Hier ist ein Artikel, der nützlich sein könnte: http://www.databasejournal.com/features/mssql/article.php/3738276/Storing-Images-and-BLOB-files-in-SQL-Server-Part-4.htm )

Wenn Sie sie im Dateisystem speichern möchten, sollten Sie diese ServerFault-Frage für einige Aufgaben und Fehler lesen: Eine Million Bilder im Dateisystem speichern .

Ignorieren Sie Personen, die sagen: " Speichern Sie keine Bilder / Binärdaten in der Datenbank ", da ihre Antworten auf alten Informationen basieren (vorausgesetzt, Sie speichern die Daten in einer Spalte vom Typ VarBinary). Die Leistungsprobleme bei der Verwendung von SQL Server zum Speichern von Bildern können jetzt mithilfe des Datentyps FILESTREAM in SQL Server 2008 gemindert werden . Im Wesentlichen können Sie mit dem Datentyp FILESTREAM die einfache Speicherung von Daten in der Datenbank mit der Leistung kombinieren, die Sie durch die Bereitstellung erhalten Dateien aus einem NTFS-Dateispeicher.

So zitieren Sie SQL Mag :

"Die neue FILESTREAM-Unterstützung von SQL Server 2008 kombiniert den Vorteil des direkten Zugriffs auf Branchen über das NTFS-Dateisystem mit der referenziellen Integrität und dem einfachen Zugriff durch das relationale Datenbankmodul von SQL Server."

Weitere Informationen finden Sie in diesem Blog von Ravi S.Maniam auf MSDN .

Obwohl ich mich nicht mit der Herausforderung von mehreren Millionen Bildern befasse, würde ich Amazon CloudFront verwenden. Alle Dateien werden in einem S3-Bucket gespeichert, sind jedoch über das Content Delivery-System von Amazon Server. Ich würde S3 nicht alleine benutzen.

Meine zweite Wahl wäre das Dateisystem. Einfach und leicht, das einzige Problem ist, wenn alle diese Dateien in einem Verzeichnis landen, stürzt das Ganze hart ab.

SQL wäre für mich keine Option für ein System wie dieses. Sie erhalten nicht nur eine Gebühr für die Übertragung der Bandbreite, sondern auch für die Verarbeitung der Abfrage. Dies hängt stark vom Hosting ab. Ich gehe jedoch davon aus, dass Sie einen dedizierten Server oder zumindest ein vps verwenden, für das eine Gebühr erhoben wird für Fahrräder. Dann wird die gesamte Site verlangsamt, wenn dieselbe Datenbank wie der Image-Server verwendet wird. Wenn nicht, müssen Sie zusätzlich zwei Datenbankverbindungen verwalten.

Datenbanken sind auf Transaktionsdaten / Konsistenz und Sicherheit ausgelegt.

Mediendateien (Bilder, Audio, Video) werden in der Regel erstellt und möglicherweise gelöscht, jedoch nur sehr selten aktualisiert. Im Allgemeinen müssen sie nicht mit anderen Daten transaktionskonform sein, und eine Datenbank bietet Ihnen dort keinen wirklichen Vorteil. Textinhalt vielleicht eine andere Sache.

Solange Sie kein Problem damit haben, dass jemand Ihre Datei direkt abruft, wenn er die URL der Datei hat, ist ein Dateisystem in Ordnung. Wenn Sie so etwas wie eine Fotobibliothek ausgeführt haben, in der Sie vor dem Herunterladen der Datei eine Aufladung erwarten, ist dies wahrscheinlich eine andere Sache. Das heißt, sobald ein Benutzer bezahlt hat, erhält er möglicherweise eine URL, die für diesen Benutzer spezifisch oder nur für kurze Zeit gültig ist, und die Anwendung verarbeitet mehrere oder temporäre URLs, die auf dasselbe Bild verweisen. Das könnte immer noch von der App und einem Dateisystem erledigt werden, aber am Ende werden die Medien eher über die Anwendung als als direkter Dateidownload bereitgestellt (was die Vorteile von S3 größtenteils ausschließen würde), und es gibt weniger Unterschiede zwischen DB und Dateisystem .