Almacenamiento de objetos para cargas de trabajo de IA
Almacenamiento de objetos para cargas de trabajo de IA
El almacenamiento de objetos almacena datos como objetos autocontenidos en lugar de como archivos en carpetas o bloques en un disco. Está diseñado para datos no estructurados: fotos, video, audio, correo electrónico, páginas web, lecturas de sensores y los embeddings vectoriales que producen las aplicaciones de IA.
Un almacén de objetos en la nube distribuye estos datos entre muchas máquinas, pero te permite acceder a todos ellos como un único grupo mediante una API HTTP. Cada objeto contiene tres cosas: los datos en sí, cualquier metadato que añadas y un ID único. Puedes recuperar o analizar cualquier objeto mediante ese ID, sea cual sea su tipo de archivo.
Amazon S3, el primer almacén de objetos en la nube, ahora contiene más de 500 billones de objetos. Se ha convertido en la capa de almacenamiento predeterminada de la nube.
Cómo funciona el almacenamiento de objetos
Tres modelos de almacenamiento gestionan los datos de manera diferente. Un sistema de archivos coloca los datos en carpetas anidadas. El almacenamiento en bloques divide los datos en bloques de tamaño fijo en un disco. El almacenamiento de objetos mantiene cada elemento completo en un contenedor plano llamado bucket, sin carpetas.
Para almacenar un archivo, el sistema toma los datos, añade cualquier metadato que le proporciones y adjunta un ID. Luego las aplicaciones leen, escriben y eliminan objetos mediante ese ID a través de una API HTTP. No hay ruta de archivo ni punto de montaje.
PUT /my-bucket/embedding-batch-042.parquet # almacenar un objeto
GET /my-bucket/embedding-batch-042.parquet # recuperarlo por ID
DELETE /my-bucket/embedding-batch-042.parquet # eliminarlo
La estructura plana es lo que hace que el almacenamiento de objetos escale. Añades capacidad agregando máquinas al grupo, no reestructurando un árbol de carpetas, por lo que un solo bucket puede crecer casi sin límite. Amazon S3, lanzado en 2006, estableció la API que el resto de la industria copió, y Ceph, MinIO y OpenStack Swift son todos compatibles con S3, al igual que las otras grandes nubes.
| Servicio | Proveedor | Estándar de API |
|---|---|---|
| Amazon S3 | AWS | S3 (el estándar de facto) |
| Cloud Storage | Google Cloud | interoperable con S3 + nativo |
| Blob Storage | Microsoft Azure | Nativo + puertas de enlace compatibles con S3 |
| MinIO / Ceph | Autoalojado (código abierto) | compatible con S3 |
Características y limitaciones clave
El diseño del almacenamiento de objetos le da un conjunto claro de fortalezas y un conjunto claro de límites.
Características clave
- Escala casi sin límite. Un solo bucket contiene tantos objetos como necesites. Añades capacidad escribiendo más datos y pagas solo por lo que almacenas, sin tener que dimensionar un clúster de antemano.
- Duradero y resiliente. Los almacenes de objetos mantienen copias de cada objeto en varias máquinas, a menudo entre centros de datos o regiones. Amazon S3 está diseñado para once nueves (99.999999999%) de durabilidad, con cada objeto almacenado en al menos tres Zonas de disponibilidad.
- Barato, con niveles. Los precios por gigabyte están muy por debajo del almacenamiento en bloques o de archivos, y los datos fríos se trasladan automáticamente a niveles más baratos.
- Contiene cualquier dato, con metadatos ricos. Un bucket puede contener cualquier tipo de dato no estructurado, y cada objeto lleva metadatos que tú defines. Puedes encontrar y filtrar objetos por esos metadatos, sea cual sea el tipo de archivo.
- Abierto y fácil de acceder. Los objetos se leen mediante una API HTTP sencilla. La API de S3 es un estándar de facto, por lo que muchas herramientas leen los mismos buckets sin conectores especiales.
Limitaciones
- Más lento que el almacenamiento en bloques. Cada solicitud pasa por HTTP, por lo que el almacenamiento de objetos no encaja bien con trabajos de baja latencia y acceso aleatorio ni con bases de datos transaccionales.
- Sin edición in situ. Reemplazas un objeto completo en lugar de cambiar parte de él, lo que hace que el almacenamiento de objetos no sea adecuado para datos que cambian con frecuencia.
- Las lecturas pequeñas se encarecen. Una carga de trabajo que realiza muchas lecturas diminutas puede acumular grandes cargos de API incluso cuando los datos en sí son pequeños.
- Sin búsqueda ni cómputo integrados. El almacenamiento de objetos almacena y sirve bytes. No tiene índice, ni búsqueda, ni analítica. Cualquier cosa más allá de "recupera este objeto por ID" necesita un motor de consulta encima. Esa última brecha es la razón por la que el almacenamiento de objetos es la base para los datos de IA, pero no puede, por sí solo, servir búsqueda de IA.
Casos de uso y el puente hacia la IA
La escala, la durabilidad y el bajo costo del almacenamiento de objetos lo convierten en el destino predeterminado para muchas cargas de trabajo:
- Lagos de datos (la base de almacenamiento estándar)
- Copias de seguridad y recuperación ante desastres
- Archivos a largo plazo
- Almacenamiento y entrega de medios
- Registros y datos de analítica
- Conjuntos de entrenamiento de ML (los grandes conjuntos de datos de los que aprenden los modelos)
La búsqueda con IA ahora le está pidiendo al almacenamiento de objetos que haga más que guardar datos. Los embeddings son los vectores numéricos detrás de la búsqueda semántica y la generación aumentada por recuperación (RAG). Hay enormes cantidades de ellos, cada uno es grande, y almacenarlos en una base de datos especializada resulta caro.
Por eso los equipos han empezado a mantener los embeddings directamente en el almacenamiento de objetos. Amazon S3 Vectors, disponible de forma general desde diciembre de 2025, añade almacenamiento y búsqueda vectorial nativos a S3. AWS afirma que reduce el costo de almacenar y consultar vectores hasta en un 90% frente a las bases de datos vectoriales especializadas, admite hasta dos mil millones de vectores por índice y responde a consultas frecuentes en unos 100 milisegundos y a las poco frecuentes en menos de un segundo.
El problema es la velocidad. El almacenamiento de objetos ahora puede guardar y buscar vectores de forma económica, pero responder a una búsqueda rápidamente, mientras los datos permanecen en el almacenamiento de objetos y nunca se copian en un almacenamiento rápido separado, es la parte difícil.
Almacenamiento de objetos en la infraestructura de IA
El almacenamiento de objetos tiene una brecha real para la IA: no tiene forma de buscar en sí mismo. Los embeddings se alojan en él de forma económica, pero una búsqueda por similitud te deja dos malas opciones. Copiar los datos en una base de datos vectorial dedicada, y ahora mantienes dos copias, pagas dos facturas y tienes que mantenerlas sincronizadas. Buscar en los archivos sin procesar sin índice, y es demasiado lento para producción.
La solución es darle al almacenamiento de objetos lo único que le falta: una forma de buscar los datos donde residen. Eso requiere tres piezas, ninguna de las cuales viene integrada:
- Índices junto a los datos. Los índices vectoriales viven en el almacenamiento de objetos, junto a los datos, en lugar de en un sistema separado.
- Lecturas que recuperan solo lo que necesitan. El motor de consultas extrae solo las páginas de índice y los fragmentos de datos que toca una consulta, no archivos completos.
- Una caché delante. La memoria o el SSD local se sitúa delante del almacenamiento de objetos para que los datos activos se sirvan sin un viaje de ida y vuelta.
En conjunto, esto te permite buscar directamente en el almacenamiento de objetos en lugar de tratarlo como un almacén pasivo.
Zilliz Vector Lakebase es un sistema construido de esta manera. Mantiene los datos y los índices en el almacenamiento de objetos, separados del cómputo que los consulta. Varios clústeres de cómputo pueden leer la misma copia de los datos a la vez, para servicio, descubrimiento o analítica, sin duplicarla. Su función External Collections apunta a tablas de lago que ya tienes, ya sea en Lance, Iceberg, Parquet o su propio formato Vortex, y ejecuta búsquedas vectoriales contra ellas in situ.
En el benchmark de Zilliz sobre una tabla Iceberg de mil millones de vectores, la velocidad depende de cómo se almacenen en caché los datos:
- Sin índice (escaneo Spark por fuerza bruta): horas
- En frío (índice recién creado, en unos 20 minutos): ~30 segundos
- Templado (desde la caché de SSD local): decenas de milisegundos
- En caliente (desde la memoria): milisegundos de un solo dígito
Debido a que cada consulta carga solo las páginas que necesita, Zilliz informa que reduce la amplificación de lectura (transferencia de datos desperdiciada) en más del 90%, y su formato Vortex mueve 135 veces menos datos desde S3 por lectura que Parquet.
Este patrón es más grande que cualquier producto individual. El almacenamiento de objetos se está convirtiendo en un lugar donde los datos de IA se buscan directamente, además de ser donde se almacenan.
Preguntas frecuentes
¿Es bueno el almacenamiento de objetos para las cargas de trabajo de IA?
Sí, para almacenar datos de entrenamiento, embeddings y artefactos de modelos a escala, donde su durabilidad, capacidad casi ilimitada y bajo costo compensan. El límite es la velocidad: para buscar esos datos rápidamente, necesitas un índice y cómputo sobre el almacenamiento sin procesar.
¿Cuál es la diferencia entre el almacenamiento de objetos y una base de datos vectorial?
El almacenamiento de objetos es un almacén general para cualquier dato no estructurado, al que se accede por ID. Una base de datos vectorial está diseñada para la búsqueda por similitud sobre embeddings, con índices optimizados para consultas rápidas de vecinos más cercanos. Ambos están convergiendo: los equipos cada vez más mantienen los vectores en el almacenamiento de objetos y añaden una capa de búsqueda sobre ellos.
¿Puedes ejecutar búsqueda vectorial directamente en el almacenamiento de objetos?
Cada vez más, sí. AWS S3 Vectors añade búsqueda vectorial nativa, y las plataformas que apuntan a tablas de lake in situ te permiten buscar datos de almacenamiento de objetos sin copiarlos fuera. Las consultas se ejecutan más lentamente que en un índice en memoria, pero el coste es mucho menor.
¿Por qué los data lakes usan almacenamiento de objetos?
Un data lake tiene que almacenar enormes volúmenes de datos estructurados y no estructurados de forma económica y duradera, en formatos abiertos, accesibles por muchos motores a la vez. El pool plano de almacenamiento de objetos, direccionado por ID, encaja mejor con eso que el almacenamiento de archivos o de bloques.
¿Es el almacenamiento de objetos más lento que el almacenamiento de bloques?
Para una sola operación, normalmente sí. El almacenamiento de bloques ofrece una latencia muy baja para trabajo transaccional y de acceso aleatorio. El almacenamiento de objetos intercambia eso por rendimiento, durabilidad y coste en objetos grandes, en su mayoría estáticos, leídos a través de HTTP. La brecha se reduce para lecturas secuenciales grandes, pero sigue siendo amplia para las pequeñas y sensibles a la latencia.
Almacenamiento de objetos para IA: próximos pasos
El almacenamiento de objetos es la base sobre la que se construye el resto de la pila de datos de IA. Para ver cómo una plataforma nativa de vectores ejecuta recuperación, descubrimiento y analíticas directamente sobre datos de almacenamiento de objetos, lee De base de datos vectorial a Vector Lakebase o explora la plataforma Zilliz Cloud.
- Cómo funciona el almacenamiento de objetos
- Características y limitaciones clave
- Casos de uso y el puente hacia la IA
- Almacenamiento de objetos en la infraestructura de IA
- Preguntas frecuentes
- Almacenamiento de objetos para IA: próximos pasos
Contenido
Comienza Gratis, Escala Fácilmente
Prueba la base de datos vectorial completamente gestionada construida para tus aplicaciones GenAI.
Prueba Zilliz Cloud Gratis