¿Frustrado con los datos nuevos? Nuestra base de datos vectorial puede ayudar
En la era del Big Data, ¿qué tecnologías y aplicaciones de bases de datos pasarán a primer plano? ¿Cuál será el próximo punto de inflexión?
Con los datos no estructurados representando aproximadamente el 80-90% de todos los datos almacenados, ¿qué se supone que debemos hacer con estos crecientes lagos de datos? Uno podría pensar en usar métodos analíticos tradicionales, pero estos no logran extraer información útil, si es que extraen alguna información. Para responder a esta pregunta, los "Tres Mosqueteros" del equipo de Investigación y Desarrollo de Zilliz, el Dr. Rentong Guo, el Sr. Xiaofan Luan y la Dra. Xiaomeng Yi, han coescrito un artículo para discutir el diseño y los desafíos enfrentados al construir un sistema de base de datos vectorial de propósito general.
Este artículo ha sido incluido en Programmer, una revista producida por CSDN, la comunidad de desarrolladores de software más grande de China. Este número de Programmer también incluye artículos de Jeffrey Ullman, ganador del Premio Turing 2020, Yann LeCun, ganador del Premio Turing 2018, Mark Porter, CTO de MongoDB, Zhenkun Yang, fundador de OceanBase, Dongxu Huang, fundador de PingCAP, etc.
A continuación compartimos con ustedes el artículo completo:
Diseño y práctica de sistemas de bases de datos vectoriales de propósito general orientados a la IA
Introducción
Las aplicaciones de datos modernas pueden manejar fácilmente datos estructurados, que representan aproximadamente el 20% de los datos actuales. En su caja de herramientas hay sistemas como bases de datos relacionales, bases de datos NoSQL, etc.; en contraste, los datos no estructurados, que representan aproximadamente el 80% de todos los datos, no cuentan con sistemas fiables establecidos. Para resolver este problema, este artículo discutirá los puntos débiles que el análisis de datos tradicional tiene con los datos no estructurados y, además, discutirá la arquitectura y los desafíos que enfrentamos al construir nuestro propio sistema de base de datos vectorial de propósito general.
Revolución de los datos en la era de la IA
Con el rápido desarrollo de las tecnologías 5G e IoT, las industrias buscan multiplicar sus canales de recopilación de datos y proyectar aún más el mundo real en el espacio digital. Aunque ha traído consigo algunos desafíos enormes, también ha traído beneficios tremendos para la industria en crecimiento. Uno de estos desafíos difíciles es cómo obtener conocimientos más profundos de estos nuevos datos entrantes.
Según estadísticas de IDC, solo en 2020 se generaron en todo el mundo más de 40.000 exabytes de datos nuevos. Del total, solo el 20% son datos estructurados: datos altamente ordenados y fáciles de organizar y analizar mediante cálculos numéricos y álgebra relacional. En contraste, los datos no estructurados (que ocupan el 80% restante) son extremadamente ricos en variaciones de tipos de datos, lo que dificulta descubrir la semántica profunda mediante métodos tradicionales de análisis de datos.
Afortunadamente, estamos experimentando una evolución rápida y simultánea en los datos no estructurados y la IA, con la IA permitiéndonos comprender mejor los datos a través de varios tipos de redes neuronales, como se muestra en la Figura 1.
Figura 1: Proceso de embedding
La tecnología de embedding ganó popularidad rápidamente tras el debut de Word2vec, con la idea de "incrustar todo" llegando a todos los sectores del aprendizaje automático. Esto conduce a la aparición de dos capas principales de datos: la capa de datos sin procesar y la capa de datos vectoriales. La capa de datos sin procesar está compuesta por datos no estructurados y ciertos tipos de datos estructurados; la capa vectorial es la colección de embeddings fácilmente analizables que se origina en la capa sin procesar al pasar por modelos de aprendizaje automático.
En comparación con los datos sin procesar, los datos vectorizados presentan las siguientes ventajas:
- Los vectores de incrustación son un tipo abstracto de datos, lo que significa que podemos construir un sistema de álgebra unificado dedicado a reducir la complejidad de los datos no estructurados.
- Los vectores de incrustación se expresan mediante vectores densos de punto flotante, lo que permite que las aplicaciones aprovechen SIMD. Dado que SIMD es compatible con GPU y casi todas las CPU modernas, los cálculos entre vectores pueden lograr un alto rendimiento a un coste relativamente bajo.
- Los datos vectoriales codificados mediante modelos de aprendizaje automático ocupan menos espacio de almacenamiento que los datos no estructurados originales, lo que permite un mayor rendimiento.
- También se puede realizar aritmética entre vectores de incrustación. La Figura 2 muestra un ejemplo de coincidencia aproximada semántica intermodal: las imágenes mostradas en la figura son el resultado de hacer coincidir incrustaciones de palabras con incrustaciones de imágenes.
Figura 2: Visualización de incrustación semántica basada en un modelo de lenguaje neuronal intermodal
Como se muestra en la Figura 3, combinar la semántica de imágenes y palabras puede hacerse con simples sumas y restas vectoriales entre sus incrustaciones correspondientes.
Figura 3: Visualización unificada de incrustación semántica basada en un modelo de lenguaje neuronal intermodal
Además de las características anteriores, estos operadores admiten sentencias de consulta más complicadas en escenarios prácticos. La recomendación de contenido es un ejemplo bien conocido. Generalmente, el sistema incrusta tanto el contenido como las preferencias de visualización de los usuarios. A continuación, el sistema hace coincidir las preferencias incrustadas del usuario con el contenido incrustado más similar mediante análisis de similitud semántica, lo que da como resultado nuevo contenido similar a las preferencias de los usuarios. Esta capa de datos vectoriales no se limita únicamente a los sistemas de recomendación; los casos de uso incluyen comercio electrónico, análisis de malware, análisis de datos, verificación biométrica, análisis de fórmulas químicas, finanzas, seguros, etc.
Los datos no estructurados requieren una pila completa de software básico
El software de sistema se sitúa en la base de todas las aplicaciones orientadas a datos, pero el software de sistemas de datos construido durante las últimas décadas, por ejemplo, bases de datos, motores de análisis de datos, etc., está destinado a trabajar con datos estructurados. Las aplicaciones de datos modernas dependen casi exclusivamente de datos no estructurados y no se benefician de los sistemas tradicionales de gestión de bases de datos.
Para abordar este problema, hemos desarrollado y liberado como código abierto un sistema de base de datos vectorial de propósito general orientado a IA llamado Milvus (Referencia n.º 1~2). En comparación con los sistemas de bases de datos tradicionales, Milvus trabaja en una capa de datos diferente. Las bases de datos tradicionales, como bases de datos relacionales, bases de datos KV, bases de datos de texto, bases de datos de imágenes/vídeo, etc... trabajan en la capa de datos sin procesar, mientras que Milvus trabaja en la capa de datos vectoriales.
En los siguientes capítulos, analizaremos las nuevas características, el diseño arquitectónico y los desafíos técnicos a los que nos enfrentamos al construir Milvus.
Atributos principales de la base de datos vectorial
Las bases de datos vectoriales almacenan, recuperan, analizan vectores y, al igual que cualquier otra base de datos, también proporcionan una interfaz estándar para operaciones CRUD. Además de estas características "estándar", los atributos enumerados a continuación también son cualidades importantes para una base de datos vectorial:
- Soporte para operadores vectoriales de alta eficiencia
El soporte para operadores vectoriales en un motor de análisis se centra en dos niveles. En primer lugar, la base de datos vectorial debe admitir diferentes tipos de operadores, por ejemplo, la coincidencia de similitud semántica y la aritmética semántica mencionadas anteriormente. Además de esto, debe admitir una variedad de métricas de similitud para los cálculos de similitud subyacentes. Dicha similitud suele cuantificarse como distancia espacial entre vectores, siendo métricas comunes la distancia euclidiana, la distancia del coseno y la distancia del producto interno.
- Soporte para indexación vectorial
En comparación con los índices basados en B-tree o LSM-tree en bases de datos tradicionales, los índices vectoriales de alta dimensión suelen consumir muchos más recursos informáticos. Recomendamos usar algoritmos de índices de agrupamiento y grafos, y dar prioridad a las operaciones matriciales y vectoriales, aprovechando así al máximo las capacidades de aceleración de cálculo vectorial del hardware mencionadas anteriormente.
- Experiencia de usuario consistente en diferentes entornos de implementación
Las bases de datos vectoriales suelen desarrollarse e implementarse en diferentes entornos. En la etapa preliminar, los científicos de datos y los ingenieros de algoritmos trabajan principalmente en sus portátiles y estaciones de trabajo, ya que prestan más atención a la eficiencia de la verificación y a la velocidad de iteración. Cuando se completa la verificación, pueden implementar la base de datos de tamaño completo en un clúster privado o en la nube. Por lo tanto, un sistema de base de datos vectorial cualificado debería ofrecer un rendimiento y una experiencia de usuario consistentes en diferentes entornos de implementación.
- Soporte para búsqueda híbrida
Están surgiendo nuevas aplicaciones a medida que las bases de datos vectoriales se vuelven omnipresentes. Entre todas estas demandas, la más mencionada es la búsqueda híbrida en vectores y otros tipos de datos. Algunos ejemplos de esto son la búsqueda aproximada del vecino más cercano (ANNS) después del filtrado escalar, la recuperación multicanal a partir de búsqueda de texto completo y búsqueda vectorial, y la búsqueda híbrida de datos espaciotemporales y datos vectoriales. Estos desafíos exigen escalabilidad elástica y optimización de consultas para fusionar eficazmente los motores de búsqueda vectorial con KV, texto y otros motores de búsqueda.
- Arquitectura nativa de la nube
El volumen de datos vectoriales crece como hongos con el crecimiento exponencial de la recopilación de datos. Los datos vectoriales de alta dimensión a escala de billones corresponden a miles de TB de almacenamiento, lo que supera con creces el límite de un solo nodo. Como resultado, la extensibilidad horizontal es una capacidad clave para una base de datos vectorial y debería satisfacer las demandas de los usuarios en cuanto a elasticidad y agilidad de implementación. Además, también debería reducir la complejidad de operación y mantenimiento del sistema, al tiempo que mejora la observabilidad con la asistencia de la infraestructura en la nube. Algunas de estas necesidades se presentan en forma de aislamiento multiinquilino, instantáneas y copias de seguridad de datos, cifrado de datos y visualización de datos, que son comunes en las bases de datos tradicionales.
Arquitectura del sistema de bases de datos vectoriales
Milvus 2.0 sigue los principios de diseño de "registro como datos", "procesamiento unificado por lotes y en streaming", "sin estado" y "microservicios". La Figura 4 muestra la arquitectura general de Milvus 2.0.
Figura 4: Arquitectura general de Milvus 2.0
Registro como datos: Milvus 2.0 no mantiene ninguna tabla física. En su lugar, garantiza la fiabilidad de los datos mediante la persistencia de registros y las instantáneas de registros. El intermediario de registros (la columna vertebral del sistema) almacena registros y desacopla componentes y servicios a través del mecanismo de publicación-suscripción (pub-sub) de registros. Como se muestra en la Figura 5, el intermediario de registros está compuesto por "secuencia de registros" y "suscriptor de registros". La secuencia de registros registra todas las operaciones que cambian el estado de una colección (equivalente a una tabla en una base de datos relacional ); el suscriptor de registros se suscribe a la secuencia de registros para actualizar sus datos locales y proporcionar servicios en forma de copias de solo lectura. El mecanismo pub-sub también deja espacio para la extensibilidad del sistema en términos de captura de datos modificados (CDC) e implementación distribuida globalmente.
Figura 5: Un modelo simplificado para el almacenamiento de registros
Procesamiento unificado por lotes y en streaming: La transmisión de logs permite a Milvus actualizar los datos en tiempo real, garantizando así la entrega en tiempo real. Además, al transformar lotes de datos en instantáneas de logs y construir índices sobre instantáneas, Milvus puede lograr una mayor eficiencia en las consultas. Durante una consulta, Milvus fusiona los resultados de consulta tanto de los datos incrementales como de los datos históricos para garantizar la integridad de los datos devueltos. Este diseño equilibra mejor el rendimiento en tiempo real y la eficiencia, aliviando la carga de mantenimiento de los sistemas en línea y fuera de línea en comparación con la arquitectura Lambda tradicional.
Sin estado: La infraestructura en la nube y los componentes de almacenamiento de código abierto liberan a Milvus de persistir datos dentro de sus propios componentes. Milvus 2.0 persiste datos con tres tipos de almacenamiento: almacenamiento de metadatos, almacenamiento de logs y almacenamiento de objetos. El almacenamiento de metadatos no solo almacena los metadatos, sino que también gestiona el descubrimiento de servicios y la administración de nodos. El almacenamiento de logs ejecuta la persistencia de datos incrementales y la publicación-suscripción de datos. El almacenamiento de objetos almacena instantáneas de logs, índices y algunos resultados intermedios de cálculo.
Microservicios: Milvus sigue los principios de desagregación del plano de datos y el plano de control, separación de lectura/escritura y separación de tareas en línea/fuera de línea. Está compuesto por cuatro capas de servicio: la capa de acceso, la capa de coordinadores, la capa de trabajadores y la capa de almacenamiento. Estas capas son mutuamente independientes en cuanto a escalado y recuperación ante desastres. Como capa orientada al exterior y punto de acceso para el usuario, la capa de acceso gestiona las conexiones de los clientes, valida las solicitudes de los clientes y combina los resultados de las consultas. Como el "cerebro" del sistema, la capa de coordinadores asume las tareas de gestión de la topología del clúster, equilibrio de carga, declaración de datos y gestión de datos. La capa de trabajadores contiene las "extremidades" del sistema, ejecutando actualizaciones de datos, consultas y operaciones de construcción de índices. Finalmente, la capa de almacenamiento se encarga de la persistencia y replicación de datos. En general, este diseño basado en microservicios garantiza una complejidad del sistema controlable, con cada componente responsable de su propia función correspondiente. Milvus aclara los límites de los servicios mediante interfaces bien definidas y desacopla los servicios con base en una granularidad más fina, lo que optimiza aún más la escalabilidad elástica y la distribución de recursos.
Desafíos técnicos que enfrentan las bases de datos vectoriales
La investigación inicial sobre bases de datos vectoriales se concentró principalmente en el diseño de estructuras de índices y métodos de consulta de alta eficiencia; esto dio como resultado una variedad de bibliotecas de algoritmos de búsqueda vectorial (Referencia n.º 3~5). En los últimos años, un número creciente de equipos académicos y de ingeniería han vuelto a examinar los problemas de búsqueda vectorial desde la perspectiva del diseño de sistemas y han propuesto algunas soluciones sistemáticas. Resumiendo los estudios existentes y la demanda de los usuarios, categorizamos los principales desafíos técnicos para las bases de datos vectoriales de la siguiente manera:
- Optimización de la relación costo-rendimiento relativa a la carga
En comparación con el análisis de tipos de datos tradicionales, el análisis de datos vectoriales requiere muchos más recursos de almacenamiento y computación debido a su alta dimensionalidad. Además, los usuarios han mostrado diversas preferencias respecto a las características de carga y la optimización costo-rendimiento en soluciones de búsqueda vectorial. Por ejemplo, los usuarios que trabajan con conjuntos de datos extremadamente grandes (decenas o cientos de miles de millones de vectores) preferirían soluciones con menores costos de almacenamiento de datos y variación en la latencia de búsqueda, mientras que otros pueden exigir un mayor rendimiento de búsqueda y una latencia promedio constante. Para satisfacer preferencias tan diversas, el componente central de índices de la base de datos vectorial debe ser capaz de admitir estructuras de índices y algoritmos de búsqueda con diferentes tipos de almacenamiento y hardware de computación.
Por ejemplo, almacenar datos vectoriales y los datos de índice correspondientes en medios de almacenamiento más económicos (como NVM y SSD) debería tenerse en cuenta al reducir los costes de almacenamiento. Sin embargo, la mayoría de los algoritmos de búsqueda vectorial existentes funcionan con datos leídos directamente de la memoria. Para evitar la pérdida de rendimiento provocada por el uso de unidades de disco, la base de datos vectorial debería poder aprovechar la localidad del acceso a los datos combinada con algoritmos de búsqueda, además de poder adaptarse a soluciones de almacenamiento para datos vectoriales y estructuras de índices (Referencia n.º 6~8). En aras de mejorar el rendimiento, la investigación contemporánea se ha centrado en tecnologías de aceleración de hardware que involucran GPU, NPU, FPGA, etc. (Referencia n.º 9). Sin embargo, el hardware y los chips específicos de aceleración varían en el diseño de su arquitectura, y el problema de la ejecución más eficiente en diferentes aceleradores de hardware aún no se ha resuelto.
- Configuración y ajuste automatizados del sistema
La mayoría de los estudios existentes sobre algoritmos de búsqueda vectorial buscan un equilibrio flexible entre los costes de almacenamiento, el rendimiento computacional y la precisión de búsqueda. En general, tanto los parámetros del algoritmo como las características de los datos influyen en el rendimiento real de un algoritmo. Dado que las demandas de los usuarios difieren en costes y rendimiento, seleccionar un método de consulta vectorial que se adapte a sus necesidades y a las características de los datos plantea un desafío significativo.
No obstante, los métodos manuales para analizar los efectos de la distribución de los datos en los algoritmos de búsqueda no son eficaces debido a la alta dimensionalidad de los datos vectoriales. Para abordar este problema, el mundo académico y la industria están buscando soluciones de recomendación de algoritmos basadas en aprendizaje automático (Referencia n.º 10).
El diseño de un algoritmo inteligente de búsqueda vectorial impulsado por ML también es un foco de investigación. En términos generales, los algoritmos de búsqueda vectorial existentes se desarrollan de manera universal para datos vectoriales con diversas dimensionalidades y patrones de distribución. Como resultado, no admiten estructuras de índices específicas según las características de los datos y, por tanto, tienen poco margen de optimización. Los estudios futuros también deberían explorar tecnologías eficaces de aprendizaje automático que puedan adaptar las estructuras de índices a diferentes características de los datos (Referencia n.º 11-12).
- Compatibilidad con semánticas de consulta avanzadas
Las aplicaciones modernas suelen depender de consultas más avanzadas entre vectores; las semánticas tradicionales de búsqueda de vecinos más cercanos ya no son aplicables a la búsqueda de datos vectoriales. Además, está surgiendo la demanda de búsquedas combinadas en múltiples bases de datos vectoriales o sobre datos vectoriales y no vectoriales (Referencia n.º 13).
En concreto, las variaciones en las métricas de distancia para la similitud vectorial crecen rápidamente. Las puntuaciones de similitud tradicionales, como la distancia euclidiana, la distancia de producto interno y la distancia coseno, no pueden satisfacer todas las demandas de las aplicaciones. Con la popularización de la tecnología de inteligencia artificial, muchas industrias están desarrollando sus propias métricas de similitud vectorial específicas de su campo, como la distancia de Tanimoto, la distancia de Mahalanobis, Superestructura y Subestructura. Integrar estas métricas de evaluación en los algoritmos de búsqueda existentes y diseñar algoritmos novedosos que utilicen dichas métricas son problemas de investigación desafiantes.
A medida que aumenta la complejidad de los servicios de usuario, las aplicaciones necesitarán buscar tanto en datos vectoriales como en datos no vectoriales. Por ejemplo, un recomendador de contenido analiza las preferencias de los usuarios, las relaciones sociales y las relaciona con los temas populares actuales para ofrecer contenido adecuado a los usuarios. Estas búsquedas normalmente implican consultas sobre múltiples tipos de datos o en múltiples sistemas de procesamiento de datos. Soportar dichas búsquedas híbridas de manera eficiente y flexible es otro desafío de diseño de sistemas.
Autores
Dr. Rentong Guo (Ph.D. en Software y Teoría de Computación, Universidad de Ciencia y Tecnología de Huazhong), socio y Director de I+D de Zilliz. Es miembro del Comité Técnico de Computación y Procesamiento Distribuidos de la Federación China de Computación (CCF TCDCP). Su investigación se centra en bases de datos, sistemas distribuidos, sistemas de caché y computación heterogénea. Sus trabajos de investigación se han publicado en varias conferencias y revistas de primer nivel, incluidas Usenix ATC, ICS, DATE, TPDS. Como arquitecto de Milvus, el Dr. Guo busca soluciones para desarrollar sistemas de análisis de datos basados en IA altamente escalables y rentables.
Xiaofan Luan, socio y Director de Ingeniería de Zilliz, y miembro del Comité Asesor Técnico de LF AI & Data Foundation. Trabajó sucesivamente en la sede de Oracle en EE. UU. y en Hedvig, una startup de almacenamiento definido por software. Se incorporó al equipo de bases de datos de Alibaba Cloud y estuvo a cargo del desarrollo de la base de datos NoSQL HBase y Lindorm. Luan obtuvo su maestría en Ingeniería de Computación Electrónica en Cornell University.
Dr. Xiaomeng Yi (Ph.D. en Arquitectura de Computadores, Universidad de Ciencia y Tecnología de Huazhong), Investigador Sénior y líder del equipo de investigación de Zilliz. Su investigación se concentra en la gestión de datos de alta dimensión, la recuperación de información a gran escala y la asignación de recursos en sistemas distribuidos. Los trabajos de investigación del Dr. Yi se han publicado en revistas líderes y conferencias internacionales, incluidas IEEE Network Magazine, IEEE/ACM TON, ACM SIGMOD, IEEE ICDCS y ACM TOMPECS.
Filip Haltmayer, ingeniero de datos de Zilliz, se graduó en University of California, Santa Cruz con una licenciatura en Ciencias de la Computación. Tras incorporarse a Zilliz, Filip dedica la mayor parte de su tiempo a trabajar en implementaciones en la nube, interacciones con clientes, charlas técnicas y desarrollo de aplicaciones de IA.
Referencias
- Proyecto Milvus: https://github.com/milvus-io/milvus
- Milvus: A Purpose-Built Vector Data Management System, SIGMOD'21
- Proyecto Faiss: https://github.com/facebookresearch/faiss
- Proyecto Annoy: https://github.com/spotify/annoy
- Proyecto SPTAG: https://github.com/microsoft/SPTAG
- GRIP: Multi-Store Capacity-Optimized High-Performance Nearest Neighbor Search for Vector Search Engine, CIKM'19
- DiskANN: Fast Accurate Billion-point Nearest Neighbor Search on a Single Node, NIPS'19
- HM-ANN: Efficient Billion-Point Nearest Neighbor Search on Heterogeneous Memory, NIPS'20
- SONG: Approximate Nearest Neighbor Search on GPU, ICDE'20
- A demonstration of the ottertune automatic database management system tuning service, VLDB'18
- The Case for Learned Index Structures, SIGMOD'18
- Improving Approximate Nearest Neighbor Search through Learned Adaptive Early Termination, SIGMOD'20
- AnalyticDB-V: A Hybrid Analytical Engine Towards Query Fusion for Structured and Unstructured Data, VLDB'20
Interactúa con nuestra comunidad de código abierto:
Sigue leyendo
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.
Similarity Metrics for Vector Search
Exploring five similarity metrics for vector search: L2 or Euclidean distance, cosine distance, inner product, and hamming distance.
Building RAG Pipelines for Real-Time Data with Cloudera and Milvus
explore how Cloudera can be integrated with Milvus to effectively implement some of the key functionalities of RAG pipelines.