Introducción a la arquitectura de Milvus
En una encuesta de más de 1200 usuarios, encontramos un desafío clave recurrente: la escalabilidad. ¿Cómo podemos escalar nuestras operaciones vectoriales? Esta pregunta conduce al desarrollo de Milvus como un sistema distribuido. Las bases de datos vectoriales, a diferencia de las bases de datos tradicionales, tienen requisitos de uso diferentes. Tres diferencias principales nos motivaron a crear una base de datos vectorial nativa de la nube desde cero.
Primero, los datos vectoriales no requieren transacciones complejas.
Segundo, la diversidad de los casos de uso requiere un equilibrio ajustable entre rendimiento y consistencia.
Tercero, algunas operaciones con datos vectoriales son computacionalmente costosas, lo que requiere una asignación elástica de recursos.
Milvus logra el escalado horizontal mediante su diseño deliberado como sistema distribuido. Aunque las bases de datos de instancia única pueden escalar hasta cierto punto, pronto quedan limitadas por el hardware. La capacidad de escalado horizontal de Milvus supera este problema, permitiendo que la base de datos se extienda a través de múltiples instancias. Hay dos maneras de escalar una base de datos horizontalmente: integrar directamente la funcionalidad en la base de datos o implementar manualmente los procesos de escalado.
Con Milvus, la funcionalidad de escalado está integrada en el sistema. Aunque puedes gestionar el escalado por tu cuenta, no es una solución ideal a menos que tu trabajo crítico para la misión implique escalar bases de datos. Examinemos tres arquitecturas y dos opciones de diseño de búsqueda que hacen que Milvus sea tan escalable.
Arquitectura de sistema nativa de la nube
La mayoría de los equipos de software ya no despliegan en los servidores de la sala de servidores. ¿Por qué? Las nubes públicas disponibles (AWS, Azure, GCP, etc.) permiten a los equipos de software avanzar más rápido. Milvus está construido para aprovechar la flexibilidad que proporciona trabajar en la nube.
Milvus contiene cuatro capas: acceso, coordinación, trabajador y almacenamiento. Los nodos de acceso sin estado dan acceso al sistema. Los trabajadores y coordinadores están diseñados con un patrón serverless. Los coordinadores con estado activan y desactivan trabajadores sin estado según sea necesario. La capa de almacenamiento almacena los datos vectoriales y toda la información necesaria para que el sistema funcione.
Separación de responsabilidades
Al trabajar con una base de datos vectorial, hay tres áreas principales de responsabilidad: consultas, ingesta de datos e indexación. Estas tres funcionalidades siempre escalarán en diferentes magnitudes en distintos momentos. Milvus proporciona tres tipos diferentes de nodos que pueden escalar de forma independiente.
Los nodos de consulta gestionan la funcionalidad de consulta, lo que significa que deben tener suficiente memoria para contener los índices en memoria de múltiples segmentos. Los segmentos son bloques de datos de un tamaño predefinido que Milvus utiliza para lograr eficiencia y escalabilidad. Los nodos de consulta también ayudan a paralelizar la búsqueda utilizando parte de su capacidad de cómputo y memoria para delegar, agregar y procesar resultados de búsqueda de múltiples segmentos, muchos de los cuales pueden estar alojados en otros nodos.
A medida que llegan los datos, entran tanto en los nodos de consulta como en los nodos de datos. Estos nodos conservan los datos en segmentos en crecimiento que aún no han alcanzado su límite de tamaño. Después de que el segmento alcanza su capacidad, el nodo de consulta libera esos datos y los reemplaza con el índice generado.
Los nodos de datos gestionan la ingesta de datos. Después de que un segmento alcanza su límite de tamaño con un nodo de datos, queda “sellado.” Luego, los segmentos sellados se vacían al almacenamiento permanente desde los nodos de datos y de consulta. Una vez que los datos se vacían en la capa de almacenamiento, los coordinadores notifican a un nodo de índice.
Los nodos de índice crean índices. Cuando un nodo de índice recibe una notificación, lee el segmento de datos desde la capa de almacenamiento. Esta configuración nos permite trabajar de forma natural con menos datos al crear el índice. Dado que el nodo de índice lee datos desde el almacenamiento, puede leer solo los atributos que necesita para desarrollar índices.
Consistencia de escritura a gran escala
Una parte natural del escalado es encontrarse con problemas de consistencia. Una vez que pones en marcha la segunda réplica o instancia de Milvus o de cualquier otro sistema de base de datos, te encuentras al instante con un problema de consistencia de datos. Debes garantizar un acuerdo en todo el sistema sobre cuán consistentes deben ser los datos.
Milvus tiene muchas opciones para ajustar la consistencia de tus datos integradas en el sistema. Milvus es un sistema pub/sub. El bloque de almacenamiento de mensajes actúa como un sistema de publicación, asignando una marca de tiempo a cada pieza de datos que pasa por él. Los nodos de consulta y de datos luego leen este registro de publicación como suscriptores.
Escalar la escritura implica escalar el número de shards que actúan como escritores. A medida que entran los datos, se aplica un hash a su ID, y el hash determina qué shard escribirá esa pieza de datos.
Segmentos de datos para búsqueda paralela
Como se mencionó anteriormente, Milvus crea índices individuales sobre cantidades predefinidas de datos llamadas “segmentos.” De forma predeterminada, Milvus crea segmentos sobre 512MB de datos, lo cual puedes ajustar para adaptarlo a tus necesidades.
¿Por qué creamos segmentos y construimos índices de esta manera? Para obtener más flexibilidad, escalabilidad y facilidad de modificación. Los índices son formas de acceder a los datos. Imagina que construyes un índice sobre algún conjunto de datos inicial. En un escenario del mundo real, tus datos cambian con el tiempo, por lo que tendrás que seguir añadiendo datos. Dado que el índice inicial solo se construyó sobre los datos iniciales, no ayuda con los datos nuevos.
La solución racional a este problema de indexación sería construir continuamente nuevos índices en algún intervalo predefinido (como la cantidad de datos nuevos añadidos). Milvus implementa esta solución en múltiples instancias y réplicas.
Esta configuración de segmentos proporciona una solución eficiente para una indexación ineficiente y hace que las consultas sean más escalables. Dado que los índices construidos sobre segmentos de datos separados no dependen unos de otros, podemos buscarlos en paralelo, limitados solo por el hardware.
Optar por un tamaño de segmento más grande mejora la eficiencia de cada operación de búsqueda; sin embargo, es esencial tener en cuenta que esta elección también resulta en mayores costos asociados con la compactación y la reconstrucción de índices.
Búsqueda de metadatos con prefiltrado
El filtrado de metadatos es una característica importante para muchas personas. Esta característica te permite buscar únicamente vectores de fechas específicas, de autores específicos o con valores de atributos específicos. Al diseñar una aplicación de búsqueda vectorial, puedes colocar el filtrado de metadatos antes o después de la funcionalidad de búsqueda vectorial.
Antes de realizar una búsqueda vectorial, Milvus genera una máscara de bits sobre los metadatos. Esta operación de prefiltrado es lineal en el tiempo. Milvus revisa los datos una vez y comprueba si los metadatos coinciden o no con la expresión de filtro proporcionada. Prefiltrar los metadatos reduce el volumen de datos sometidos a la búsqueda vectorial, lo que hace que la operación de búsqueda vectorial sea más eficiente.
En la próxima versión de Milvus 2.4, daremos soporte al índice invertido con tantivy, y la velocidad de prefiltrado aumentará drásticamente.
Resumen
Milvus adopta una arquitectura de sistema distribuido compuesta por cuatro capas: acceso, coordinación, trabajador y almacenamiento. Dados los diversos casos de uso de las bases de datos vectoriales, una infraestructura adaptable y en evolución es esencial. Milvus modela su componente de ingesta de datos en línea con este requisito como un sistema pub/sub (publicación-suscripción).
Modelar la ingesta de datos como un servicio pub/sub nos brinda flexibilidad al permitir un paradigma de servicio desacoplado y ayuda con la consistencia de los datos. El servicio de “publicación” marca cada pieza de datos con una marca de tiempo como parte de la funcionalidad de consistencia.
Cuando se trata de las tres preocupaciones (consultas, ingesta de datos e indexación) en una base de datos vectorial, Milvus las separa todas. Cada una de las tres operaciones tiene su nodo dedicado. Puedes poner en marcha y detener los nodos de forma independiente, lo que permite que Milvus escale con la cantidad de datos que tienes y el patrón de uso.
Garantizar la consistencia de los datos es una de las tareas más desafiantes a medida que escala la cantidad de datos que tienes. Milvus aborda este desafío mediante el uso de “shards”. Los datos entrantes se someten a hash y luego se dividen en un shard según su hash. Milvus tiene una consistencia ajustable con cuatro niveles entre los que elegir para equilibrar la rapidez con la que responde tu búsqueda y la rapidez con la que los datos se replican en las numerosas instancias de la base de datos.
Escribir datos a escala utiliza múltiples shards. Leer datos a escala utiliza segmentos. Los índices se construyen sobre segmentos individuales. Cada segmento ahora puede buscarse en paralelo en el momento de la consulta, lo que reduce enormemente el tiempo de búsqueda para grandes cantidades de datos.
Al buscar datos, probablemente querrás poder filtrarlos de alguna manera. Milvus implementa el filtrado de metadatos como una operación de prefiltrado. Luego aplica una máscara de bits al conjunto de datos durante la búsqueda vectorial y omite cualquier vector que no encaje. Este enfoque puede reducir significativamente el tiempo de búsqueda si se filtran muchos vectores.
La arquitectura única de Milvus proporciona muchos beneficios, especialmente el escalado horizontal. Está meticulosamente diseñada como una base de datos vectorial nativa de la nube para un rápido escalado horizontal mientras mantiene un rendimiento óptimo. El diseño de arquitectura deliberadamente desacoplada facilita la evolución de Milvus con el tiempo y permite flexibilidad. Esta adaptabilidad resulta crucial dada la creciente prominencia de las bases de datos vectoriales y la variedad cada vez mayor de casos de uso que atienden.
Sigue leyendo
Zilliz Cloud Just Landed in Claude Code
The Zilliz Cloud Plugin brings the full power of Zilliz Cloud directly into your Claude Code terminal as natural-language conversations.
Milvus 2.6.x Now Generally Available on Zilliz Cloud, Making Vector Search Faster, Smarter, and More Cost-Efficient for Production AI
Milvus 2.6.x is now GA on Zilliz Cloud, delivering faster vector search, smarter hybrid queries, and lower costs for production RAG and AI applications.
Why Teams Are Migrating from Weaviate to Zilliz Cloud — and How to Do It Seamlessly
Explore how Milvus scales for large datasets and complex queries with advanced features, and discover how to migrate from Weaviate to Zilliz Cloud.