Frustrado com novos dados? Nosso banco de dados vetorial pode ajudar
Na era do Big Data, quais tecnologias e aplicações de banco de dados ganharão destaque? Qual será o próximo divisor de águas?
Com dados não estruturados representando aproximadamente 80-90% de todos os dados armazenados; o que devemos fazer com esses data lakes em crescimento? Pode-se pensar em usar métodos analíticos tradicionais, mas eles não conseguem extrair informações úteis, se é que extraem alguma informação. Para responder a essa pergunta, os "Três Mosqueteiros" da equipe de Pesquisa e Desenvolvimento da Zilliz, Dr. Rentong Guo, Sr. Xiaofan Luan e Dr. Xiaomeng Yi, coescreveram um artigo para discutir o design e os desafios enfrentados ao construir um sistema de banco de dados vetorial de uso geral.
Este artigo foi incluído na Programmer, uma revista produzida pela CSDN, a maior comunidade de desenvolvedores de software da China. Esta edição da Programmer também inclui artigos de Jeffrey Ullman, vencedor do Prêmio Turing de 2020, Yann LeCun, vencedor do Prêmio Turing de 2018, Mark Porter, CTO da MongoDB, Zhenkun Yang, fundador da OceanBase, Dongxu Huang, fundador da PingCAP, etc.
Abaixo compartilhamos o artigo completo com você:
Design e Prática de Sistemas de Banco de Dados Vetorial de Uso Geral Orientados a IA
Introdução
As aplicações de dados modernas conseguem lidar facilmente com dados estruturados, que representam aproximadamente 20% dos dados atuais. Em sua caixa de ferramentas estão sistemas como bancos de dados relacionais, bancos de dados NoSQL, etc.; em contraste, os dados não estruturados, que representam aproximadamente 80% de todos os dados, não contam com nenhum sistema confiável em vigor. Para resolver esse problema, este artigo discutirá os pontos problemáticos que a análise de dados tradicional tem com dados não estruturados e discutirá ainda a arquitetura e os desafios que enfrentamos ao construir nosso próprio sistema de banco de dados vetorial de uso geral.
Revolução dos Dados na era da IA
Com o rápido desenvolvimento das tecnologias 5G e IoT, os setores estão buscando multiplicar seus canais de coleta de dados e projetar ainda mais o mundo real no espaço digital. Embora isso tenha trazido alguns desafios enormes, também trouxe benefícios tremendos para o setor em crescimento. Um desses desafios difíceis é como obter insights mais profundos sobre esses novos dados que estão chegando.
De acordo com estatísticas da IDC, mais de 40.000 exabytes de novos dados foram gerados mundialmente somente em 2020. Do total, apenas 20% são dados estruturados - dados que são altamente ordenados e fáceis de organizar e analisar por meio de cálculos numéricos e álgebra relacional. Em contraste, os dados não estruturados (que ocupam os 80% restantes) são extremamente ricos em variações de tipos de dados, tornando difícil descobrir a semântica profunda por meio de métodos tradicionais de análise de dados.
Felizmente, estamos vivenciando uma evolução rápida e simultânea em dados não estruturados e IA, com a IA nos permitindo compreender melhor os dados por meio de vários tipos de redes neurais, conforme mostrado na Figura 1.
Figura 1: Processo de embedding
A tecnologia de embedding ganhou popularidade rapidamente após a estreia do Word2vec, com a ideia de "embed everything" alcançando todos os setores do machine learning. Isso leva ao surgimento de duas grandes camadas de dados: a camada de dados brutos e a camada de dados vetoriais. A camada de dados brutos é composta por dados não estruturados e certos tipos de dados estruturados; a camada vetorial é a coleção de embeddings facilmente analisáveis que se origina da camada bruta passando por modelos de machine learning.
Quando comparados com dados brutos, os dados vetorizados apresentam as seguintes vantagens:
- Vetores de embedding são um tipo abstrato de dados, o que significa que podemos construir um sistema de álgebra unificado dedicado a reduzir a complexidade de dados não estruturados.
- Vetores de embedding são expressos por meio de vetores densos de ponto flutuante, permitindo que aplicações tirem proveito de SIMD. Como SIMD é suportado por GPUs e por quase todas as CPUs modernas, computações entre vetores podem alcançar alto desempenho a um custo relativamente baixo.
- Dados vetoriais codificados por meio de modelos de aprendizado de máquina ocupam menos espaço de armazenamento do que os dados não estruturados originais, permitindo maior throughput.
- Aritmética também pode ser realizada entre vetores de embedding. A Figura 2 mostra um exemplo de correspondência aproximada semântica multimodal - as imagens mostradas na figura são o resultado da correspondência de embeddings de palavras com embeddings de imagens.
Figura 2: Visualizando embedding semântico baseado em um modelo de linguagem neural multimodal
Como mostrado na Figura 3, combinar semântica de imagens e palavras pode ser feito com simples adição e subtração vetorial entre seus embeddings correspondentes.
Figura 3: Visualização unificada de embedding semântico baseado em modelo de linguagem neural multimodal
Além dos recursos acima, esses operadores dão suporte a instruções de consulta mais complicadas em cenários práticos. Recomendação de conteúdo é um exemplo bem conhecido. Geralmente, o sistema incorpora tanto o conteúdo quanto as preferências de visualização dos usuários. Em seguida, o sistema faz a correspondência das preferências incorporadas do usuário com o conteúdo incorporado mais semelhante por meio de análise de similaridade semântica, resultando em novo conteúdo que é semelhante às preferências dos usuários. Essa camada de dados vetoriais não se limita apenas a sistemas de recomendação; os casos de uso incluem e-commerce, análise de malware, análise de dados, verificação biométrica, análise de fórmulas químicas, finanças, seguros etc.
Dados não estruturados exigem uma pilha completa de software básico
O software de sistema fica na base de todas as aplicações orientadas a dados, mas o software de sistemas de dados construído ao longo das últimas décadas, por exemplo, bancos de dados, mecanismos de análise de dados etc., foi concebido para lidar com dados estruturados. Aplicações de dados modernas dependem quase exclusivamente de dados não estruturados e não se beneficiam dos sistemas tradicionais de gerenciamento de banco de dados.
Para enfrentar esse problema, desenvolvemos e tornamos open-source um sistema de banco de dados vetorial de uso geral orientado a IA chamado Milvus (Referência nº 1~2). Quando comparado aos sistemas tradicionais de banco de dados, Milvus trabalha em uma camada diferente de dados. Bancos de dados tradicionais, como bancos de dados relacionais, bancos de dados KV, bancos de dados de texto, bancos de dados de imagens/vídeo etc... trabalham na camada de dados brutos, enquanto Milvus trabalha na camada de dados vetoriais.
Nos capítulos a seguir, discutiremos os recursos inovadores, o design arquitetônico e os desafios técnicos que enfrentamos ao construir Milvus.
Principais atributos de banco de dados vetorial
Bancos de dados vetoriais armazenam, recuperam, analisam vetores e, assim como qualquer outro banco de dados, também fornecem uma interface padrão para operações CRUD. Além desses recursos "padrão", os atributos listados abaixo também são qualidades importantes para um banco de dados vetorial:
- Suporte a operadores vetoriais de alta eficiência
O suporte a operadores vetoriais em um mecanismo de análise se concentra em dois níveis. Primeiro, o banco de dados vetorial deve oferecer suporte a diferentes tipos de operadores, por exemplo, correspondência de similaridade semântica e aritmética semântica mencionadas acima. Além disso, deve oferecer suporte a uma variedade de métricas de similaridade para os cálculos de similaridade subjacentes. Tal similaridade geralmente é quantificada como distância espacial entre vetores, sendo as métricas comuns a distância euclidiana, a distância do cosseno e a distância do produto interno.
- Suporte à indexação vetorial
Em comparação com índices baseados em B-tree ou LSM-tree em bancos de dados tradicionais, índices vetoriais de alta dimensionalidade geralmente consomem muito mais recursos computacionais. Recomendamos o uso de algoritmos de indexação por agrupamento e grafos, e dar prioridade a operações de matriz e vetor, aproveitando assim ao máximo as capacidades de aceleração de cálculo vetorial por hardware mencionadas anteriormente.
- Experiência de usuário consistente em diferentes ambientes de implantação
Bancos de dados vetoriais geralmente são desenvolvidos e implantados em diferentes ambientes. Na etapa preliminar, cientistas de dados e engenheiros de algoritmos trabalham principalmente em seus laptops e estações de trabalho, pois dão mais atenção à eficiência da verificação e à velocidade de iteração. Quando a verificação é concluída, eles podem implantar o banco de dados em tamanho completo em um cluster privado ou na nuvem. Portanto, um sistema de banco de dados vetorial qualificado deve oferecer desempenho e experiência de usuário consistentes em diferentes ambientes de implantação.
- Suporte para pesquisa híbrida
Novas aplicações estão surgindo à medida que bancos de dados vetoriais se tornam onipresentes. Entre todas essas demandas, a mais frequentemente mencionada é a pesquisa híbrida em vetores e outros tipos de dados. Alguns exemplos disso são a busca aproximada de vizinhos mais próximos (ANNS) após filtragem escalar, recuperação multicanal a partir de pesquisa de texto completo e pesquisa vetorial, e pesquisa híbrida de dados espaço-temporais e dados vetoriais. Tais desafios exigem escalabilidade elástica e otimização de consultas para fundir efetivamente mecanismos de pesquisa vetorial com KV, texto e outros mecanismos de pesquisa.
- Arquitetura nativa da nuvem
O volume de dados vetoriais cresce rapidamente com o crescimento exponencial da coleta de dados. Dados vetoriais de alta dimensionalidade em escala de trilhões correspondem a milhares de TB de armazenamento, o que está muito além do limite de um único nó. Como resultado, a extensibilidade horizontal é uma capacidade-chave para um banco de dados vetorial, e deve satisfazer as demandas dos usuários por elasticidade e agilidade de implantação. Além disso, também deve reduzir a complexidade de operação e manutenção do sistema, ao mesmo tempo em que melhora a observabilidade com a assistência da infraestrutura de nuvem. Algumas dessas necessidades vêm na forma de isolamento multi-tenant, snapshot e backup de dados, criptografia de dados e visualização de dados, que são comuns em bancos de dados tradicionais.
Arquitetura do sistema de banco de dados vetorial
O Milvus 2.0 segue os princípios de design de "log como dados", "processamento unificado em lote e fluxo", "stateless" e "microservices". A Figura 4 mostra a arquitetura geral do Milvus 2.0.
Figura 4: Arquitetura geral do Milvus 2.0
Log como dados: O Milvus 2.0 não mantém nenhuma tabela física. Em vez disso, garante a confiabilidade dos dados por meio da persistência de logs e snapshots de logs. O broker de logs (a espinha dorsal do sistema) armazena logs e desacopla componentes e serviços por meio do mecanismo de publicação-assinatura (pub-sub) de logs. Como mostrado na Figura 5, o broker de logs é composto por "sequência de logs" e "assinante de logs". A sequência de logs registra todas as operações que alteram o estado de uma coleção (equivalente a uma tabela em um banco de dados relacional ); o assinante de logs assina a sequência de logs para atualizar seus dados locais e fornecer serviços na forma de cópias somente leitura. O mecanismo pub-sub também abre espaço para a extensibilidade do sistema em termos de captura de dados de alteração (CDC) e implantação distribuída globalmente.
Figura 5: Um modelo simplificado para armazenamento de logs
Processamento unificado em lote e em fluxo: O streaming de logs permite que o Milvus atualize dados em tempo real, garantindo assim a entrega em tempo real. Além disso, ao transformar lotes de dados em snapshots de logs e construir índices sobre snapshots, o Milvus é capaz de alcançar maior eficiência de consulta. Durante uma consulta, o Milvus mescla os resultados da consulta provenientes tanto de dados incrementais quanto de dados históricos para garantir a integridade dos dados retornados. Esse design equilibra melhor o desempenho em tempo real e a eficiência, aliviando a carga de manutenção tanto dos sistemas online quanto offline em comparação com a arquitetura Lambda tradicional.
Sem estado: A infraestrutura em nuvem e os componentes de armazenamento de código aberto liberam o Milvus de persistir dados dentro de seus próprios componentes. O Milvus 2.0 persiste dados com três tipos de armazenamento: armazenamento de metadados, armazenamento de logs e armazenamento de objetos. O armazenamento de metadados não apenas armazena os metadados, mas também lida com a descoberta de serviços e o gerenciamento de nós. O armazenamento de logs executa a persistência de dados incrementais e a publicação-assinatura de dados. O armazenamento de objetos armazena snapshots de logs, índices e alguns resultados intermediários de cálculo.
Microsserviços: O Milvus segue os princípios de desagregação do plano de dados e do plano de controle, separação de leitura/escrita e separação de tarefas online/offline. Ele é composto por quatro camadas de serviço: a camada de acesso, a camada coordenadora, a camada de trabalho e a camada de armazenamento. Essas camadas são mutuamente independentes quando se trata de escalabilidade e recuperação de desastres. Como a camada voltada para a frente e endpoint do usuário, a camada de acesso lida com conexões de clientes, valida solicitações de clientes e combina resultados de consultas. Como o "cérebro" do sistema, a camada coordenadora assume as tarefas de gerenciamento da topologia do cluster, balanceamento de carga, declaração de dados e gerenciamento de dados. A camada de trabalho contém os "membros" do sistema, executando atualizações de dados, consultas e operações de construção de índices. Por fim, a camada de armazenamento é responsável pela persistência e replicação de dados. No geral, esse design baseado em microsserviços garante uma complexidade de sistema controlável, com cada componente responsável por sua função correspondente. O Milvus esclarece os limites dos serviços por meio de interfaces bem definidas e desacopla os serviços com base em granularidade mais fina, o que otimiza ainda mais a escalabilidade elástica e a distribuição de recursos.
Desafios técnicos enfrentados por bancos de dados vetoriais
As primeiras pesquisas sobre bancos de dados vetoriais concentraram-se principalmente no design de estruturas de índice e métodos de consulta de alta eficiência - isso resultou em uma variedade de bibliotecas de algoritmos de busca vetorial (Referência nº 3~5). Nos últimos anos, um número crescente de equipes acadêmicas e de engenharia passou a examinar novamente as questões de busca vetorial sob a perspectiva do design de sistemas e propôs algumas soluções sistemáticas. Resumindo os estudos existentes e a demanda dos usuários, categorizamos os principais desafios técnicos para bancos de dados vetoriais da seguinte forma:
- Otimização da relação custo-desempenho em relação à carga
Em comparação com os tipos de dados tradicionais, a análise de dados vetoriais exige muito mais recursos de armazenamento e computação devido à sua alta dimensionalidade. Além disso, os usuários demonstraram preferências diversas por características de carga e otimização de custo-desempenho em soluções de busca vetorial. Por exemplo, usuários que trabalham com conjuntos de dados extremamente grandes (dezenas ou centenas de bilhões de vetores) prefeririam soluções com menores custos de armazenamento de dados e menor variação na latência de busca, enquanto outros podem exigir maior desempenho de busca e uma latência média não variável. Para satisfazer preferências tão diversas, o componente central de índice do banco de dados vetorial deve ser capaz de oferecer suporte a estruturas de índice e algoritmos de busca com diferentes tipos de armazenamento e hardware de computação.
Por exemplo, armazenar dados vetoriais e os dados de índice correspondentes em meios de armazenamento mais baratos (como NVM e SSD) deve ser levado em consideração ao reduzir os custos de armazenamento. No entanto, a maioria dos algoritmos de busca vetorial existentes trabalha com dados lidos diretamente da memória. Para evitar a perda de desempenho causada pelo uso de unidades de disco, o banco de dados vetorial deve ser capaz de explorar a localidade do acesso aos dados combinada com algoritmos de busca, além de ser capaz de se ajustar a soluções de armazenamento para dados vetoriais e estrutura de índice (Referência nº 6~8). Em prol de melhorias de desempenho, a pesquisa contemporânea tem se concentrado em tecnologias de aceleração por hardware envolvendo GPU, NPU, FPGA etc. (Referência nº 9). No entanto, hardwares e chips específicos para aceleração variam em design de arquitetura, e o problema da execução mais eficiente entre diferentes aceleradores de hardware ainda não foi resolvido.
- Configuração e ajuste automatizados do sistema
A maioria dos estudos existentes sobre algoritmos de busca vetorial busca um equilíbrio flexível entre custos de armazenamento, desempenho computacional e precisão da busca. Geralmente, tanto os parâmetros do algoritmo quanto as características dos dados influenciam o desempenho real de um algoritmo. Como as demandas dos usuários diferem em custos e desempenho, selecionar um método de consulta vetorial que atenda às suas necessidades e características dos dados representa um desafio significativo.
No entanto, métodos manuais de analisar os efeitos da distribuição dos dados nos algoritmos de busca não são eficazes devido à alta dimensionalidade dos dados vetoriais. Para abordar essa questão, a academia e a indústria estão buscando soluções de recomendação de algoritmos baseadas em aprendizado de máquina (Referência nº 10).
O design de um algoritmo inteligente de busca vetorial impulsionado por ML também é um ponto de destaque na pesquisa. De modo geral, os algoritmos de busca vetorial existentes são desenvolvidos universalmente para dados vetoriais com várias dimensionalidades e padrões de distribuição. Como resultado, eles não oferecem suporte a estruturas de índice específicas de acordo com as características dos dados e, portanto, têm pouco espaço para otimização. Estudos futuros também devem explorar tecnologias eficazes de aprendizado de máquina que possam personalizar estruturas de índice para diferentes características dos dados (Referência nº 11-12).
- Suporte a semânticas avançadas de consulta
Aplicações modernas frequentemente dependem de consultas mais avançadas entre vetores - as semânticas tradicionais de busca pelo vizinho mais próximo já não são mais aplicáveis à busca de dados vetoriais. Além disso, está surgindo a demanda por busca combinada entre múltiplos bancos de dados vetoriais ou em dados vetoriais e não vetoriais (Referência nº 13).
Especificamente, as variações nas métricas de distância para similaridade vetorial crescem rapidamente. Pontuações tradicionais de similaridade, como distância Euclidiana, distância de produto interno e distância de cosseno, não conseguem satisfazer todas as demandas das aplicações. Com a popularização da tecnologia de inteligência artificial, muitas indústrias estão desenvolvendo suas próprias métricas de similaridade vetorial específicas de seus campos, como distância de Tanimoto, distância de Mahalanobis, Superestrutura e Subestrutura. Integrar essas métricas de avaliação aos algoritmos de busca existentes e projetar novos algoritmos utilizando essas métricas são ambos problemas de pesquisa desafiadores.
À medida que a complexidade dos serviços dos usuários aumenta, as aplicações precisarão pesquisar tanto em dados vetoriais quanto em dados não vetoriais. Por exemplo, um recomendador de conteúdo analisa as preferências dos usuários, relações sociais, e as combina com os tópicos em alta no momento para fornecer conteúdo adequado aos usuários. Essas buscas normalmente envolvem consultas em múltiplos tipos de dados ou entre múltiplos sistemas de processamento de dados. Dar suporte a essas buscas híbridas de forma eficiente e flexível é outro desafio de design de sistemas.
Autores
Dr. Rentong Guo (Ph.D. em Software e Teoria da Computação, Universidade de Ciência e Tecnologia de Huazhong), sócio e Diretor de P&D da Zilliz. Ele é membro do Comitê Técnico de Computação e Processamento Distribuídos da China Computer Federation (CCF TCDCP). Sua pesquisa concentra-se em banco de dados, sistemas distribuídos, sistemas de cache e computação heterogênea. Seus trabalhos de pesquisa foram publicados em várias conferências e periódicos de primeira linha, incluindo Usenix ATC, ICS, DATE, TPDS. Como arquiteto do Milvus, Dr. Guo busca soluções para desenvolver sistemas de análise de dados baseados em IA altamente escaláveis e eficientes em custo.
Xiaofan Luan, sócio e Diretor de Engenharia da Zilliz, e membro do Comitê Consultivo Técnico da LF AI & Data Foundation. Ele trabalhou sucessivamente na sede da Oracle nos EUA e na Hedvig, uma startup de armazenamento definido por software. Ele ingressou na equipe de Banco de Dados do Alibaba Cloud e foi responsável pelo desenvolvimento do banco de dados NoSQL HBase e do Lindorm. Luan obteve seu mestrado em Engenharia de Computação Eletrônica pela Cornell University.
Dr. Xiaomeng Yi (Ph.D. em Arquitetura de Computadores, Universidade de Ciência e Tecnologia de Huazhong), Pesquisador Sênior e líder da equipe de Pesquisa da Zilliz. Sua pesquisa concentra-se em gerenciamento de dados de alta dimensão, recuperação de informações em larga escala e alocação de recursos em sistemas distribuídos. Os trabalhos de pesquisa do Dr. Yi foram publicados em periódicos líderes e conferências internacionais, incluindo IEEE Network Magazine, IEEE/ACM TON, ACM SIGMOD, IEEE ICDCS e ACM TOMPECS.
Filip Haltmayer, Engenheiro de Dados da Zilliz, formou-se pela University of California, Santa Cruz com um BS em Ciência da Computação. Após ingressar na Zilliz, Filip passa a maior parte do tempo trabalhando em implantações em nuvem, interações com clientes, palestras técnicas e desenvolvimento de aplicações de IA.
Referências
- Projeto Milvus: https://github.com/milvus-io/milvus
- Milvus: Um Sistema de Gerenciamento de Dados Vetoriais Desenvolvido para um Propósito Específico, SIGMOD'21
- Projeto Faiss: https://github.com/facebookresearch/faiss
- Projeto Annoy: https://github.com/spotify/annoy
- Projeto SPTAG: https://github.com/microsoft/SPTAG
- GRIP: Busca de Vizinhos Mais Próximos de Alto Desempenho e Capacidade Otimizada com Múltiplos Armazenamentos para Motor de Busca Vetorial, CIKM'19
- DiskANN: Busca Rápida e Precisa de Vizinhos Mais Próximos em um Bilhão de Pontos em um Único Nó, NIPS'19
- HM-ANN: Busca Eficiente de Vizinhos Mais Próximos em Bilhão de Pontos em Memória Heterogênea, NIPS'20
- SONG: Busca Aproximada de Vizinhos Mais Próximos em GPU, ICDE'20
- Uma demonstração do serviço de ajuste do sistema de gerenciamento automático de banco de dados ottertune, VLDB'18
- O Caso das Estruturas de Índice Aprendidas, SIGMOD'18
- Melhorando a Busca Aproximada de Vizinhos Mais Próximos por meio de Encerramento Antecipado Adaptativo Aprendido, SIGMOD'20
- AnalyticDB-V: Um Mecanismo Analítico Híbrido para Fusão de Consultas para Dados Estruturados e Não Estruturados, VLDB'20
Interaja com nossa comunidade de código aberto:
Continue lendo
VDBBench Adds Cost-Aware Benchmarking for Vector Databases
Compare Zilliz Cloud, Pinecone, and turbopuffer with VDBBench cost-aware vector database benchmarks across latency, freshness, multitenancy, and cold starts.
We spent 8 years making vector databases faster. Then we stopped.
Rarely queried embeddings still need to stay searchable. See how Vector Lakebase enables on-demand vector search without always-on compute costs.
Balancing Precision and Performance: How Zilliz Cloud's New Parameters Help You Optimize Vector Search
Optimize vector search with Zilliz Cloud’s level and recall features to tune accuracy, balance performance, and power AI applications.