• Sobre Milvus
  • Começar a trabalhar
  • Conceitos
  • Guia do utilizador
  • Importação de dados
  • Ferramentas de IA
  • Guia de Administração
  • Ferramentas
  • Integrações
  • Tutoriais
  • FAQs
  • API Reference

Desagregação Armazenamento/Computação

Seguindo o princípio da desagregação do plano de dados e do plano de controlo, o Milvus é composto por quatro camadas que são mutuamente independentes em termos de escalabilidade e de recuperação de desastres.

Camada de acesso

Composta por um grupo de proxies sem estado, a camada de acesso é a camada frontal do sistema e o ponto final para os utilizadores. Valida os pedidos dos clientes e reduz os resultados devolvidos:

  • O proxy é, por si só, apátrida. Fornece um endereço de serviço unificado utilizando componentes de balanceamento de carga como o Nginx, o Kubernetes Ingress, o NodePort e o LVS.
  • Como o Milvus utiliza uma arquitetura de processamento paralelo massivo (MPP), o proxy agrega e pós-processa os resultados intermédios antes de devolver os resultados finais ao cliente.

Coordenador

O Coordinator funciona como o cérebro do Milvus. Em qualquer momento, está ativo exatamente um Coordenador em todo o cluster, responsável pela manutenção da topologia do cluster, pelo agendamento de todos os tipos de tarefas e pela garantia de consistência ao nível do cluster.

A seguir estão algumas das tarefas tratadas pelo Coordenador:

  • Gerenciamento de DDL/DCL/TSO: Trata os pedidos de linguagem de definição de dados (DDL) e de linguagem de controlo de dados (DCL), tais como a criação ou eliminação de colecções, partições ou índices, bem como a gestão do timestamp Oracle (TSO) e a emissão de time ticker.
  • Gestão do serviço de streaming: Vincula o Write-Ahead Log (WAL) aos nós de streaming e fornece descoberta de serviço para o serviço de streaming.
  • Gestão de consultas: Gere a topologia e o equilíbrio de carga para os nós de consulta e fornece e gere as vistas de consulta de serviço para orientar o encaminhamento de consultas.
  • Gestão de dados históricos: Distribui tarefas offline, como compactação e criação de índices para nós de dados, e gerencia a topologia de segmentos e visualizações de dados.

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 coordenador. Os nós de trabalho são stateless graças à separação entre armazenamento e computação, e podem facilitar o scale-out do sistema e a recuperação de desastres quando implantados no Kubernetes. Existem três tipos de nós de trabalho:

Nó de streaming

O nó de streaming funciona como o "mini-cérebro" ao nível do shard, fornecendo garantias de consistência ao nível do shard e recuperação de falhas com base no armazenamento WAL subjacente. Entretanto, o nó de fluxo contínuo também é responsável pela consulta de dados crescentes e pela geração de planos de consulta. Além disso, também trata da conversão de dados crescentes em dados selados (históricos).

Nó de consulta

O nó de consulta carrega os dados históricos do armazenamento de objectos e fornece a consulta de dados históricos.

Nó de dados

O nó de dados é responsável pelo processamento offline dos dados históricos, como a compactação e a criação de índices.

Armazenamento

O armazenamento é o osso do sistema, responsável pela persistência dos dados. Inclui o meta-armazenamento, o corretor de registos e o armazenamento de objectos.

Meta-armazenamento

O meta-armazenamento armazena instantâneos de metadados, como o esquema de coleção e os pontos de controlo do consumo de mensagens. O armazenamento de metadados exige uma disponibilidade extremamente elevada, uma forte consistência e suporte de transacções, pelo que a Milvus escolheu o etcd para o meta storage. A Milvus também utiliza o etcd para o registo de serviços e a verificação da sua integridade.

Armazenamento de objectos

O armazenamento de objectos armazena ficheiros de instantâneos de registos, ficheiros de índice para dados escalares e vectoriais e resultados de consultas intermédias. O Milvus utiliza o MinIO como armazenamento de objectos e pode ser facilmente implementado no AWS S3 e no Azure Blob, dois dos serviços de armazenamento mais populares e económicos do mundo. No entanto, o armazenamento de objectos tem uma latência de acesso elevada e cobra pelo número de consultas. Para melhorar o seu desempenho e reduzir os custos, a Milvus planeia implementar a separação de dados cold-hot num conjunto de cache baseado em memória ou SSD.

Armazenamento WAL

O armazenamento WAL (Write-Ahead Log) é a base da durabilidade e consistência dos dados em sistemas distribuídos. Antes de qualquer alteração ser confirmada, é primeiro registada num registo - garantindo que, em caso de falha, pode recuperar exatamente onde parou.

As implementações comuns de WAL incluem Kafka, Pulsar e Woodpecker. Ao contrário das soluções tradicionais baseadas em disco, o Woodpecker adota um design nativo da nuvem, sem disco, que grava diretamente no armazenamento de objetos. Essa abordagem é dimensionada sem esforço de acordo com suas necessidades e simplifica as operações ao remover a sobrecarga de gerenciamento de discos locais.

Ao registar antecipadamente todas as operações de escrita, a camada WAL garante um mecanismo fiável de recuperação e consistência em todo o sistema, independentemente da complexidade do seu ambiente distribuído.

O que vem a seguir

Try Managed Milvus for Free

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

Get Started
Feedback

Esta página foi útil?