Es gibt hier einen guten Artikel über s3fs, den ich nach dem Lesen auf eine EBS-Freigabe zurückgegriffen habe.
Es hebt einige wichtige Überlegungen bei der Verwendung von s3fs hervor, nämlich in Bezug auf die inhärenten Einschränkungen von S3:
- keine Datei darf größer als 5 GB sein
- Sie können eine Datei nicht teilweise aktualisieren, sodass durch das Ändern eines einzelnen Bytes die gesamte Datei neu hochgeladen wird.
- Operationen mit vielen kleinen Dateien sind sehr effizient (jede ist schließlich ein separates S3-Objekt), aber große Dateien sind sehr ineffizient
- Obwohl S3 partielle/chunked Downloads unterstützt, nutzt s3fs dies nicht. Wenn Sie also nur ein Byte einer 1-GB-Datei lesen möchten, müssen Sie die gesamten GB herunterladen.
Es hängt daher davon ab, was Sie speichern, ob s3fs eine praktikable Option ist. Wenn Sie beispielsweise Fotos speichern, in die Sie eine ganze Datei schreiben oder eine ganze Datei lesen möchten, ändern Sie niemals eine Datei inkrementell, dann ist es in Ordnung, obwohl man fragen könnte, wenn Sie dies tun, warum verwenden Sie dann nicht einfach S3s API direkt?
Wenn Sie über Anwendungsdaten sprechen (z. B. Datenbankdateien, Protokolldateien), an denen Sie kleine inkrementelle Änderungen vornehmen möchten, ist dies definitiv ein Nein - S3 funktioniert einfach nicht, so dass Sie eine Datei nicht inkrementell ändern können.
Der oben erwähnte Artikel spricht von einer ähnlichen Anwendung – s3backer – die die Leistungsprobleme umgeht, indem sie ein virtuelles Dateisystem über S3 implementiert. Dies umgeht die Leistungsprobleme, hat aber selbst einige Probleme:
- Hohes Risiko für Datenbeschädigung aufgrund verzögerter Schreibvorgänge
- Zu kleine Blockgrößen (z. B. die Standardeinstellung von 4 KB) können erhebliche Zusatzkosten verursachen (z. B. 130 $ für 50 GB mit Speicherplatz im Wert von 4 K-Blöcken)
- Zu große Blockgrößen können erhebliche Datenübertragungs- und Speichergebühren verursachen.
- Die Speichernutzung kann unerschwinglich sein:Standardmäßig werden 1000 Blöcke zwischengespeichert.
Mit der standardmäßigen 4K-Blockgröße ist das kein Problem, aber die meisten Benutzer
wird wahrscheinlich die Blockgröße erhöhen wollen.
Ich habe auf EBS Mounted Drived Shared von einer EC2-Instanz zurückgegriffen. Aber Sie sollten wissen, dass, obwohl die leistungsfähigste Option, ein großes Problem hat. Eine EBS-gemountete NFS-Freigabe hat ihre eigenen Probleme – einen einzelnen Fehlerpunkt; Wenn der Computer, der das EBS-Volume teilt, ausfällt, verlieren Sie den Zugriff auf alle Computer, die auf die Freigabe zugreifen.
Das ist ein Risiko, mit dem ich leben konnte und für das ich mich letztendlich entschieden habe. Ich hoffe, das hilft.
Dies ist eine alte Frage, daher werde ich meine Erfahrungen im vergangenen Jahr mit S3FS teilen.
Anfangs hatte es eine Reihe von Fehlern und Speicherlecks (ich hatte einen Cron-Job, um es alle 2 Stunden neu zu starten), aber mit der neuesten Version 1.73 war es sehr stabil.
Das Beste an S3FS ist, dass Sie sich um eine Sache weniger kümmern müssen und einige Leistungsvorteile kostenlos erhalten.
Die meisten Ihrer S3-Anfragen werden PUT (~5 %) und GET (~95 %) sein. Wenn Sie keine Nachbearbeitung benötigen (zum Beispiel Thumbnail-Generierung). Wenn Sie keine Nachbearbeitung benötigen, sollten Sie Ihren Webserver gar nicht erst aufrufen und direkt auf S3 hochladen (mit CORS).
Angenommen, Sie treffen den Server, bedeutet wahrscheinlich, dass Sie Bilder nachbearbeiten müssen. Mit einer S3-API laden Sie auf den Server und dann auf S3 hoch. Wenn der Benutzer zuschneiden möchte, müssen Sie erneut von S3 herunterladen, dann erneut auf den Server hochladen, zuschneiden und dann zu S3 hochladen. Wenn S3FS und lokales Caching aktiviert sind, wird diese Orchestrierung für Sie erledigt und das Herunterladen von Dateien von S3 erspart.
Wenn Sie beim Caching auf einem kurzlebigen Laufwerk auf EC2 zwischenspeichern, erhalten Sie die damit verbundenen Leistungsvorteile und können Ihren Cache leeren, ohne sich um irgendetwas kümmern zu müssen. Sofern Ihnen nicht der Speicherplatz ausgeht, sollten Sie keinen Grund haben, Ihren Cache zu leeren. Dies erleichtert das Durchlaufen von Vorgängen wie Suchen und Filtern erheblich.
Das einzige, was ich mir wünschte, war eine vollständige Synchronisierung mit S3 (RSync-Stil). Das würde es zu einer Unternehmensversion von DropBox oder Google Drive für S3 machen, aber ohne die damit verbundenen Kontingente und Gebühren.