🚀 Experimente o Zilliz Cloud, o Milvus totalmente gerenciado, gratuitamente—experimente um desempenho 10x mais rápido! Experimente Agora>>

milvus-logo
LFAI
  • Home
  • Blog
  • Milvus 2.0 Redefinir a base de dados vetorial

Milvus 2.0 Redefinir a base de dados vetorial

  • Engineering
August 01, 2021
Xiaofan Luan

Foi ontem que escrevemos a primeira linha de código do Milvus em outubro de 2018. Em março de 2021, após 19 iterações testadas por mais de 1.000 utilizadores em todo o mundo, lançámos o Milvus 1.0, o nosso primeiro lançamento oficial com suporte a longo prazo. Sendo a base de dados vetorial de código aberto mais popular do mundo, o Milvus 1.0 conseguiu resolver algumas questões fundamentais na gestão vetorial, como as operações CRUD e a persistência de dados. No entanto, à medida que foram surgindo novos cenários e requisitos, começámos a aperceber-nos de que ainda há muitas outras questões por resolver. Este artigo apresenta uma recapitulação das observações que fizemos nos últimos três anos, os desafios que o Milvus 2.0 deverá enfrentar e porque é que o Milvus 2.0 é considerado uma melhor solução para esses desafios. Para saber mais sobre o que o Milvus 2.0 tem para oferecer, consulte as Notas de Lançamento do Milvus 2.0.

Desafios enfrentados pelo Milvus 1.x

Silo de dados: o Milvus 1.0 só é capaz de lidar com embeddings vectoriais gerados a partir de dados não estruturados e dá pouco apoio a consultas escalares. A desagregação do armazenamento de dados na sua conceção resulta em dados duplicados e aumenta a complexidade do desenvolvimento de aplicações, e a pesquisa híbrida entre dados vectoriais e escalares é insatisfatória devido à falta de um optimizador unificado.

Dilema entre atualidade e eficiência: O Milvus 1.0 é um sistema quase em tempo real, que se baseia em descargas regulares ou forçadas para garantir a visibilidade dos dados. Esta abordagem aumenta a complexidade e a incerteza do processamento de dados em fluxo contínuo a vários níveis. Além disso, embora se diga que esta abordagem de inserção em lote melhora a eficiência do processamento, continua a consumir muitos recursos. Por isso, é necessária uma abordagem de carregamento em massa.

Falta de escalabilidade e elasticidade: O Milvus 1.0 baseia-se no Mishards, uma solução de middleware de fragmentação, para atingir a escalabilidade, e no armazenamento ligado à rede (NAS) para a persistência dos dados. Esta arquitetura clássica baseada em armazenamento partilhado não contribui muito para a escalabilidade global pelas seguintes razões

  1. Apenas um nó de escrita é suportado em Mishards e não pode ser escalado.
  2. O escalonamento dos nós de leitura no Mishards é implementado usando roteamento consistente baseado em hash. Embora o hashing consistente seja fácil de implementar e ajude a resolver o problema da uniformidade da distribuição de dados, não é suficientemente flexível no escalonamento de dados e não consegue resolver o desajuste entre o tamanho dos dados e a potência computacional.
  3. O Milvus 1.0 depende do MySQL para gerir os metadados, mas as consultas e o tamanho do conjunto de dados que um servidor MySQL autónomo é capaz de gerir são bastante limitados.

Falta de alta disponibilidade: Uma observação que fizemos é que a maioria dos utilizadores do Milvus tende a favorecer a disponibilidade em detrimento da consistência, enquanto o Milvus 1.x carece de capacidades como réplicas na memória e recuperação de desastres e não está à altura em termos de alta disponibilidade. Por isso, estamos a explorar a possibilidade de sacrificar um certo grau de precisão para conseguir uma maior disponibilidade.

Custos proibitivos: O Milvus 1.0 depende do NAS para a persistência de dados, cujo custo é normalmente dez vezes superior ao de um armazenamento local ou de objectos. Uma vez que a pesquisa vetorial depende fortemente dos recursos de computação e da memória, os custos elevados em que incorre podem tornar-se um obstáculo à exploração de conjuntos de dados em grande escala ou de cenários empresariais complexos.

Experiência do utilizador pouco intuitiva:

  1. A implantação distribuída complicada acarreta custos operacionais elevados.
  2. Não está disponível uma interface gráfica do utilizador (GUI) bem concebida.
  3. As API pouco intuitivas tornaram-se um entrave ao desenvolvimento de aplicações.

A grande questão é saber se se deve passar do patch ou começar do zero. Charles Xie, o pai da Milvus, acredita que, tal como muitos fabricantes de automóveis tradicionais nunca conseguiram transformar progressivamente a Tesla, a Milvus tem de se tornar um fator de mudança no domínio do processamento e análise de dados não estruturados para prosperar. Foi esta convicção que nos levou a lançar o Milvus 2.0, uma base de dados vetorial nativa da nuvem refacturada.

A criação do Milvus 2.0

Princípios de design

Como nosso banco de dados vetorial nativo da nuvem de próxima geração, o Milvus 2.0 é construído em torno dos três princípios a seguir:

Primeiro, nativo da nuvem: Acreditamos que apenas as arquitecturas que suportam a separação do armazenamento e da computação podem ser escaladas a pedido e tirar o máximo partido da elasticidade da nuvem. Gostaríamos também de chamar a sua atenção para o design de microsserviços do Milvus 2.0, que inclui a separação de leitura e escrita, a separação de dados incrementais e históricos e a separação de tarefas com uso intensivo de CPU, memória e IO. Os microsserviços ajudam a otimizar a atribuição de recursos para a carga de trabalho heterogénea em constante mudança.

Logs como dados: No Milvus 2.0, o corretor de logs serve como a espinha dorsal do sistema: Todas as operações de inserção e atualização de dados têm de passar pelo corretor de registos, e os nós de trabalho executam operações CRUD subscrevendo e consumindo registos. Esse design reduz a complexidade do sistema ao mover funções essenciais, como persistência de dados e flashback, para a camada de armazenamento, e o pub-sub de logs torna o sistema ainda mais flexível e melhor posicionado para escalonamento futuro.

Processamento unificado de lote e fluxo: O Milvus 2.0 implementa a arquitetura Lambda unificada, que integra o processamento dos dados incrementais e históricos. Em comparação com a arquitetura Kappa, o Milvus 2.0 introduz o log backfill, que armazena instantâneos de log e índices no armazenamento de objectos para melhorar a eficiência da recuperação de falhas e o desempenho das consultas. Para dividir os dados não limitados (stream) em janelas limitadas, o Milvus adopta um novo mecanismo de marca de água, que divide os dados do stream em vários pacotes de mensagens de acordo com o tempo de escrita ou o tempo do evento, e mantém uma linha temporal para os utilizadores consultarem por tempo.

2.0 image 1.png 2.0 imagem 1.png

Arquitetura do sistema

Como já foi referido, a conceção do Milvus 2.0 segue rigorosamente os princípios da separação entre armazenamento e computação e da separação entre controlo e plano de dados. O sistema divide-se em quatro camadas: camada de acesso, serviço coordenador, nós de trabalho e armazenamento.

Camada de acesso: A interface: A camada de acesso é a camada frontal do sistema e o ponto final para os utilizadores. É responsável pelo encaminhamento dos pedidos e pela recolha dos resultados.

Serviço de coordenação: O serviço de coordenação atribui tarefas aos nós de trabalho e funciona como o cérebro do sistema. Existem quatro tipos de coordenadores: coordenador de raiz (root coord), coordenador de dados (data coord), coordenador de consulta (query coord) e coordenador de índice (index coord).

Nós de trabalho: Os braços e as pernas. Os nós de trabalho são executores burros que seguem as instruções do serviço coordenador e respondem aos pedidos de leitura/escrita da camada de acesso. Existem três tipos de nós de trabalho: nós de dados, nós de consulta e nós de índice.

Armazenamento: Os ossos. O armazenamento tem três tipos: meta storage, log broker e object storage.

  • Implementado pelo etcd, o meta-armazenamento é usado para armazenar metadados, como coleta e ponto de verificação para o serviço coordenador.
  • Implementado pelo Pulsar, o corretor de logs é usado principalmente para armazenar logs incrementais e implementar notificações assíncronas confiáveis.
  • Implementado pelo MinIO ou S3, o armazenamento de objectos é utilizado principalmente para armazenar instantâneos de registos e ficheiros de índice.

Segue-se o diagrama da arquitetura do sistema do Milvus 2.0: 2.0 image 2.png2.0 image 2.png

Caraterísticas principais

Os custos de funcionamento de uma base de dados envolvem não só o consumo de recursos em tempo de execução, mas também os potenciais custos de aprendizagem e os custos operacionais e de manutenção. Em termos práticos, quanto mais fácil de utilizar for uma base de dados, maior será a probabilidade de poupar esses custos potenciais. Desde o primeiro dia do calendário do Milvus, a facilidade de utilização está sempre no topo da nossa lista, e a última versão do Milvus 2.0 tem muito para oferecer no sentido de reduzir esses custos.

Sempre online

A fiabilidade dos dados e a sustentabilidade do serviço são os requisitos básicos para uma base de dados, e a nossa estratégia é "falhar barato, falhar pequeno e falhar frequentemente".

  • "Fail cheap" refere-se à separação entre armazenamento e computação, o que torna o tratamento da recuperação de falhas de nós simples e a baixo custo.
  • "Falhar pouco" refere-se à estratégia "dividir e conquistar", que simplifica a complexidade da conceção, fazendo com que cada serviço coordenador trate apenas de uma pequena parte dos dados de leitura/escrita/incremental/históricos.
  • "Falhar frequentemente" refere-se à introdução do teste do caos, que utiliza a injeção de falhas num ambiente de teste para simular situações como falhas de hardware e falhas de dependência e acelerar a descoberta de erros.

Pesquisa híbrida entre dados escalares e vectoriais

Para aproveitar a sinergia entre dados estruturados e não estruturados, o Milvus 2.0 suporta dados escalares e vectoriais e permite a pesquisa híbrida entre eles. A pesquisa híbrida ajuda os utilizadores a encontrar os vizinhos mais próximos que correspondem a um critério de filtragem. Atualmente, o Milvus suporta operações relacionais como EQUAL, GREATER THAN e LESS THAN, e operações lógicas como NOT, AND, OR e IN.

Consistência ajustável

Como uma base de dados distribuída que obedece ao teorema PACELC, o Milvus 2.0 tem de escolher entre consistência, disponibilidade e latência. Na maioria dos cenários, enfatizar demais a consistência dos dados na produção pode ser um exagero, pois permitir que uma pequena parte dos dados seja invisível tem pouco impacto na recuperação geral, mas pode melhorar significativamente o desempenho da consulta. Ainda assim, acreditamos que os níveis de consistência, tais como forte, staleness limitado, e sessão, têm a sua própria aplicação única. Por isso, o Milvus suporta consistência ajustável ao nível do pedido. Tomando os testes como exemplo, os utilizadores podem necessitar de uma consistência forte para garantir que os resultados dos testes estão absolutamente corretos.

Viagens no tempo

Os engenheiros de dados necessitam frequentemente de efetuar o rollback de dados para corrigir dados sujos e erros de código. As bases de dados tradicionais geralmente implementam a reversão de dados através de instantâneos ou mesmo de reciclagem de dados. Isto pode acarretar custos gerais e de manutenção excessivos. O Milvus mantém uma linha temporal para todas as operações de inserção e eliminação de dados, e os utilizadores podem especificar um carimbo temporal numa consulta para obter uma vista de dados num determinado momento. Com a viagem no tempo, o Milvus também pode implementar um backup ou clone de dados leve.

SDK Python ORM

O mapeamento relacional de objectos (ORM) permite que os utilizadores se concentrem mais no modelo de negócio de nível superior do que no modelo de dados subjacente, facilitando aos programadores a gestão das relações entre colecções, campos e programas. Para fechar a lacuna entre a prova de conceito (PoC) para algoritmos de IA e a implantação de produção, projetamos as APIs ORM do PyMilvus, que podem funcionar com uma biblioteca incorporada, uma implantação autônoma, um cluster distribuído ou até mesmo um serviço em nuvem. Com um conjunto unificado de APIs, proporcionamos aos utilizadores uma experiência de utilização consistente e reduzimos os custos de migração ou adaptação de código.

2.0 image 3.png 2.0 imagem 3.png

Ferramentas de apoio

  • O Milvus Insight é a interface gráfica de utilizador do Milvus que oferece funcionalidades práticas como a gestão do estado do cluster, a meta gestão e a consulta de dados. O código-fonte do Milvus Insight também será de fonte aberta como um projeto independente. Estamos à procura de mais colaboradores para se juntarem a este esforço.
  • Experiência fora da caixa (OOBE), implementação mais rápida: O Milvus 2.0 pode ser implantado usando helm ou docker-compose.
  • O Milvus 2.0 usa o Prometheus, um banco de dados de série temporal de código aberto, para armazenar dados de desempenho e monitoramento, e o Grafana, uma plataforma de observabilidade aberta, para visualização de métricas.

Olhando para o futuro

Em retrospetiva, acreditamos que a arquitetura do sistema baseada em grandes dados + aplicação de IA é demasiado complicada. A principal prioridade da comunidade Milvus sempre foi tornar o Milvus mais fácil de usar. No futuro, o projeto Milvus centrar-se-á nas seguintes áreas:

BD para IA: Para além das funções CRUD básicas, o Milvus, enquanto sistema de base de dados, precisa de ter um optimizador de consultas mais inteligente, capacidades de consulta de dados mais poderosas e funções de gestão de dados mais abrangentes. O nosso trabalho para a próxima fase centrar-se-á nas funções da linguagem de manipulação de dados (DML) e nos tipos de dados ainda não disponíveis no Milvus 2.0, incluindo a adição de operações de eliminação e atualização e o suporte de tipos de dados de cadeia.

IA para BD: O ajuste de parâmetros como tipos de índices, configurações do sistema, carga de trabalho do utilizador e tipos de hardware complica a utilização do Milvus e deve ser evitado tanto quanto possível. Começámos a analisar a carga do sistema e a recolher a frequência de acesso aos dados, e planeamos introduzir a afinação automática no futuro para reduzir os custos de aprendizagem.

Otimização de custos: O maior desafio para a recuperação de vectores é a necessidade de processar conjuntos de dados em grande escala num período de tempo limitado. Isto consome muita CPU e muita memória. A introdução da aceleração de hardware heterogéneo de GPU e FPGA na camada física pode reduzir significativamente a sobrecarga da CPU. Estamos também a desenvolver algoritmos híbridos de indexação ANN no disco e na memória para realizar consultas de elevado desempenho em conjuntos de dados maciços com memória limitada. Além disso, estamos a avaliar o desempenho dos algoritmos de indexação vetorial de código aberto existentes, como o ScaNN e o NGT.

Facilidade de utilização: A Milvus continua a melhorar a sua facilidade de utilização, fornecendo ferramentas de gestão de clusters, SDKs em várias línguas, ferramentas de implementação, ferramentas operacionais e muito mais.

Para saber mais sobre os planos de lançamento do Milvus, consulte o Milvus Roadmap.

Parabéns a todos os colaboradores da comunidade Milvus, sem os quais o Milvus 2.0 não teria sido possível. Sinta-se à vontade para submeter um problema ou contribuir com o seu código para a comunidade Milvus!


Sobre o autor

Xiaofan Luan trabalha atualmente na Zilliz como Diretor de Engenharia, gerindo a I&D do projeto Milvus. Ele tem 7 anos de experiência de trabalho focado na construção de sistemas de base de dados/armazenamento. Depois de se formar na Universidade de Cornell, trabalhou consecutivamente na Oracle, HEDVIG e Alibaba Cloud.

Try Managed Milvus for Free

Zilliz Cloud is hassle-free, powered by Milvus and 10x faster.

Get Started

Like the article? Spread the word

Continue Lendo