La lección anterior dejó fuera de HDFS, deliberadamente, las fotos de los productos: miles de ficheros pequeños que la web tiene que servir por HTTP, con metadatos, versiones y una durabilidad que no dependa de un NameNode. El almacenamiento de objetos nació para exactamente eso. Renuncia a los directorios, a las escrituras parciales y al rename, y a cambio ofrece un modelo plano de buckets y claves, una API HTTP que Amazon S3 convirtió en estándar de facto, durabilidad de "once nueves" mediante replicación y codificación de borrado, y un coste por gigabyte que ningún disco de red iguala. Hoy es el almacén por defecto de fotos, vídeos, copias de seguridad, documentos y, cada vez más, del propio lago de datos. En esta lección entenderemos su modelo y su API, veremos cómo se consigue la durabilidad (con un ejemplo numérico de Reed-Solomon), aprenderemos a reconocer cuándo no es la herramienta adecuada, y lo pondremos a funcionar en Kilómetro Cero con MinIO en docker-compose.yml y un módulo boto3 con el que la Quesería Montblanc subirá la foto de su queso-curado y la web la mostrará mediante URLs prefirmadas.

1. Objeto, fichero y bloque
2. El modelo de objetos: buckets, claves, metadatos y versiones
3. La API S3 como estándar de facto
4. Durabilidad: replicación y codificación de borrado (Reed-Solomon)
5. Consistencia en los almacenes de objetos
6. Cuándo usar objetos y cuándo no
7. Coste: almacenamiento, operaciones y egress
8. Objetos en Kilómetro Cero: fotos, facturas y backups
9. Práctica: MinIO, mc y servicios/catalogo/fotos.py con boto3
10. Errores Comunes y Consejos
11. Ejercicios
12. Conclusión

Hay tres formas de presentar el almacenamiento a un programa, y conviene distinguirlas antes de nada:

La columna de "modificación" es la que lo cambia todo: un objeto es inmutable. Para cambiar un byte se sube un objeto nuevo con la misma clave. Esa inmutabilidad simplifica la replicación (dos copias de un objeto son idénticas o una de ellas es de otra versión, no hay estados intermedios) y es la razón de que los almacenes de objetos escalen tanto y cuesten tan poco. También es la razón de casi todas sus limitaciones (apartado 6).

• Bucket: contenedor de nivel superior, con nombre único (en S3, único a nivel global; en MinIO, por despliegue). Un bucket tiene región, política de acceso, configuración de versionado y reglas de ciclo de vida. Kilómetro Cero usará km0-fotos, km0-facturas y km0-backups.
• Clave (key): el nombre del objeto dentro del bucket, una cadena de hasta 1024 bytes. No hay directorios: fotos/queso-curado/original.jpg es una única cadena, y la barra no significa nada para el sistema. Las consolas y herramientas muestran "carpetas" agrupando por prefijo, pero es una ilusión: listar "la carpeta fotos/queso-curado/" es una operación LIST con prefix=fotos/queso-curado/.
• Datos: de 0 bytes a 5 TB (S3). Opacos: el sistema no interpreta el contenido.
• Metadatos: del sistema (Content-Type, Content-Length, Last-Modified, ETag) y del usuario (x-amz-meta-productor: queseria-montblanc, hasta 2 KB en total). Los metadatos viajan con el objeto y se recuperan con HEAD sin descargar los datos. No se pueden modificar sin reescribir el objeto (se hace con una copia sobre sí mismo).
• Versionado: si el bucket lo activa, cada PUT sobre una clave existente no la sobrescribe sino que crea una nueva versión con su VersionId, y DELETE no borra sino que coloca un marcador de borrado encima. Las versiones anteriores siguen ahí y se pueden recuperar: es la protección más sencilla contra el borrado accidental y contra un proceso que sube ficheros corruptos.
• Ciclo de vida (lifecycle): reglas declarativas por prefijo o etiqueta: "los objetos con la etiqueta tipo=miniatura y más de 90 días pasan a clase de almacenamiento fría", "las versiones no actuales se borran a los 30 días", "las subidas multipart incompletas se abortan a los 7 días". El sistema las aplica solo, sin código.
• Clases de almacenamiento: el mismo objeto puede vivir en niveles con distinto coste y tiempo de acceso: estándar (milisegundos), acceso infrecuente (más barato por GB, más caro por lectura), archivo (S3 Glacier: horas para recuperar, centavos por TB). MinIO implementa tiering hacia otro almacén remoto.
• Etiquetas (tags): pares clave-valor para clasificar objetos (campaña=semana-del-queso-artesano) y dirigir las reglas de ciclo de vida y las políticas de acceso.

Amazon lanzó S3 en 2006 con una API REST sencilla, y hoy prácticamente todos los almacenes de objetos la implementan: MinIO, Ceph RGW, Google Cloud Storage (modo interoperable), Backblaze B2, Cloudflare R2, Wasabi… Aprender S3 es aprender todos. Las operaciones básicas:

Dos conceptos que merecen detalle:

ETag. Cada objeto tiene una etiqueta de entidad que cambia si cambia el contenido. Para subidas simples es el MD5 del contenido ("9e107d9d372bb6826bd81d3542a419d6"), lo que permite verificar la integridad de una subida comparando el MD5 local con el ETag devuelto. Para subidas multipart es el MD5 de los MD5 de las partes seguido de -N (número de partes), así que no sirve como suma del fichero entero. Se usa también en lecturas condicionales: la web pide GET con If-None-Match: "<etag>" y recibe 304 Not Modified si la foto no ha cambiado.

URLs prefirmadas. El almacén de objetos no debería ser accesible públicamente, y la web de Kilómetro Cero no quiere hacer de proxy de cada foto (pagaría el ancho de banda dos veces y añadiría latencia). La solución es que el servicio catalogo, que sí tiene credenciales, firme una URL de descarga con una caducidad (por ejemplo 15 minutos) y se la dé al navegador; el navegador descarga directamente del almacén, que verifica la firma y la fecha. El mismo mecanismo funciona para subidas: la Quesería Montblanc recibe una URL prefirmada de PUT y sube su foto directamente al bucket sin pasar por catalogo. La firma (Signature V4) es un HMAC-SHA256 de la petición canónica con la clave secreta; el servidor la recalcula y compara. Es un ejemplo perfecto de capacidad (capability): un permiso portátil y limitado, sin cuentas ni sesiones, tema que reaparecerá en 06-01.

S3 anuncia una durabilidad del 99,999999999 % anual ("once nueves"): si guardas 10 millones de objetos, la expectativa es perder uno cada 10 000 años. No es una cifra de disponibilidad (esa es del 99,9 %–99,99 %); es la probabilidad de que los bytes sigan existiendo. Se consigue con dos técnicas.

Replicación. N copias completas en N dominios de fallo distintos (discos, servidores, racks, centros de datos). Con 3 copias se tolera la pérdida de 2 y el sobrecoste es del 200 % (3 bytes guardados por cada byte útil). Es lo que hace HDFS (04-02) y es simple y rápida de leer (cualquier copia sirve).

Codificación de borrado (erasure coding). En lugar de copiar, se divide el objeto en k fragmentos de datos y se calculan m fragmentos de paridad, de modo que cualesquiera k de los k+m fragmentos bastan para reconstruir el objeto. Se toleran m pérdidas con un sobrecoste de solo m/k. El algoritmo habitual es Reed-Solomon, la misma familia de códigos que usan los CD, los QR y las comunicaciones espaciales.

La intuición, sin álgebra de cuerpos finitos: piensa en k = 2 datos, d1 y d2, y m = 2 paridades:

Guardamos [d1, d2, p1, p2] en cuatro discos. Si perdemos d1 y d2 (los dos de datos), tenemos dos ecuaciones y dos incógnitas: d2 = p2 − p1, d1 = p1 − d2. Si perdemos d1 y p2: d1 = p1 − d2. Cualquier pareja de supervivientes basta. Reed-Solomon generaliza esto a cualquier k y m con coeficientes elegidos para que todo subconjunto de k fragmentos sea resoluble, operando en un cuerpo finito (GF(2⁸)) para que las sumas y multiplicaciones se hagan sobre bytes sin desbordar. Un ejemplo numérico con enteros para ver que funciona:

Comparemos configuraciones reales para 1 TB de datos útiles:

El precio de la codificación de borrado es la reconstrucción: para leer un objeto hay que reunir k fragmentos de k nodos (más latencia que leer una copia), y para reparar un disco perdido hay que leer k fragmentos de cada objeto afectado (mucho tráfico de red). Por eso los sistemas la usan para datos grandes y fríos, y mantienen replicación (o cachés, 04-05) para lo pequeño y caliente; muchos hacen ambas cosas: replicación para objetos pequeños y erasure coding a partir de cierto tamaño.

Los once nueves se calculan combinando la probabilidad de fallo anual de un disco (1–3 %), el tiempo de reconstrucción tras un fallo (horas) y el número de fallos simultáneos que hacen falta para perder datos (m+1 en el mismo grupo dentro de esa ventana). Con RS(8,4) y reparación en horas, esa coincidencia es astronómicamente improbable. A ello se suman las sumas de comprobación por fragmento y el scrubbing: un proceso de fondo relee todo periódicamente para detectar corrupción silenciosa (bit rot) y repararla antes de que se acumulen fallos.

Durante 14 años, S3 fue eventualmente consistente para sobrescrituras y borrados: tras un PUT sobre una clave existente, un GET podía devolver la versión anterior durante unos segundos; tras un DELETE, un LIST podía seguir mostrando la clave. En diciembre de 2020 Amazon anunció consistencia fuerte read-after-write para todas las operaciones: cualquier GET, HEAD o LIST posterior a un PUT o DELETE confirmado ve el nuevo estado. En el vocabulario de 03-01, cada objeto es linealizable, y en el de 03-02, S3 es CP (una escritura no se confirma hasta que el quórum de réplicas la tiene). MinIO ofrece la misma garantía dentro de un despliegue, y Ceph RGW también.

No todos los proveedores lo hacen: algunos almacenes compatibles con S3 y las configuraciones de replicación entre regiones son eventuales (la copia en la otra región tarda segundos o minutos). Y hay un matiz importante incluso con consistencia fuerte: no hay transacciones entre objetos. Subir original.jpg y luego miniatura-300.jpg son dos operaciones independientes; un lector puede ver la primera y no la segunda. Si la aplicación necesita que aparezcan juntas, sube primero las miniaturas y al final el objeto "índice" que las referencia, o guarda la referencia en la base de datos solo cuando todas las subidas han terminado.

Por último, las cachés delante del almacén (una CDN, tema de 08-04, o un navegador con Cache-Control) reintroducen la consistencia eventual por su cuenta: reemplazar original.jpg no vacía la CDN. Por eso la práctica común es no sobrescribir claves de contenido: se sube original-v3.jpg (o se usa un hash del contenido como parte de la clave) y se actualiza la referencia. La inmutabilidad del objeto se extiende así a la clave.

Un almacén de objetos encaja cuando los datos son:

• Inmutables o de sustitución completa: fotos, vídeos, PDF, backups, ficheros de eventos cerrados, artefactos de compilación, modelos entrenados.
• Grandes en volumen total, con acceso por clave conocida o por prefijo.
• Servidos por HTTP a navegadores, apps o a otros servicios, a menudo con CDN delante.
• Tolerantes a decenas de milisegundos por operación.

Y no encaja cuando hace falta:

• Semántica de ficheros: seek y escritura parcial, append, bloqueos, directorios reales. Los sistemas que montan S3 como disco (s3fs, Mountpoint) funcionan para lecturas, pero cada escritura reescribe el objeto entero.
• Renombrado atómico. mv fotos/tmp/x.jpg fotos/queso-curado/original.jpg en un sistema de ficheros es una operación atómica de metadatos; en S3 es CopyObject + DeleteObject, dos operaciones, sin atomicidad y con coste proporcional al tamaño. Mover un "directorio" de un millón de objetos es un millón de copias. Muchos motores de procesamiento (Módulo 5) tuvieron problemas por esto al pasar de HDFS a S3, y por eso existen formatos de tabla (Iceberg, Delta) que evitan renombrar.
• Latencia baja y muchas operaciones pequeñas: leer 10 000 objetos de 1 KB son 10 000 peticiones HTTP; una base de datos (04-04) o una caché (04-05) lo hace mil veces más rápido.
• Listados frecuentes y grandes: LIST está paginado a 1000 y es la operación más lenta; la aplicación debe guardar en su base de datos qué objetos existen, no descubrirlos listando.
• Datos que cambian a menudo: cada cambio es una versión nueva del objeto completo.

Los almacenes de objetos en la nube cobran por tres conceptos, y el tercero sorprende a muchos equipos:

El egress es la razón principal de poner una CDN delante (08-04): la CDN cachea las fotos en sus bordes y el bucket solo paga el primer envío a cada borde. También es la razón de que mover datos entre nubes sea caro y de que el lago de datos (04-02) y el cómputo (Módulo 5) deban estar en la misma región. Algunos proveedores (R2, B2) no cobran egress, y un MinIO propio cambia el modelo: no hay coste por GB servido, pero hay discos, servidores y personal que operarlos.

Tres tipos de datos de la plataforma se van al almacén de objetos:

Las fotos son el caso principal. El flujo completo, desde que la Quesería Montblanc elige una foto en su panel hasta que Ana la ve en la web:

catalogo nunca toca los bytes de la foto: firma, valida y guarda referencias. Es el patrón habitual y el que permite que el almacén, no el servicio, absorba el ancho de banda.

MinIO es un almacén de objetos de código abierto compatible con S3, escrito en Go, que se despliega en un solo binario. En producción se ejecuta en modo distribuido (varios nodos, varios discos por nodo, codificación de borrado automática); para km0/ basta un nodo con un volumen. Añadimos al docker-compose.yml:

mc (MinIO Client) es la CLI, que funciona con cualquier S3. Los comandos útiles desde tu máquina:

boto3 es el SDK oficial de AWS para Python y, gracias a la compatibilidad de MinIO, funciona con solo cambiar endpoint_url. El módulo servicios/catalogo/fotos.py concentra todo lo que catalogo necesita:

Comentarios sobre las partes menos evidentes:

• Config(signature_version="s3v4", s3={"addressing_style": "path"}): MinIO local no tiene DNS con comodines, así que el bucket va en el path (/km0-fotos/…) y no en el host (km0-fotos.localhost). Signature V4 es la que usan las URLs prefirmadas modernas.
• subir_foto comprueba el ETag contra el MD5 local: si la red corrompió algo, se detecta al momento. Con put_object (subida simple) esta igualdad se cumple; con multipart no, como vimos en el apartado 3. Para fotos de más de 100 MB, usa s3.upload_file, que hace multipart automáticamente con reintentos por parte.
• CacheControl: immutable: como prometimos no sobrescribir contenido que la CDN vaya a cachear, podemos dejar cachear un año. Cuando la quesería cambie la foto, la nueva versión tendrá otro VersionId y, en la práctica de Kilómetro Cero, la web referenciará original.jpg?v=<etag> para que la URL cambie.
• url_descarga no habla con el servidor: generate_presigned_url calcula la firma localmente con la clave secreta. Es instantáneo y no consume una operación del bucket. Nota que el ExpiresIn no puede superar 7 días con Signature V4.
• url_subida incluye ContentType y Metadata en los parámetros firmados: el productor debe enviar exactamente esas cabeceras, o la firma no cuadra. Es la manera de forzar que la subida lleve los metadatos que catalogo decidió.
• restaurar_version muestra el truco de "modificar" un objeto inmutable: copiarlo sobre sí mismo desde la versión deseada, lo que crea una versión nueva con el contenido antiguo.
• configurar_ciclo_vida: StorageClass en MinIO se refiere a un nivel de tiering definido con mc ilm tier add (por ejemplo, otro MinIO con discos lentos o un S3 Glacier); en S3 se usaría STANDARD_IA o GLACIER. La regla de multipart abandonadas evita pagar por partes huérfanas que nadie ve en los listados.

Prueba rápida en dos líneas:

El curl -I devuelve 200 OK con Content-Type: image/jpeg, ETag, x-amz-meta-productor: queseria-montblanc y Cache-Control. Espera 15 minutos y repite: 403 Forbidden con Request has expired. Esa es la URL prefirmada funcionando.

• Pensar en carpetas. No existen. LIST por prefijo es lento y paginado; guarda en la base de datos qué claves tiene cada producto en lugar de listar el bucket en cada página vista.
• Sobrescribir claves que una CDN o un navegador cachean. El bucket será consistente; las cachés no. Cambia la clave (hash o versión en el nombre) y actualiza la referencia.
• Exponer credenciales al navegador o al productor. Nunca. Firma URLs desde el servicio, con caducidad corta y los parámetros que quieres forzar incluidos en la firma.
• Buckets públicos "para que funcione". Un bucket público con LIST habilitado es la fuga de datos más común de la nube. mc anonymous set none y URLs prefirmadas o CDN con firma.
• Usar rename o mover prefijos grandes. No hay renombrado: es copia + borrado por objeto. Diseña las claves para no tener que moverlas.
• Confiar en el ETag como MD5 de subidas multipart. No lo es. Si necesitas un hash del fichero completo, calcúlalo y guárdalo como metadato (x-amz-meta-sha256) o usa las sumas de comprobación de objetos completos (ChecksumAlgorithm).
• Olvidar el egress y las operaciones en el presupuesto. Servir fotos directamente desde el bucket a miles de usuarios cuesta más que almacenarlas; la CDN (08-04) es una decisión económica antes que de latencia.
• Sin versionado ni ciclo de vida. El versionado es un seguro barato contra borrados accidentales; el ciclo de vida evita que las versiones y las multipart abandonadas crezcan sin límite. Actívalos el primer día.

Ejercicio 1. Kilómetro Cero tiene 4 200 productos con 3 variantes de foto (original 1,8 MB, miniatura-800 180 KB, miniatura-300 35 KB) y 2 000 productores. Durante la Semana del Queso Artesano la web sirve 6 millones de vistas de producto al día, cada una con una miniatura-800. (a) Calcula el almacenamiento total en el bucket y su coste mensual a 0,02 €/GB. (b) Calcula el egress diario y mensual a 0,08 €/GB si se sirve directamente desde el bucket. (c) ¿Qué porcentaje del tráfico habría que servir desde una CDN para que el egress del bucket baje al 5 % del cálculo anterior, y qué cambio en las claves lo hace posible sin riesgo de servir fotos obsoletas?

Ejercicio 2. Implementa generar_miniaturas(slug) en fotos.py: descarga original.jpg en memoria con get_object, genera las variantes de 800 y 300 px con Pillow y las sube con subir_foto reutilizando los metadatos del original (léelos con head_object). Luego describe qué puede ver la web si un usuario carga la página de queso-curado justo entre la subida del original y la de las miniaturas, y cómo evitarías mostrar una imagen rota.

Ejercicio 3. Con RS(k=4, m=2) sobre 6 discos, un objeto de 24 MB se divide en 4 fragmentos de datos de 6 MB y 2 de paridad. (a) ¿Cuántos bytes ocupa en total y cuál es el sobrecoste frente a 3 réplicas? (b) Si fallan dos discos, ¿cuántos MB hay que leer para reconstruir el objeto en una lectura, y cuántos para reparar un solo fragmento perdido de ese objeto? (c) Explica por qué MinIO, con 6 discos, usa por defecto RS(3,3) (paridad = mitad) en lugar de RS(4,2) y qué se gana y se pierde.

Solución 1:

(a) Por producto: 1,8 MB + 0,18 MB + 0,035 MB ≈ 2,0 MB. Total: 4 200 × 2,0 MB ≈ 8,5 GB (más versiones no actuales durante 30 días; supongamos un 20 % extra: ~10 GB). Coste: 10 GB × 0,02 € ≈ 0,20 €/mes. El almacenamiento es irrelevante.

(b) Egress diario: 6 000 000 × 180 KB ≈ 1,08 TB/día; mensual ≈ 32 TB. A 0,08 €/GB: ≈ 86 €/día, 2 600 €/mes. Trece mil veces el coste de almacenar. Las operaciones GET (6 M/día × 0,4 €/M ≈ 2,4 €/día) también superan al almacenamiento.

(c) Para que el bucket sirva solo el 5 %, la CDN debe atender el 95 % de las peticiones desde caché (hit ratio ≥ 95 %), lo que es realista con 4 200 objetos pequeños y Cache-Control: max-age=31536000, immutable. La condición para que ese max-age de un año sea seguro es que la clave (o la URL) cambie cuando cambie el contenido: fotos/queso-curado/miniatura-800.jpg?v=<etag> o fotos/queso-curado/<etag>/miniatura-800.jpg. Con claves inmutables no hay que invalidar la CDN nunca; se detallará en 08-04.

Solución 2:

(Se reutiliza subir_foto, que ya fija variante en los metadatos.) Entre la subida del original y la de las miniaturas, el bucket contiene original.jpg pero no miniatura-800.jpg: la web, que pide una URL prefirmada de la miniatura, obtendría una URL válida pero el GET devolvería 404 NoSuchKey y el navegador mostraría la imagen rota. El almacén es consistente por objeto, pero no hay transacción entre objetos (apartado 5). Solución: catalogo no marca la foto como "disponible" en km0_catalogo (ni publica foto.subida para la web) hasta que el generador confirma las miniaturas; mientras tanto la web muestra la foto anterior o una imagen de relleno. Alternativa más robusta: el generador sube las miniaturas antes de que se actualice la referencia, y la referencia (en la base de datos) es el único "commit" visible.

Solución 3:

(a) 4 × 6 MB + 2 × 6 MB = 36 MB para 24 MB útiles: sobrecoste del 50 %. Con 3 réplicas serían 72 MB (200 %): la codificación de borrado ahorra la mitad del disco tolerando las mismas 2 pérdidas.

(b) Para leer el objeto hacen falta 4 fragmentos cualesquiera: 24 MB leídos de 4 discos (con los dos fallos, exactamente los 4 supervivientes). Para reparar un solo fragmento perdido de 6 MB hay que leer 4 fragmentos (24 MB) y recalcular: el coste de reparación es k veces el tamaño del fragmento, que es la penalización característica del erasure coding frente a la réplica (donde reparar 6 MB cuesta leer 6 MB).

(c) Con RS(3,3), cada objeto tolera la pérdida de 3 discos de 6 (la mitad), con sobrecoste del 100 %; con RS(4,2) tolera 2, con sobrecoste del 50 %. MinIO elige por defecto la configuración más segura (y con 6 discos, dos fallos simultáneos no son tan raros durante una ventana de reparación larga), y deja que el operador baje la paridad (MINIO_STORAGE_CLASS_STANDARD=EC:2) cuando prefiere capacidad. Se gana tolerancia a fallos y lecturas que necesitan solo 3 fragmentos; se pierde el 50 % adicional de disco.

El almacenamiento de objetos cambia el contrato del almacenamiento: buckets y claves planas en lugar de directorios, objetos inmutables que se reemplazan enteros, metadatos que viajan con los datos, versionado y reglas de ciclo de vida que el sistema aplica solo. La API S3 (PUT/GET/HEAD/LIST, multipart, ETag, URLs prefirmadas) es el estándar que MinIO, Ceph y el resto implementan. La durabilidad de once nueves se consigue combinando replicación con codificación de borrado, donde Reed-Solomon reconstruye un objeto a partir de cualesquiera k de sus k+m fragmentos con un sobrecoste del 33–50 % en lugar del 200 % de tres copias, a cambio de lecturas y reparaciones más costosas. S3 y MinIO son hoy fuertemente consistentes por objeto, pero no hay transacciones entre objetos ni renombrado atómico, y las cachés delante del bucket devuelven la consistencia eventual, por lo que la buena práctica es no sobrescribir claves. El egress, no el almacenamiento, domina la factura, y esa es la razón económica de la CDN que veremos en 08-04. Kilómetro Cero ha destinado a objetos sus fotos (km0-fotos, con fotos.py, subida directa de la Quesería Montblanc por URL prefirmada y servicio a la web con URLs de 15 minutos), sus facturas y sus backups, y lo ha montado con MinIO y mc en docker-compose.yml.

Ya tenemos dónde guardar ficheros masivos (HDFS) y ficheros que se sirven (objetos). Falta el almacenamiento que mueve la plataforma cada segundo: registros pequeños, consultados y actualizados con baja latencia, con transacciones y con las garantías de consistencia que elegimos en 03-02. Ese es el terreno de las bases de datos distribuidas, donde pedidos migrará a Cassandra, inventario se quedará en PostgreSQL, y el anillo de hashing consistente de 04-01 reaparecerá con réplicas y niveles de consistencia por operación.