Milvus 2.0 Redefinición de la base de datos vectorial
Fue ayer cuando pusimos la primera línea de código de Milvus en octubre de 2018. En marzo de 2021, después de 19 iteraciones probadas por más de 1.000 usuarios de todo el mundo, lanzamos Milvus 1.0, nuestra primera versión oficial con soporte a largo plazo. Como la base de datos de vectores de código abierto más popular del mundo, Milvus 1.0 logró resolver algunos problemas fundamentales en la gestión de vectores, como las operaciones CRUD y la persistencia de datos. Sin embargo, a medida que surgían nuevos escenarios y requisitos, empezamos a darnos cuenta de que aún quedaban muchas más cuestiones por resolver. Este artículo ofrece una recapitulación de las observaciones que hemos hecho en los últimos tres años, los retos que se espera que Milvus 2.0 aborde y por qué Milvus 2.0 se considera una solución mejor para tales retos. Para saber más sobre lo que Milvus 2.0 tiene que ofrecer, consulte las Notas de la versión de Milvus 2.0.
Desafíos a los que se enfrenta Milvus 1.x
Silo de datos: Milvus 1.0 sólo es capaz de manejar incrustaciones vectoriales generadas a partir de datos no estructurados, y ofrece poco soporte para consultas escalares. La desagregación del almacenamiento de datos en su diseño da lugar a datos duplicados y aumenta la complejidad del desarrollo de aplicaciones, y la búsqueda híbrida entre datos vectoriales y escalares es insatisfactoria debido a la falta de un optimizador unificado.
Dilema entre puntualidad y eficiencia: Milvus 1.0 es un sistema casi en tiempo real, que se basa en la descarga regular o forzada para garantizar la visibilidad de los datos. Este enfoque aumenta la complejidad y la incertidumbre en el tratamiento de datos de flujo a varios niveles. Además, aunque se dice que este enfoque de inserción por lotes mejora la eficacia del procesamiento, sigue consumiendo muchos recursos. Por lo tanto, es necesario un enfoque de carga masiva.
Falta de escalabilidad y elasticidad: Milvus 1.0 se basa en Mishards, una solución middleware de fragmentación, para lograr la escalabilidad, y en el almacenamiento conectado a la red (NAS) para la persistencia de los datos. Esta arquitectura clásica basada en el almacenamiento compartido no contribuye mucho a la escalabilidad general por las siguientes razones:
- Mishards sólo admite un nodo de escritura y no puede escalarse.
- El escalado de los nodos de lectura en Mishards se implementa utilizando enrutamiento consistente basado en hash. Aunque el hash consistente es fácil de implementar y ayuda a resolver el problema de la uniformidad de la distribución de datos, no es lo suficientemente flexible en la programación de datos y no llega a resolver el desajuste entre el tamaño de los datos y la potencia de cálculo.
- Milvus 1.0 se basa en MySQL para gestionar los metadatos, pero las consultas y el tamaño de los conjuntos de datos que puede manejar un servidor MySQL independiente son bastante limitados.
Falta de alta disponibilidad: Una observación que hemos hecho es que la mayoría de los usuarios de Milvus tienden a favorecer la disponibilidad sobre la consistencia, mientras que Milvus 1.x carece de capacidades como las réplicas en memoria y la recuperación de desastres y no está a la altura en términos de alta disponibilidad. Por lo tanto, estamos explorando la posibilidad de sacrificar un cierto grado de precisión para lograr una mayor disponibilidad.
Costes prohibitivos: Milvus 1.0 se basa en NAS para la persistencia de datos, cuyo coste suele ser diez veces superior al de un almacenamiento local o de objetos. Dado que la búsqueda vectorial depende en gran medida de los recursos informáticos y de la memoria, los elevados costes en los que incurre podrían convertirse en un obstáculo para una mayor exploración en conjuntos de datos a gran escala o en escenarios empresariales complejos.
Experiencia de usuario poco intuitiva:
- El complicado despliegue distribuido conlleva elevados costes operativos.
- No se dispone de una interfaz gráfica de usuario (GUI) bien diseñada.
- Las API poco intuitivas se han convertido en un lastre para el desarrollo de aplicaciones.
Pasar del parche o empezar de cero es una gran incógnita. Charles Xie, el padre de Milvus, cree que, al igual que muchos fabricantes de automóviles tradicionales nunca podrían convertir progresivamente a Tesla, Milvus tiene que convertirse en un cambio de juego en el campo del procesamiento de datos no estructurados y análisis para prosperar. Es esta convicción la que nos impulsó a poner en marcha Milvus 2.0, una base de datos vectorial nativa de la nube refactorizada.
La creación de Milvus 2.0
Principios de diseño
Como nuestra base de datos vectorial nativa en la nube de próxima generación, Milvus 2.0 se basa en los tres principios siguientes:
Primero la nube nativa: Creemos que sólo las arquitecturas que soportan la separación de almacenamiento y computación pueden escalar bajo demanda y aprovechar al máximo la elasticidad de la nube. También nos gustaría llamar su atención sobre el diseño de microservicios de Milvus 2.0, que cuenta con separación de lectura y escritura, separación de datos incrementales e históricos, y separación de tareas intensivas en CPU, memoria e IO. Los microservicios ayudan a optimizar la asignación de recursos para la siempre cambiante carga de trabajo heterogénea.
Registros como datos: En Milvus 2.0, el corredor de registros sirve de columna vertebral del sistema: Todas las operaciones de inserción y actualización de datos deben pasar por el corredor de registros, y los nodos trabajadores ejecutan las operaciones CRUD suscribiéndose a los registros y consumiéndolos. Este diseño reduce la complejidad del sistema al trasladar funciones básicas como la persistencia de datos y el flashback a la capa de almacenamiento, y el pub-sub de registros hace que el sistema sea aún más flexible y esté mejor posicionado para el escalado futuro.
Procesamiento unificado de lotes y flujos: Milvus 2.0 implementa la arquitectura Lambda unificada, que integra el procesamiento de los datos incrementales e históricos. En comparación con la arquitectura Kappa, Milvus 2.0 introduce log backfill, que almacena instantáneas de registro e índices en el almacenamiento de objetos para mejorar la eficiencia de la recuperación de fallos y el rendimiento de las consultas. Para dividir los datos ilimitados (flujo) en ventanas delimitadas, Milvus adopta un nuevo mecanismo de marca de agua, que divide los datos de flujo en múltiples paquetes de mensajes según el tiempo de escritura o el tiempo del evento, y mantiene una línea de tiempo para que los usuarios puedan realizar consultas por tiempo.
2.0 imagen 1.png
Arquitectura del sistema
Como ya se ha mencionado, el diseño de Milvus 2.0 sigue estrictamente los principios de separación entre almacenamiento y computación y entre plano de control y plano de datos. El sistema se divide en cuatro capas: capa de acceso, servicio coordinador, nodos trabajadores y almacenamiento.
Capa de acceso: La interfaz: La capa de acceso es la capa frontal del sistema y punto final para los usuarios. Se encarga de reenviar las peticiones y recoger los resultados.
Servicio de coordinación: El servicio coordinador asigna tareas a los nodos trabajadores y funciona como cerebro del sistema. Hay cuatro tipos de coordinador: coordinador raíz (root coord), coordinador de datos (data coord), coordinador de consultas (query coord) y coordinador de índices (index coord).
Nodos trabajadores: Los brazos y las piernas. Los nodos trabajadores son ejecutores mudos que siguen las instrucciones del servicio coordinador y responden a las peticiones de lectura/escritura de la capa de acceso. Hay tres tipos de nodos trabajadores: nodos de datos, nodos de consulta y nodos de índice.
El almacenamiento: Los huesos. El almacenamiento es de tres tipos: metaalmacenamiento, log broker y almacenamiento de objetos.
- Implementado por etcd, el metaalmacenamiento se utiliza para almacenar metadatos como la recopilación y el punto de control para el servicio coordinador.
- Implementado por Pulsar, el log broker se utiliza principalmente para almacenar logs incrementales e implementar notificaciones asíncronas fiables.
- Implementado por MinIO o S3, el almacenamiento de objetos se utiliza principalmente para almacenar instantáneas de registro y archivos de índice.
A continuación se muestra el diagrama de la arquitectura del sistema de Milvus 2.0: 2.0 image 2.png
Características principales
Los costes de funcionamiento de una base de datos no solo implican el consumo de recursos en tiempo de ejecución, sino también los posibles costes de aprendizaje y los costes operativos y de mantenimiento. En la práctica, cuanto más fácil de usar sea una base de datos, más probabilidades tendrá de ahorrar esos costes potenciales. Desde el primer día del calendario de Milvus, la facilidad de uso siempre ha estado en lo más alto de nuestra lista, y la última Milvus 2.0 tiene bastantes cosas que ofrecer para reducir dichos costes.
Siempre en línea
La fiabilidad de los datos y la sostenibilidad del servicio son los requisitos básicos de una base de datos, y nuestra estrategia es "fallar poco, fallar poco y fallar a menudo".
- "Fallar barato" se refiere a la separación entre almacenamiento y computación, que hace que la gestión de la recuperación de fallos de nodos sea sencilla y de bajo coste.
- "Fallar poco" se refiere a la estrategia de "divide y vencerás", que simplifica la complejidad del diseño haciendo que cada servicio coordinador gestione sólo una pequeña parte de los datos de lectura/escritura/incrementales/históricos.
- "Fallar a menudo" se refiere a la introducción de pruebas caóticas, que utilizan la inyección de fallos en un entorno de pruebas para simular situaciones como fallos de hardware y fallos de dependencia y acelerar el descubrimiento de errores.
Búsqueda híbrida entre datos escalares y vectoriales
Para aprovechar la sinergia entre datos estructurados y no estructurados, Milvus 2.0 admite datos escalares y vectoriales y permite la búsqueda híbrida entre ellos. La búsqueda híbrida ayuda a los usuarios a encontrar los vecinos más cercanos aproximados que coinciden con un criterio de filtrado. Actualmente, Milvus admite operaciones relacionales como IGUAL, MAYOR QUE y MENOR QUE, y operaciones lógicas como NOT, AND, OR e IN.
Consistencia ajustable
Como base de datos distribuida que se rige por el teorema PACELC, Milvus 2.0 tiene que elegir entre consistencia, disponibilidad y latencia. En la mayoría de los casos, hacer demasiado hincapié en la coherencia de los datos en la producción puede ser excesivo, ya que permitir que una pequeña parte de los datos sea invisible tiene poco impacto en la recuperación general, pero puede mejorar significativamente el rendimiento de la consulta. Aún así, creemos que los niveles de consistencia, como fuerte, estancamiento limitado y sesión, tienen su propia aplicación única. Por lo tanto, Milvus permite ajustar la coherencia a nivel de solicitud. Tomando las pruebas como ejemplo, los usuarios pueden necesitar una consistencia fuerte para garantizar que los resultados de las pruebas son absolutamente correctos.
Desplazamiento en el tiempo
Los ingenieros de datos a menudo necesitan hacer rollback de datos para corregir datos sucios y errores de código. Las bases de datos tradicionales suelen implementar la reversión de datos mediante instantáneas o incluso la reconfiguración de datos. Esto podría acarrear unos gastos generales y de mantenimiento excesivos. Milvus mantiene una línea de tiempo para todas las operaciones de inserción y eliminación de datos, y los usuarios pueden especificar una marca de tiempo en una consulta para recuperar una vista de datos en un punto específico del tiempo. Con el viaje en el tiempo, Milvus también puede implementar una copia de seguridad de datos ligera o un clon de datos.
ORM Python SDK
El mapeo relacional de objetos (ORM) permite a los usuarios centrarse más en el modelo de negocio de nivel superior que en el modelo de datos subyacente, facilitando a los desarrolladores la gestión de las relaciones entre colecciones, campos y programas. Para cerrar la brecha entre la prueba de concepto (PoC) de los algoritmos de IA y el despliegue de producción, hemos diseñado las API de ORM de PyMilvus, que pueden funcionar con una biblioteca integrada, un despliegue independiente, un clúster distribuido o incluso un servicio en la nube. Con un conjunto unificado de APIs, proporcionamos a los usuarios una experiencia consistente y reducimos los costes de migración o adaptación de código.
2.0 imagen 3.png
Herramientas de apoyo
- Milvus Insight es la interfaz gráfica de usuario de Milvus que ofrece funcionalidades prácticas como la gestión del estado del clúster, la metagestión y la consulta de datos. El código fuente de Milvus Insight también será de código abierto como proyecto independiente. Estamos buscando más colaboradores que se unan a este esfuerzo.
- Experiencia Out-of-box (OOBE), despliegue más rápido: Milvus 2.0 puede desplegarse utilizando helm o docker-compose.
- Milvus 2.0 utiliza Prometheus, una base de datos de series temporales de código abierto, para almacenar datos de rendimiento y monitorización, y Grafana, una plataforma de observabilidad abierta, para la visualización de métricas.
Mirando al futuro
En retrospectiva, creemos que la arquitectura del sistema basada en big data + aplicación de IA es excesivamente complicada. La principal prioridad de la comunidad Milvus siempre ha sido hacer que Milvus sea más fácil de usar. De cara al futuro, el proyecto Milvus se centrará en las siguientes áreas:
DB para AI: Además de las funciones CRUD básicas, Milvus, como sistema de base de datos, necesita tener un optimizador de consultas más inteligente, capacidades de consulta de datos más potentes y funciones de gestión de datos más completas. Nuestro trabajo para la próxima etapa se centrará en las funciones del lenguaje de manipulación de datos (DML) y en los tipos de datos que aún no están disponibles en Milvus 2.0, incluyendo la adición de operaciones de borrado y actualización y el soporte de tipos de datos de cadena.
AI for DB: El ajuste de parámetros como los tipos de índice, las configuraciones del sistema, la carga de trabajo del usuario y los tipos de hardware complica el uso de Milvus y debería evitarse en la medida de lo posible. Nos hemos propuesto analizar la carga del sistema y recopilar la frecuencia de acceso a los datos, y planeamos introducir el autoajuste en el futuro para reducir los costes de aprendizaje.
Optimización de costes: El mayor reto de la recuperación vectorial es la necesidad de procesar conjuntos de datos a gran escala en un periodo de tiempo limitado. Esto requiere un uso intensivo tanto de la CPU como de la memoria. La introducción de la aceleración por hardware heterogéneo de GPU y FPGA en la capa física puede reducir enormemente la sobrecarga de la CPU. También estamos desarrollando algoritmos de indexación RNA híbridos en disco y en memoria para realizar consultas de alto rendimiento en conjuntos de datos masivos con memoria limitada. Además, estamos evaluando el rendimiento de algoritmos de indexación vectorial de código abierto como ScaNN y NGT.
Facilidad de uso: Milvus sigue mejorando su facilidad de uso proporcionando herramientas de gestión de clústeres, SDK en varios idiomas, herramientas de despliegue, herramientas operativas y mucho más.
Para saber más sobre los planes de lanzamiento de Milvus, consulte la hoja de ruta de Milvus.
Enhorabuena a todos los colaboradores de la comunidad Milvus, sin los cuales Milvus 2.0 no habría sido posible. No dude en enviar un problema o contribuir con su código a la comunidad Milvus.
Sobre el autor
Xiaofan Luan trabaja actualmente en Zilliz como Director de Ingeniería gestionando la I+D del proyecto Milvus. Cuenta con 7 años de experiencia laboral centrada en la creación de sistemas de bases de datos/almacenamiento. Tras graduarse en la Universidad de Cornell, trabajó consecutivamente en Oracle, HEDVIG y Alibaba Cloud.
Try Managed Milvus for Free
Zilliz Cloud is hassle-free, powered by Milvus and 10x faster.
Get StartedLike the article? Spread the word