Visão geral da arquitetura distribuída

O objetivo do Milvus é conseguir uma pesquisa e análise de semelhanças eficiente para vectores de grande escala. Uma instância autónoma do Milvus pode lidar facilmente com a pesquisa de vectores à escala de mil milhões. No entanto, para 10 mil milhões, 100 mil milhões ou mesmo conjuntos de dados maiores, é necessário um cluster Milvus. O cluster pode ser utilizado como uma instância autónoma para aplicações de nível superior e pode satisfazer as necessidades comerciais de baixa latência e elevada simultaneidade para dados em grande escala. Um cluster Milvus pode reenviar pedidos, separar a leitura da escrita, escalar horizontalmente e expandir-se dinamicamente, fornecendo assim uma instância Milvus que pode expandir-se sem limites. Mishards é uma solução distribuída para Milvus.

Este artigo apresentará brevemente os componentes da arquitetura do Mishards. Informações mais detalhadas serão introduzidas nos próximos artigos.

1-milvus-cluster-mishards.png

Visão geral da arquitetura distribuída

2-distributed-architecture-overview.png

Rastreio de serviços

3-service-tracing-milvus.png

Componentes de serviço primários

• Estrutura de descoberta de serviços, como ZooKeeper, etcd e Consul.
• Balanceador de carga, como Nginx, HAProxy, Ingress Controller.
• Nó Mishards: sem estado, escalável.
• Nó Milvus só de escrita: nó único e não escalável. É necessário utilizar soluções de alta disponibilidade para este nó para evitar um ponto único de falha.
• Nó Milvus só de leitura: Nó com estado e escalável.
• Serviço de armazenamento partilhado: Todos os nós Milvus utilizam um serviço de armazenamento partilhado para partilhar dados, como o NAS ou o NFS.
• Serviço de metadados: Todos os nós Milvus utilizam este serviço para partilhar metadados. Atualmente, apenas o MySQL é suportado. Este serviço requer uma solução de alta disponibilidade MySQL.

Componentes escaláveis

• Mishards
• Nós Milvus só de leitura

Introdução aos componentes

Nós Mishards

O Mishards é responsável por dividir os pedidos a montante e encaminhar os subpedidos para os sub-serviços. Os resultados são resumidos para retornar ao upstream.

4-mishards-nodes.jpg

Como indicado no gráfico acima, depois de aceitar um pedido de pesquisa TopK, a Mishards começa por dividir o pedido em subpedidos e envia os subpedidos para o serviço a jusante. Quando todas as sub-respostas são recolhidas, as sub-respostas são fundidas e devolvidas ao serviço a montante.

Como o Mishards é um serviço sem estado, não guarda dados nem participa em cálculos complexos. Assim, os nós não têm grandes requisitos de configuração e o poder de computação é utilizado principalmente na fusão dos sub-resultados. Assim, é possível aumentar o número de nós Mishards para obter uma elevada concorrência.

Nós Milvus

Os nós Milvus são responsáveis pelas operações principais relacionadas com CRUD, pelo que têm requisitos de configuração relativamente elevados. Em primeiro lugar, o tamanho da memória deve ser suficientemente grande para evitar demasiadas operações de IO do disco. Em segundo lugar, as configurações da CPU também podem afetar o desempenho. À medida que o tamanho do cluster aumenta, são necessários mais nós Milvus para aumentar o rendimento do sistema.

Nós somente leitura e nós graváveis

• As operações principais do Milvus são a inserção e a pesquisa de vectores. A pesquisa tem requisitos extremamente altos nas configurações de CPU e GPU, enquanto a inserção ou outras operações têm requisitos relativamente baixos. A separação entre o nó que executa a pesquisa e o nó que executa outras operações permite uma implementação mais económica.
• Em termos de qualidade de serviço, quando um nó está a executar operações de pesquisa, o hardware relacionado está a funcionar em plena carga e não pode garantir a qualidade de serviço de outras operações. Por conseguinte, são utilizados dois tipos de nós. Os pedidos de pesquisa são processados por nós só de leitura e os outros pedidos são processados por nós com capacidade de escrita.

Só é permitido um nó gravável

• Atualmente, o Milvus não suporta a partilha de dados para várias instâncias graváveis.

• Durante a implementação, é necessário ter em conta um ponto único de falha dos nós graváveis. É necessário preparar soluções de alta disponibilidade para os nós graváveis.

Escalabilidade de nós só de leitura

Quando o tamanho dos dados é extremamente grande ou o requisito de latência é extremamente elevado, pode escalar horizontalmente os nós só de leitura como nós com estado. Suponha que haja 4 hosts e que cada um tenha a seguinte configuração: Núcleos de CPU: 16, GPU: 1, Memória: 64 GB. O gráfico a seguir mostra o cluster ao escalonar horizontalmente nós com estado. Tanto o poder de computação quanto a memória são escalonados linearmente. Os dados são divididos em 8 shards com cada nó processando solicitações de 2 shards.

5-read-only-node-scalability-milvus.png

Quando o número de solicitações é grande para alguns shards, nós stateless read-only podem ser implantados para esses shards para aumentar a taxa de transferência. Tome os hosts acima como exemplo. Quando os hosts são combinados em um cluster sem servidor, o poder de computação aumenta linearmente. Como os dados a processar não aumentam, o poder de processamento para o mesmo fragmento de dados também aumenta linearmente.

6-read-only-node-scalability-milvus-2.png

Serviço de metadados

Palavras-chave: MySQL

Para obter mais informações sobre os metadados do Milvus, consulte Como visualizar os metadados. Num sistema distribuído, os nós graváveis Milvus são os únicos produtores de metadados. Os nós Mishards, os nós graváveis Milvus e os nós somente leitura Milvus são todos consumidores de metadados. Atualmente, o Milvus apenas suporta MySQL e SQLite como backend de armazenamento de metadados. Num sistema distribuído, o serviço só pode ser implementado como MySQL altamente disponível.

Descoberta de serviços

Palavras-chave: Apache Zookeeper, etcd, Consul, Kubernetes

7-service-discovery.png

A descoberta de serviços fornece informações sobre todos os nós do Milvus. Os nós Milvus registam as suas informações quando ficam online e terminam a sessão quando ficam offline. Os nós Milvus também podem detetar nós anormais verificando periodicamente o estado de saúde dos serviços.

A descoberta de serviços contém uma série de estruturas, incluindo etcd, Consul, ZooKeeper, etc. Mishards define as interfaces de descoberta de serviços e oferece possibilidades de escalonamento por plugins. Atualmente, o Mishards fornece dois tipos de plugins, que correspondem ao cluster Kubernetes e a configurações estáticas. O utilizador pode personalizar a sua própria descoberta de serviços seguindo a implementação destes plugins. As interfaces são temporárias e precisam de ser redesenhadas. Mais informações sobre como escrever seu próprio plug-in serão elaboradas nos próximos artigos.

Balanceamento de carga e fragmentação de serviços

Palavras-chave: Nginx, HAProxy, Kubernetes

7-load-balancing-and-service-sharding.png

A descoberta de serviços e o balanceamento de carga são usados em conjunto. O balanceamento de carga pode ser configurado como polling, hashing ou hashing consistente.

O balanceador de carga é responsável por reenviar as solicitações do usuário para o nó da Mishards.

Cada nó Mishards adquire a informação de todos os nós Milvus a jusante através do centro de descoberta de serviços. Todos os metadados relacionados podem ser adquiridos pelo serviço de metadados. A Mishards implementa a fragmentação consumindo estes recursos. O Mishards define as interfaces relacionadas com as estratégias de encaminhamento e fornece extensões através de plugins. Atualmente, a Mishards fornece uma estratégia de hashing consistente baseada no nível de segmento mais baixo. Como é mostrado no gráfico, há 10 segmentos, s1 a s10. De acordo com a estratégia de hashing consistente baseada no segmento, a Mishards encaminha os pedidos relativos a s1, 24, s6 e s9 para o nó Milvus 1, s2, s3, s5 para o nó Milvus 2 e s7, s8, s10 para o nó Milvus 3.

Com base nas suas necessidades comerciais, pode personalizar o encaminhamento seguindo o plugin de encaminhamento de hashing consistente predefinido.

Rastreamento

Palavras-chave: OpenTracing, Jaeger, Zipkin

Dada a complexidade de um sistema distribuído, os pedidos são enviados para várias invocações de serviços internos. Para ajudar a identificar problemas, precisamos rastrear a cadeia de invocação de serviços internos. À medida que a complexidade aumenta, os benefícios de um sistema de rastreamento disponível são auto-explicativos. Escolhemos o padrão OpenTracing do CNCF. O OpenTracing fornece APIs independentes de plataforma e de fornecedor para que os programadores possam implementar convenientemente um sistema de rastreio.

8-tracing-demo-milvus.png

O gráfico anterior é um exemplo de rastreamento durante a invocação de pesquisa. A pesquisa invoca get_routing, do_search e do_merge consecutivamente. do_search também invoca search_127.0.0.1.

Todo o registo de rastreio forma a seguinte árvore:

8-search-traceid-milvus.png

O gráfico seguinte mostra exemplos de informações de pedido/resposta e etiquetas de cada nó:

request-response-info-tags-node-milvus.png

O OpenTracing foi integrado no Milvus. Mais informações serão abordadas nos próximos artigos.

Monitorização e alertas

Palavras-chave: Prometheus, Grafana

10-monitor-alerta-milvus.jpg

Resumo

Como middleware de serviço, o Mishards integra a descoberta de serviços, a solicitação de roteamento, a mesclagem de resultados e o rastreamento. A expansão baseada em plug-in também é fornecida. Atualmente, as soluções distribuídas baseadas no Mishards ainda têm os seguintes contratempos:

• O Mishards utiliza proxy como camada intermédia e tem custos de latência.
• Os nós graváveis do Milvus são serviços de ponto único.
• A implementação é complicada quando existem vários fragmentos e um único fragmento tem várias cópias.
• Falta uma camada de cache, como o acesso a metadados.

Iremos corrigir estes problemas conhecidos nas próximas versões para que os Mishards possam ser aplicados ao ambiente de produção de forma mais conveniente.