MongoDB
 sql >> Datenbank >  >> NoSQL >> MongoDB

Speicher für Millionen von Bildern

Ich habe in meinem Leben Videos sowohl mit S3 (einschließlich Rackspace-Clouddateien) als auch mit MongoDB verteilt.

Die meisten Leute würden sich ohne einen zweiten Blick für S3 entscheiden, aber ich habe festgestellt, dass beide ihre Nachteile haben. Eines der großen Probleme ist, dass S3 kein CDN ist, sondern ein redundanter Speicher innerhalb einer bestimmten Region, der nicht in andere S3-Regionen repliziert wird. Das bedeutet, dass Sie etwas wie Cloudfront auf S3 verwenden müssen, um Ihre Bilder zu pingen zu einer Art Cache, wenn Sie ernsthafte Lasten auf Ihrer Website bekommen sollten.

S3 hat auch andere Funktionen, die es weniger CDN-artig und eher zu einem Lagerhaus machen. Davon abgesehen ist S3 für Dateien, auf die selten zugegriffen wird, unglaublich schnell.

Diese Doppelschicht schafft natürlich Komplexitäten wie die Wartung. Nicht nur das, ein CDN funktioniert auch mit TTLs, und obwohl viele CDNs heutzutage Edge-Purge-Fähigkeiten haben, sind sie immer noch keine 100 % sichere Methode, um sicherzustellen, dass Ihre Dateien nicht zugänglich sind.

Aufgrund der Einrichtung und der Zugriffe (mögliche Zugriffe auf Dateien, die auch gelöscht werden sollen) kann dies also schnell recht teuer werden.

Hier könnte MongoDB gewinnen. MongoDB könnte, abhängig von Ihrem Szenario, hier tatsächlich billiger sein, da Sie eine ganze Reihe von Mikroinstanzen auf AWS verwenden könnten, um Ihre Informationen tatsächlich zu speichern, indem Sie diesen Instanzen eine Spot-Instance-Reservierung hinzufügen (sehr billig) und alles, was Sie brauchen ist eine große Festplatte auf einem einzelnen Rechner.

Verdammt, Sie könnten sogar S3 verwenden, um die Bilder zu speichern, und dann MongoDB als Cloudfront-Ersatz.

Wenn Sie Bilder an verschiedene Regionen pingen möchten, erstellen Sie einfach ein paar Spot-Instances in dieser Zielregion und lassen MongoDB seine Daten über diese hinweg replizieren. Sie können auch einige coole Sachen mit der Replikation machen, um sicherzustellen, dass nur häufig aufgerufene Dateien aus dieser Region in dieser Region abgelegt werden.

Also würde ich MongoDB nicht rausschmeißen (oder sogar Cassandra), sondern ich würde eine Bedürftigkeitsprüfung zwischen den beiden durchführen.

Bearbeiten

Als zusätzlicher Hinweis zu den S3-Preisen:Wenn Sie Ihre Dateien in RR (Reduced Redundancy) speichern, halbiert sich der Preis (ungefähr), was S3 sehr billig macht, aber Sie haben immer noch das Problem, dass S3 kein CDN ist.

Weitere Bearbeitung

Da ich wirklich nur von @ cirrus 'Antwort weitergegangen bin, werde ich Ihre Frage, die oben irgendwie beantwortet wurde, tatsächlich neu bewerten.

Zum Beispiel speichert YouTube alle seine Bilder auf einzelnen Computern, die dann verteilt werden, sodass sie problemlos 200 Millionen Miniaturansichten und ... naja ... viele Aufrufe pro Tag einfach über das Dateisystem verwalten können. Daher denke ich, dass Ihre Sorge um das Dateisystem überbewertet ist.

Welche Datenbank ist besser ... Ich weiß nicht, das hängt von Ihren Tests ab.

Ich meine, die Antwort auf Ihr Problem hängt von Ihrem Szenario und Ihrem Budget sowie Ihrer Hardware und Ihren Ressourcen ab, d. h. wenn Sie AWS-Server haben, wäre dies eine ganz andere Antwort als dedizierte Inhouse-Server.