Utilização da base de dados de vectores Milvus para consultas em tempo real

Imagem da capa

Este artigo foi escrito por Xi Ge e transcrito por Angela Ni.

No post anterior, falámos sobre a inserção e persistência de dados no Milvus. Neste artigo, vamos continuar a explicar como os diferentes componentes do Milvus interagem entre si para completar a consulta de dados em tempo real.

Alguns recursos úteis antes de começar estão listados abaixo. Recomendamos que os leia primeiro para compreender melhor o tópico deste artigo.

• Mergulho profundo na arquitetura do Milvus
• Modelo de dados do Milvus
• O papel e a função de cada componente do Milvus
• Processamento de dados em Milvus
• Inserção e persistência de dados em Milvus

Carregar dados para o nó de consulta

Antes de uma consulta ser executada, os dados têm de ser carregados para os nós de consulta.

Existem dois tipos de dados que são carregados para o nó de consulta: dados de streaming do broker de registos e dados históricos do armazenamento de objectos (também designado por armazenamento persistente abaixo).

Fluxograma

A coordenação de dados é responsável pelo tratamento dos dados em fluxo contínuo que são continuamente introduzidos no Milvus. Quando um utilizador do Milvus chama collection.load() para carregar uma coleção, o coordenador de consulta consulta o coordenador de dados para saber quais os segmentos que foram persistidos no armazenamento e os seus pontos de controlo correspondentes. Um ponto de controlo é uma marca que indica que os segmentos persistidos antes do ponto de controlo são consumidos e que os segmentos após o ponto de controlo não o são.

Em seguida, a coordenada de consulta produz a estratégia de atribuição com base na informação da coordenada de dados: por segmento ou por canal. O alocador de segmentos é responsável pela alocação de segmentos no armazenamento persistente (dados em lote) para diferentes nós de consulta. Por exemplo, na imagem acima, o alocador de segmentos atribui os segmentos 1 e 3 (S1, S3) ao nó de consulta 1, e os segmentos 2 e 4 (S2, S4) ao nó de consulta 2. O alocador de canais atribui diferentes nós de consulta para assistir a múltiplos canais de manipulação de dados (DMChannels) no corretor de registo. Por exemplo, na imagem acima, o alocador de canais atribui o nó de consulta 1 para observar o canal 1 (Ch1) e o nó de consulta 2 para observar o canal 2 (Ch2).

Com a estratégia de atribuição, cada nó de consulta carrega os dados do segmento e observa os canais em conformidade. No nó de consulta 1 da imagem, os dados históricos (dados de lote) são carregados através dos S1 e S3 atribuídos a partir do armazenamento persistente. Entretanto, o nó de consulta 1 carrega dados incrementais (dados em fluxo contínuo), subscrevendo o canal 1 no corretor de registos.

Gestão de dados no nó de consulta

Um nó de consulta precisa de gerir os dados históricos e incrementais. Os dados históricos são armazenados em segmentos selados, enquanto os dados incrementais são armazenados em segmentos crescentes.

Gestão de dados históricos

Há principalmente duas considerações para a gestão de dados históricos: equilíbrio de carga e failover do nó de consulta.

Equilíbrio de carga

Por exemplo, como mostra a ilustração, ao nó de consulta 4 foram atribuídos mais segmentos selados do que aos restantes nós de consulta. Muito provavelmente, este facto fará com que o nó de consulta 4 seja o ponto de estrangulamento que torna mais lento todo o processo de consulta. Para resolver este problema, o sistema precisa de atribuir vários segmentos no nó de consulta 4 a outros nós de consulta. A isto chama-se equilíbrio de carga.

Failover do nó de consulta

Outra situação possível é ilustrada na imagem acima. Um dos nós, o nó de consulta 4, é subitamente desativado. Neste caso, a carga (segmentos atribuídos ao nó de consulta 4) tem de ser transferida para outros nós de consulta em funcionamento para garantir a exatidão dos resultados da consulta.

Gestão incremental dos dados

O nó de consulta observa os DMChannels para receber dados incrementais. O fluxograma é introduzido neste processo. Em primeiro lugar, filtra todas as mensagens de inserção de dados. Isto é para garantir que apenas os dados de uma partição específica são carregados. Cada coleção no Milvus tem um canal correspondente, que é partilhado por todas as partições dessa coleção. Por conseguinte, é necessário um fluxograma para filtrar os dados inseridos se um utilizador do Milvus só precisar de carregar dados de uma determinada partição. Caso contrário, os dados de todas as partições da coleção serão carregados no nó de consulta.

Depois de serem filtrados, os dados incrementais são inseridos em segmentos crescentes e passados para os nós de tempo do servidor.

Fluxograma

Durante a inserção de dados, é atribuído um carimbo de data/hora a cada mensagem de inserção. No DMChannel mostrado na imagem acima, os dados são inseridos por ordem, da esquerda para a direita. O carimbo de data/hora da primeira mensagem de inserção é 1; o da segunda, 2; e o da terceira, 6. A quarta mensagem marcada a vermelho não é uma mensagem de inserção, mas sim uma mensagem de marcação de tempo. Isto significa que os dados inseridos cujos carimbos de data/hora são inferiores a este carimbo de data/hora já se encontram no corretor de registo. Por outras palavras, os dados inseridos após esta mensagem de timetick devem todos ter carimbos de data/hora cujos valores são superiores a este timetick. Por exemplo, na imagem acima, quando o nó de consulta percebe que a marca de tempo atual é 5, isso significa que todas as mensagens de inserção cujo valor da marca de tempo é inferior a 5 são carregadas para o nó de consulta.

O nó de tempo do servidor fornece um valor tsafe atualizado sempre que recebe uma marca temporal do nó de inserção. tsafe significa tempo de segurança e todos os dados inseridos antes deste momento podem ser consultados. Por exemplo, se tsafe = 9, todos os dados inseridos com carimbos de data/hora inferiores a 9 podem ser consultados.

Consulta em tempo real em Milvus

A consulta em tempo real no Milvus é activada por mensagens de consulta. As mensagens de consulta são inseridas no corretor de registos por proxy. Em seguida, os nós de consulta obtêm as mensagens de consulta observando o canal de consulta no broker de registo.

Mensagem de consulta

Mensagem de consulta

Uma mensagem de consulta inclui as seguintes informações cruciais sobre uma consulta:

• msgID: ID da mensagem, o ID da mensagem de consulta atribuído pelo sistema.
• collectionID: O ID da coleção a consultar (se especificado pelo utilizador).
• execPlan: O plano de execução é utilizado principalmente para a filtragem de atributos numa consulta.
• service_ts: O carimbo de data/hora do serviço será atualizado juntamente com tsafe mencionado acima. O carimbo de data/hora do serviço indica em que ponto está o serviço. Todos os dados inseridos antes de service_ts estão disponíveis para consulta.
• travel_ts: O carimbo de data/hora da viagem especifica um intervalo de tempo no passado. E a consulta será efectuada sobre os dados existentes no período de tempo especificado por travel_ts.
• guarantee_ts: O carimbo de data/hora de garantia especifica um período de tempo após o qual a consulta tem de ser efectuada. A consulta só será efectuada quando service_ts > guarantee_ts.

Consulta em tempo real

Processo de consulta

Quando é recebida uma mensagem de consulta, o Milvus começa por verificar se o tempo de serviço atual, service_ts, é superior ao carimbo de garantia, guarantee_ts, indicado na mensagem de consulta. Em caso afirmativo, a consulta é executada. A consulta é efectuada em paralelo com os dados históricos e os dados incrementais. Uma vez que pode haver uma sobreposição de dados entre dados de fluxo contínuo e dados em lote, é necessária uma ação denominada "redução local" para filtrar os resultados redundantes da consulta.

No entanto, se o tempo de serviço atual for inferior ao carimbo de data/hora de garantia numa mensagem de consulta recentemente inserida, a mensagem de consulta tornar-se-á uma mensagem não resolvida e aguardará para ser processada até que o tempo de serviço se torne superior ao carimbo de data/hora de garantia.

Os resultados da consulta são finalmente enviados para o canal de resultados. O proxy obtém os resultados da consulta a partir desse canal. Da mesma forma, o proxy também efectua uma "redução global" porque recebe resultados de vários nós de consulta e os resultados da consulta podem ser repetitivos.

Para garantir que o proxy recebeu todos os resultados da consulta antes de os devolver ao SDK, a mensagem de resultado mantém também um registo de informações, incluindo os segmentos selados pesquisados, os DMChannels pesquisados e os segmentos selados globais (todos os segmentos em todos os nós de consulta). O sistema só pode concluir que o proxy recebeu todos os resultados da consulta se ambas as condições seguintes forem satisfeitas:

• A união de todos os segmentos selados pesquisados registados em todas as mensagens de resultados é maior do que os segmentos selados globais,
• Todos os DMChannels da coleção são consultados.

Por fim, o proxy retorna os resultados finais após a "redução global" para o Milvus SDK.

Sobre a série Deep Dive

Com o anúncio oficial da disponibilidade geral do Milvus 2.0, orquestrámos esta série de blogues Milvus Deep Dive para fornecer uma interpretação aprofundada da arquitetura e do código-fonte do Milvus. Os tópicos abordados nesta série de blogues incluem:

• Visão geral da arquitetura do Milvus
• APIs e SDKs Python
• Processamento de dados
• Gestão de dados
• Consulta em tempo real
• Motor de execução escalar
• Sistema QA
• Motor de execução vetorial