Almacenamiento de objetos vs bloques vs archivos

Cuando alguien dice "necesito storage", puede referirse a tres cosas muy distintas. Una base de datos quiere un disco rápido. Un equipo quiere una carpeta compartida. Un sitio quiere servir miles de imágenes. Cada necesidad pide un modelo propio, y elegir mal sale caro en rendimiento o en complejidad.

Los tres modelos son block storage (bloques), file storage (archivos) y object storage (objetos). La diferencia está en quién organiza los datos y en cómo accedes a ellos.

¿Cómo guarda los datos cada tipo de almacenamiento?#

Bloques. Los datos se dividen en bloques de tamaño fijo, cada uno con una dirección. Lees y escribes bloques individuales de forma directa. El resultado es un dispositivo en bruto, sin carpetas: el sistema operativo lo formatea con un sistema de archivos (ext4, XFS, NTFS) y lo usa como disco. La documentación de Amazon EBS lo describe así: un dispositivo de bloques que conectas a una instancia y usas como un disco duro físico.

Archivos. Los datos viven en una jerarquía de carpetas y archivos, con nombres, rutas y permisos de usuario y grupo. La diferencia con los bloques es que el sistema de archivos ya viene listo y se puede compartir: varios servidores montan la misma carpeta por la red, normalmente con NFS o SMB. Amazon EFS, por ejemplo, usa NFS 4 y permisos POSIX.

Objetos. Cada archivo se convierte en un objeto: el contenido, una clave única y metadatos. Los objetos viven en un espacio plano (un bucket) y se accede a ellos mediante una API HTTP, con operaciones como PUT, GET y DELETE. No hay disco montado ni carpetas reales. Encontrarás los detalles en qué es el almacenamiento de objetos.

¿Qué cambia en la práctica?#

El mismo archivo, dos formas de acceder:

import os

import boto3


def editar_en_disco():
    # Bloque o archivo: el sistema operativo te da una ruta montada.
    # Abres el archivo y escribes en medio de él.
    with open("/datos/reporte.csv", "r+b") as f:
        f.seek(1024)
        f.write(b"nuevo contenido")  # cambia solo esos bytes


def subir_como_objeto():
    # Objeto: no hay ruta montada, solo una clave y una API HTTP.
    # Para cambiar un byte, subes el objeto completo otra vez.
    s3 = boto3.client(
        "s3",
        endpoint_url=os.environ["S3_ENDPOINT"],
        aws_access_key_id=os.environ["S3_ACCESS_KEY"],
        aws_secret_access_key=os.environ["S3_SECRET_KEY"],
    )
    with open("reporte.csv", "rb") as f:
        s3.put_object(Bucket="mi-bucket", Key="reportes/reporte.csv", Body=f)

En el primer caso, el programa usa llamadas del sistema de archivos y cambia bytes en el lugar. En el segundo, cada operación es una solicitud de red que lee o reemplaza el objeto completo. Por eso un programa escrito para disco no funciona en object storage sin adaptarlo, y lo mismo pasa al revés.

Tabla comparativa#

AWS describe el block storage como de baja latencia, el file storage como el más indicado para acceso compartido y el object storage como de escala casi ilimitada, con más latencia en el acceso. Las cifras varían según el proveedor y el tipo de volumen, así que consulta la documentación del servicio que vayas a usar.

¿Cuándo elegir cada uno?#

Elige bloques cuando una aplicación necesita un disco rápido y dedicado: bases de datos, sistemas con muchas lecturas y escrituras pequeñas y el disco del sistema operativo. Por lo general el volumen se conecta a un servidor a la vez, con excepciones en algunos proveedores, como el Multi-Attach de EBS.

Elige archivos cuando varios servidores deben ver el mismo árbol de carpetas a la vez, con permisos y semántica de sistema de archivos. Ejemplos: un directorio de uploads compartido entre réplicas de una aplicación heredada o un repositorio multimedia editado por un equipo.

Elige objetos cuando guardas muchos archivos que se suben y descargan completos: avatares, imágenes de producto, videos, PDFs, logs archivados, exportaciones. Es el mejor punto de partida para contenido que crece sin límite definido y debe servirse por internet. Para decidir dónde guardar las imágenes, consulta imágenes en la base de datos o en object storage.

Combina los tres. Las aplicaciones reales mezclan tipos: la base de datos corre sobre bloques y las imágenes que suben los usuarios van a object storage, con solo la clave guardada en la base. No hay un ganador universal, solo el tipo correcto para cada dato.

¿El object storage reemplaza el disco de la aplicación?#

No para todo. Si tu código abre archivos por ruta y escribe en medio de ellos, necesita un disco o un sistema de archivos. Pero si el disco del servidor solo guarda uploads, pasarlos a object storage resuelve tres problemas a la vez: el espacio deja de acabarse, los archivos sobreviven a la recreación del servidor y varias instancias ven los mismos datos.

Como la API de Amazon S3 se volvió un estándar de facto, muchos proveedores ofrecen storage compatible. Eso permite cambiar de proveedor modificando, por lo general, el endpoint y las credenciales. Consulta qué es el storage compatible con S3.

Cómo hacerlo en Square Cloud#

Para el caso de los objetos, Square Cloud ofrece el Blob Storage: object storage con API compatible con S3 (aws-cli, rclone, boto3 y los SDKs de AWS), además de API REST y panel. La función subir_como_objeto del ejemplo de arriba sirve de base: define S3_ENDPOINT como https://s3-blob.squarecloud.app y completa S3_ACCESS_KEY y S3_SECRET_KEY con las claves de la pestaña "Acceso S3" del panel.

Los archivos pueden pesar hasta 10 GB, y la carga multipart solo es obligatoria por encima de 100 MB. No hay tarifa de salida ni de entrada, y todo plan incluye una cuota de 5 GB a 250 GB. Los archivos públicos se sirven desde una CDN global en el edge, y los privados se abren con un enlace temporal o un enlace para compartir. También puedes definir reglas por carpeta, como caducidad, caché y extensiones permitidas.

Conoce el servicio en Blob Storage.