La búsqueda de incrustaciones es fácil con 10K vectores. Con 100M vectores y P99 por debajo de 100ms, es un problema de infraestructura, y eso es lo que resuelve este patrón.
Tu pipeline RAG o sistema de recomendación funciona perfectamente en desarrollo con unos pocos miles de vectores. Ahora tienes 50 millones de incrustaciones, las consultas necesitan una latencia por debajo de los 100ms, el índice sigue creciendo y estás consumiendo mucha memoria. Necesitas una arquitectura de base de datos vectorial que escale horizontalmente, gestione la memoria de manera eficiente (no todo necesita vivir en RAM), maneje escrituras concurrentes durante la ingesta sin degradar el rendimiento de las consultas y no cueste $10K/mes en infraestructura para lo que es fundamentalmente un índice de búsqueda.
Explore more design patterns and system architectures
Nuestros arquitectos pueden ayudarle a diseñar y construir sistemas utilizando este patrón para sus requisitos específicos.
Ponte en Contacto
La arquitectura de base de datos vectorial escalable aborda los desafíos de operar la búsqueda vectorial a escala de producción: particionamiento de índices entre nodos (sharding), almacenamiento por niveles (segmentos calientes en memoria, tibios en SSD, fríos en S3), enrutamiento de consultas con equilibrio de carga y autoescalado basado en la carga de consultas y el tamaño del índice. El patrón cubre la topología de despliegue, la planificación de capacidad, el aislamiento de escritura/lectura y la optimización de costos. Es la capa de infraestructura que hace que los sistemas RAG y de recomendación sean viables a escala.
La arquitectura despliega nodos de base de datos vectorial en una topología en clúster con separación entre nodos de consulta (ruta de lectura) y nodos de datos (ruta de escritura). Un pipeline de ingesta maneja la generación de incrustaciones y las inserciones masivas con búfer de escritura para evitar afectar la latencia de las consultas. Un enrutador de consultas distribuye las búsquedas entre réplicas de lectura con paralelismo a nivel de shard. El almacenamiento por niveles mueve segmentos de acceso poco frecuente de la memoria a SSD y a S3, con carga transparente en tiempo de consulta. El autoescalado ajusta el número de réplicas basándose en QPS de consulta y la latencia P99.
| Capa | Tecnologías |
|---|---|
| Base de Datos Vectorial | Milvus (distribuido), Qdrant (nodo único/clúster pequeño), Pinecone (gestionado) |
| Backend de Almacenamiento | MinIO / S3 (almacenamiento de segmentos), SSD (nivel tibio), RAM (nivel caliente) |
| Coordinación | etcd (metadatos de Milvus), Pulsar/Kafka (registro de escritura anticipada) |
| Modelos de Incrustación | OpenAI text-embedding-3-large, Cohere embed-v4, BGE-M3, E5-large-v2 |
| Infraestructura | Kubernetes (EKS/GKE) con nodos GPU para incrustación, nodos optimizados para memoria para consulta |
| Monitorización | Grafana + exportador de métricas de Milvus, paneles de control P99/recall personalizados |
| Usar Cuando | Evitar Cuando |
|---|---|
| El recuento de vectores supera los 5M y sigue creciendo, requiriendo escalado horizontal | Tienes < 1M vectores — pgvector en tu PostgreSQL existente es suficiente |
| La latencia P99 de consulta sub-100ms es un requisito estricto | La latencia de consulta de 500ms+ es aceptable — opciones más simples funcionan |
| Múltiples aplicaciones/inquilinos comparten la infraestructura vectorial | Una sola aplicación con una sola colección — usa un servicio gestionado |
| La optimización de costos requiere almacenamiento por niveles (no todo en RAM) | El presupuesto permite servicios totalmente gestionados y el precio del proveedor funciona a tu escala |
MW diseña la infraestructura de bases de datos vectoriales con un enfoque de "tamaño adecuado desde el primer día, escala cuando se mide". Comenzamos con la planificación de capacidad basada en el recuento de vectores, la dimensionalidad, el tipo de índice y la latencia objetivo, no en suposiciones. Nuestros despliegues de Milvus en Kubernetes incluyen paneles de control de Grafana que rastrean el recuento de segmentos, la utilización de la memoria, los percentiles de latencia de consulta y las estimaciones de recuperación. Hemos implementado clústeres Milvus de autoescalado que manejan picos de tráfico de 10x durante las horas de oficina y se reducen durante la noche, reduciendo el costo de infraestructura en un 40-60% en comparación con el aprovisionamiento estático.
Ofrezca a su LLM acceso a sus datos sin ajuste fino. RAG cierra la brecha entre los modelos de lenguaje de propósito general y el conocimiento específico del dominio.
MicrocosmWorks generalmente recomienda pgvector para proyectos con menos de 5-10 millones de vectores donde el equipo ya utiliza PostgreSQL, ya que evita introducir un nuevo componente de infraestructura y soporta consultas híbridas SQL-más-vector de forma nativa. Más allá de los 10 millones de vectores o cuando se necesita una latencia p99 inferior a 50 ms con alta concurrencia, una base de datos vectorial específicamente diseñada como Qdrant, Weaviate o Milvus ofrece un rendimiento significativamente mejor a través de algoritmos de indexación optimizados y búsqueda acelerada por GPU. Ayudamos a los clientes a tomar esta decisión durante la revisión de arquitectura evaluando el rendimiento de sus patrones de consulta reales y proyecciones de crecimiento.
MicrocosmWorks diseña clústeres de bases de datos vectoriales con estrategias de sharding basadas en hash o en metadatos que distribuyen vectores entre los nodos, manteniendo los datos semánticamente relacionados coubicados para una búsqueda eficiente. Implementamos capas de enrutamiento de consultas que distribuyen las solicitudes de búsqueda a los shards relevantes y fusionan los resultados utilizando una agregación top-K global, manteniendo una latencia sub-100ms incluso a través de docenas de shards. Nuestros paneles de monitoreo rastrean el equilibrio de los shards, la distribución de consultas y el retraso de replicación para evitar hotspots a medida que su conjunto de datos escala.
MicrocosmWorks aplica cuantificación escalar (reduciendo de float32 a int8) y cuantificación de producto para comprimir el almacenamiento de vectores en un factor de 4 a 8x con típicamente menos del 2% de degradación en el recall, lo cual validamos mediante pruebas A/B en su carga de trabajo de consultas real antes de desplegar a producción. También implementamos un enfoque de recuperación de dos etapas donde los vectores cuantificados sirven para la recuperación inicial de candidatos y los vectores de precisión completa se utilizan solo para la reclasificación final de los resultados principales. Esta estrategia híbrida permite a los clientes almacenar cientos de millones de vectores a una fracción del costo mientras mantienen una calidad de búsqueda indistinguible de la operación sin comprimir.
MicrocosmWorks implementa bases de datos vectoriales en configuraciones de múltiples réplicas con replicación síncrona para la durabilidad de la escritura y réplicas de lectura distribuidas en zonas de disponibilidad para la tolerancia a fallos y el balanceo de carga. Configuramos failover automático con elección de líder impulsada por health checks, de modo que un fallo de nodo resulta en menos de 10 segundos de indisponibilidad de lectura y cero pérdida de datos. Nuestras plantillas de infraestructura como código incluyen programaciones de copia de seguridad preconfiguradas, recuperación a un punto en el tiempo y runbooks de recuperación ante desastres adaptados a cada motor de base de datos vectorial.
MicrocosmWorks diseña despliegues de bases de datos vectoriales de múltiples colecciones donde cada aplicación o modelo de embedding obtiene su propia colección aislada con configuraciones de índice adecuadas, mientras comparte la infraestructura de clúster subyacente para la eficiencia de costos. Implementamos una puerta de enlace de consulta unificada que enruta las solicitudes a la colección correcta basándose en el contexto de la aplicación y aplica preprocesamiento específico de la colección como el embedding de consulta con el modelo coincidente. Este enfoque de base de datos vectorial multi-inquilino típicamente reduce los costos de infraestructura entre un 40-60% en comparación con ejecutar clústeres separados por aplicación.