Hay un buen artículo sobre s3fs aquí, que después de leer recurrí a EBS Share.
Destaca algunas consideraciones importantes al usar s3fs, específicamente relacionadas con las limitaciones inherentes de S3:
- ningún archivo puede tener más de 5 GB
- no puede actualizar parcialmente un archivo, por lo que cambiar un solo byte volverá a cargar todo el archivo.
- la operación en muchos archivos pequeños es muy eficiente (después de todo, cada uno es un objeto S3 separado), pero los archivos grandes son muy ineficientes
- Aunque S3 admite descargas parciales o fragmentadas, s3fs no aprovecha esto, por lo que si desea leer solo un byte de un archivo de 1 GB, tendrá que descargar el GB completo.
Por lo tanto, depende de lo que esté almacenando si s3fs es una opción factible. Si está almacenando, digamos, fotos, donde desea escribir un archivo completo o leer un archivo completo, nunca cambie un archivo de forma incremental, entonces está bien, aunque uno puede preguntarse, si está haciendo esto, entonces ¿por qué no usar S3? API directamente?
Si está hablando de datos de aplicación (por ejemplo, archivos de base de datos, archivos de registro) en los que desea realizar pequeños cambios incrementales, entonces definitivamente no:S3 simplemente no funciona de esa manera, no puede cambiar un archivo de forma incremental.
El artículo mencionado anteriormente habla de una aplicación similar, s3backer, que soluciona los problemas de rendimiento mediante la implementación de un sistema de archivos virtual sobre S3. Esto soluciona los problemas de rendimiento, pero tiene algunos problemas propios:
- Alto riesgo de corrupción de datos, debido a las escrituras retrasadas
- los tamaños de bloque demasiado pequeños (por ejemplo, el valor predeterminado de 4K) pueden agregar costos adicionales significativos (por ejemplo, $130 por 50 GB con bloques de 4K de almacenamiento)
- los tamaños de bloque demasiado grandes pueden agregar tarifas significativas de transferencia y almacenamiento de datos.
- el uso de la memoria puede ser prohibitivo:por defecto almacena en caché 1000 bloques.
Con el tamaño de bloque predeterminado de 4K, eso no es un problema, pero la mayoría de los usuarios
probablemente querrá aumentar el tamaño del bloque.
Recurrí a EBS Mounted Drived compartido desde una instancia EC2. Pero debe saber que, aunque es la opción de mayor rendimiento, tiene un gran problema. Un recurso compartido NFS montado en EBS tiene sus propios problemas:un único punto de falla; si la máquina que comparte el volumen de EBS deja de funcionar, perderá el acceso a todas las máquinas que acceden al recurso compartido.
Este es un riesgo con el que pude vivir y fue la opción que elegí al final. Espero que esto ayude.
Esta es una vieja pregunta, así que compartiré mi experiencia durante el último año con S3FS.
Inicialmente, tenía una serie de errores y fugas de memoria (tenía un trabajo cron para reiniciarlo cada 2 horas), pero con la última versión 1.73 ha sido muy estable.
Lo mejor de S3FS es que tiene una cosa menos de qué preocuparse y obtiene algunos beneficios de rendimiento de forma gratuita.
La mayoría de sus solicitudes de S3 serán PUT (~5 %) y GET (~95 %). Si no necesita ningún procesamiento posterior (generación de miniaturas, por ejemplo). Si no necesita ningún procesamiento posterior, no debería acceder a su servidor web en primer lugar y cargar directamente a S3 (usando CORS).
Asumiendo que está ingresando al servidor, probablemente signifique que necesita hacer un procesamiento posterior en las imágenes. Con una API S3, estará cargando en el servidor y luego cargando en S3. Si el usuario desea recortar, deberá descargar nuevamente desde S3, luego volver a cargar al servidor, recortar y luego cargar a S3. Con S3FS y el almacenamiento en caché local activado, esta orquestación está a cargo de usted y ahorra la descarga de archivos desde S3.
En el almacenamiento en caché, si está almacenando en caché en una unidad efímera en EC2, obtiene los beneficios de rendimiento que vienen y puede purgar su caché sin tener que preocuparse por nada. A menos que se quede sin espacio en disco, no debería tener motivos para purgar su caché. Esto hace que las operaciones de desplazamiento, como la búsqueda y el filtrado, sean mucho más sencillas.
Lo único que desearía que tuviera fuera una sincronización completa con S3 (estilo RSync). Eso lo convertiría en una versión empresarial de DropBox o Google Drive para S3, pero sin tener que lidiar con las cuotas y tarifas que conlleva.