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

milvus-logo
LFAI
  • Home
  • Blog
  • Como é que o Milvus equilibra a carga das consultas nos nós?

Como é que o Milvus equilibra a carga das consultas nos nós?

  • Engineering
February 28, 2022
Xi Ge

Binlog Cover Image Imagem de capa do Binlog

Por Xi Ge.

Em artigos anteriores do blogue, introduzimos sucessivamente as funções Deletion, Bitset e Compaction no Milvus 2.0. Para culminar esta série, gostaríamos de partilhar o design por detrás do Load Balance, uma função vital no cluster distribuído do Milvus.

Implementação

Enquanto o número e o tamanho dos segmentos armazenados em buffer nos nós de consulta diferem, o desempenho da pesquisa nos nós de consulta também pode variar. O pior caso pode acontecer quando alguns nós de pesquisa estão esgotados a pesquisar uma grande quantidade de dados, mas os nós de pesquisa recém-criados permanecem inactivos porque nenhum segmento lhes é distribuído, causando um enorme desperdício de recursos da CPU e uma enorme queda no desempenho da pesquisa.

Para evitar tais circunstâncias, o coordenador da consulta (query coord) é programado para distribuir segmentos uniformemente para cada nó de consulta de acordo com o uso de RAM dos nós. Assim, os recursos da CPU são consumidos igualmente entre os nós, melhorando significativamente o desempenho da pesquisa.

Acionar o balanceamento de carga automático

De acordo com o valor predefinido da configuração queryCoord.balanceIntervalSeconds, a coordenação da consulta verifica a utilização da RAM (em percentagem) de todos os nós de consulta a cada 60 segundos. Se uma das seguintes condições for satisfeita, o coordenador de consultas começa a equilibrar a carga de consultas no nó de consulta:

  1. A utilização de RAM de qualquer nó de consulta no cluster é superior a queryCoord.overloadedMemoryThresholdPercentage (predefinição: 90);
  2. Ou o valor absoluto da diferença de uso de RAM de quaisquer dois nós de consulta é maior que queryCoord.memoryUsageMaxDifferencePercentage (padrão: 30).

Depois de os segmentos serem transferidos do nó de consulta de origem para o nó de consulta de destino, devem também satisfazer as duas condições seguintes:

  1. A utilização de RAM do nó de consulta de destino não é superior a queryCoord.overloadedMemoryThresholdPercentage (predefinição: 90);
  2. O valor absoluto da diferença de uso de RAM dos nós de consulta de origem e destino após o balanceamento de carga é menor do que antes do balanceamento de carga.

Com as condições acima satisfeitas, a coordenação da consulta procede ao equilíbrio da carga da consulta entre os nós.

Equilíbrio da carga

Quando o equilíbrio da carga é acionado, o coordenador da consulta carrega primeiro o(s) segmento(s) de destino para o nó de consulta de destino. Ambos os nós de consulta devolvem os resultados de pesquisa do(s) segmento(s) de destino em qualquer pedido de pesquisa neste ponto para garantir a integralidade do resultado.

Depois de o nó de consulta de destino carregar com êxito o segmento de destino, o coordenador da consulta publica um sealedSegmentChangeInfo no canal de consulta. Como se mostra abaixo, onlineNodeID e onlineSegmentIDs indicam o nó de consulta que carrega o segmento e o segmento carregado, respetivamente, e offlineNodeID e offlineSegmentIDs indicam o nó de consulta que precisa de libertar o segmento e o segmento a libertar, respetivamente.

sealedSegmentChangeInfo sealedSegmentChangeInfo

Tendo recebido o sealedSegmentChangeInfo, o nó de consulta de origem liberta então o segmento de destino.

Load Balance Workflow Fluxo de trabalho de balanceamento de carga

Todo o processo é bem sucedido quando o nó de consulta de origem liberta o segmento de destino. Ao completar isso, a carga da consulta é definida como balanceada entre os nós de consulta, o que significa que o uso de RAM de todos os nós de consulta não é maior que queryCoord.overloadedMemoryThresholdPercentage, e o valor absoluto da diferença de uso de RAM dos nós de consulta de origem e destino após o balanceamento de carga é menor que antes do balanceamento de carga.

O que vem a seguir?

No blogue da série de novas funcionalidades 2.0, pretendemos explicar a conceção das novas funcionalidades. Leia mais nesta série de blogues!

Este é o final da série de blogues de novas funcionalidades do Milvus 2.0. Após esta série, estamos a planear uma nova série de Milvus Deep Dive, que introduz a arquitetura básica do Milvus 2.0. Por favor, fique atento.

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