S3 son archivos, pero no un sistema de archivos

Artículo original ↗ Discusión en Hacker News ↗

Amazon S3 suele tratarse como si fuera un sistema de archivos, pero los comentaristas subrayan que en esencia es un almacén de objetos/de clave-valor con una semántica muy distinta: no hay directorios reales, no hay modificación en el lugar, los renombrados no son atómicos y los listados por prefijo pueden ser lentos. Estas diferencias importan porque intentar ejecutar software orientado a POSIX, como bases de datos tradicionales o Hadoop, sobre S3 sin una capa de adaptación lleva a mal rendimiento, sutiles problemas de consistencia y comportamiento confuso alrededor de las “carpetas”. Muchos participantes describen las fortalezas de S3 —durabilidad extrema, escalabilidad y simplicidad para blobs inmutables— y señalan capas especializadas (EMRFS, Delta/Iceberg/Hudi, rclone VFS, JuiceFS, arquitecturas tipo Aurora) como la forma adecuada de salvar la distancia cuando se necesitan funciones parecidas a las de un sistema de archivos.

Qué es S3 (y qué no es)

  • Acuerdo general: S3 es un almacén de objetos / almacén de clave-valor, no un sistema de archivos tradicional.
  • Modelo central: asignación plana de claves → objetos; las claves son cadenas opacas, y las operaciones son GET/PUT/DELETE de objeto completo.
  • La semántica estilo POSIX (inodos, directorios como objetos de primera clase, escrituras parciales, renombrados atómicos) está ausente por diseño.
  • Algunos sostienen que S3 aún cuenta como “una especie de sistema de archivos” en sentido amplio (“sistema que gestiona archivos”), mientras que otros insisten en que eso diluye el término y lleva a los usuarios a asumir cosas incorrectas.

“Carpetas” y semántica de rutas

  • S3 no tiene directorios reales. Las “carpetas” en la consola son azúcar de interfaz sobre prefijos de claves, a veces implementadas con objetos “marcador” de 0 bytes.
  • Consecuencias:
    • Puedes tener claves como dir, dir/file, dir//file simultáneamente; las barras no son especiales para S3.
    • Las “carpetas” vacías desaparecen cuando se elimina el último objeto con ese prefijo.
    • Renombrar una “carpeta” requiere copiar y borrar cada objeto con ese prefijo (O(número de objetos) y no atómico).

Operaciones, rendimiento y listado

  • No hay modificación en el lugar ni append; debes volver a subir el contenido alterado o trocearlo en una capa superior.
  • Copy y rename se implementan como copy+delete, con coste y latencia que escalan con el tamaño del objeto.
  • El listado es una diferencia semántica y de rendimiento importante:
    • S3 lista por prefijo en orden lexicográfico y admite paginación; puede ser muy eficiente para escaneos y particionado basados en prefijos.
    • Los recorridos recursivos de directorios estilo POSIX son lentos y requieren muchas llamadas secuenciales a list; borrar o vaciar buckets grandes puede ser costoso y complejo.

Bases de datos y capas de sistema de archivos sobre S3

  • Ejecutar bases de datos tradicionales directamente sobre S3 se considera ampliamente una mala adaptación: latencia, falta de escrituras parciales, sin “escribir si no existe” atómico.
  • Patrones exitosos:
    • Sistemas que son solo append o tratan los archivos como partes inmutables (por ejemplo, motores analíticos, formatos de tabla como Delta/Iceberg/Hudi).
    • Arquitecturas que usan S3 como plano de datos con una capa separada, fuertemente consistente, de metadatos/índice (por ejemplo, bases de datos que usan WAL en S3 más cachés locales, o servicios externos de metadatos).
    • Capas FUSE y VFS (por ejemplo, rclone, sistemas de archivos personalizados) que emulan POSIX cacheando localmente, troceando y gestionando metadatos en otro lugar: útiles, pero complejas y con fugas.

Durabilidad, coste y alternativas

  • La durabilidad de S3 recibe grandes elogios; se describe como líder en la industria, con uso intensivo de checksums y replicación, aunque no se cita validación externa al estilo Jepsen.
  • S3 se considera en general barato para conjuntos de datos grandes y fríos; otros señalan que existen almacenes de objetos más baratos, pero pueden sacrificar fiabilidad o funciones.
  • Para semántica real de sistema de archivos y baja latencia, los comentaristas señalan EBS/EFS/FSx o sistemas de archivos locales; para configuraciones locales “tipo S3 pero más simples”, se sugieren servidores de almacenamiento de objetos o capas personalizadas.