Serviço de Streaming

O Serviço de Fluxo é um conceito para o módulo interno do sistema de fluxo do Milvus, construído em torno do Registo de Escrita Antecipada (WAL) para suportar várias funções relacionadas com o fluxo. Estas incluem a ingestão/assinatura de dados de streaming, a recuperação de falhas do estado do cluster, a conversão de dados de streaming em dados históricos e consultas de dados crescentes. Em termos de arquitetura, o serviço de fluxo contínuo é composto por três componentes principais:

Arco distribuído de fluxo contínuo

• Coordenador de streaming: Um componente lógico no nó coordenador. Utiliza o Etcd para a descoberta de serviços para localizar os nós de fluxo disponíveis e é responsável pela ligação do WAL aos nós de fluxo correspondentes. Também regista o serviço para expor a topologia de distribuição do WAL, permitindo que os clientes de streaming conheçam o nó de streaming adequado para um determinado WAL.

• Cluster de nós de streaming: Um cluster de nós de trabalho de streaming responsável por todas as tarefas de processamento de streaming, como anexação de wal, recuperação de estado, consulta de dados crescentes.

• Cliente de Streaming: Um cliente Milvus desenvolvido internamente que encapsula funcionalidades básicas, como descoberta de serviços e verificações de prontidão. É utilizado para iniciar operações como a escrita de mensagens e a subscrição.

Mensagem

O serviço de fluxo contínuo é um sistema de fluxo contínuo orientado para o registo, pelo que todas as operações de escrita no Milvus (como DML e DDL) são abstraídas como mensagens.

• O Streaming Service atribui a cada mensagem um campo Timestamp Oracle (TSO), que indica a ordem da mensagem no WAL. A ordenação das mensagens determina a ordem das operações de escrita no Milvus. Isto torna possível reconstruir o estado mais recente do cluster a partir dos registos.

• Cada mensagem pertence a um VChannel (Virtual Channel) específico e mantém certas propriedades invariantes dentro desse canal para garantir a consistência da operação. Por exemplo, uma operação Insert deve sempre ocorrer antes de uma operação DropCollection no mesmo canal.

A ordem das mensagens em Milvus pode assemelhar-se à seguinte:

Ordem das mensagens

Componente WAL

Para suportar escalabilidade horizontal em larga escala, o WAL do Milvus não é um único arquivo de log, mas um composto de múltiplos logs. Cada registo pode suportar de forma independente a funcionalidade de fluxo contínuo para vários canais V. A qualquer momento, um componente WAL pode operar exatamente num nó de streaming, esta restrição é prometida por um mecanismo de vedação do armazenamento wal subjacente e pelo coordenador de streaming.

Outras caraterísticas do componente WAL incluem

• Gestão do ciclo de vida do segmento: Com base na política, como condições de memória/tamanho do segmento/tempo ocioso do segmento, o WAL gerencia o ciclo de vida de cada segmento.

• Suporte básico a transacções: Uma vez que cada mensagem tem um limite de tamanho, o componente WAL suporta o nível de transação simples para prometer escritas atómicas ao nível do VChannel.

• Escrita de Log Remoto de Alta-Concorrência: Milvus suporta filas de mensagens remotas de terceiros como armazenamento WAL. Para atenuar a latência de ida e volta (RTT) entre o nó de streaming e o armazenamento WAL remoto para melhorar a taxa de transferência de escrita, o serviço de streaming suporta escritas de registo simultâneas. Mantém a ordem das mensagens por TSO e sincronização TSO, e as mensagens no WAL são lidas por ordem TSO.

• Buffer de escrita antecipada: Depois de as mensagens serem escritas no WAL, são temporariamente armazenadas num buffer de escrita antecipada. Isto permite leituras de cauda de registos sem ir buscar mensagens ao armazenamento WAL remoto.

• Suporte a vários armazenamentos WAL: Woodpecker, Pulsar, Kafka. Usando o Woodpecker com modo de disco zero, podemos remover a dependência do armazenamento WAL remoto.

Armazenamento de recuperação

O componente Recovery Storage é sempre executado no nó de streaming em que o componente WAL correspondente está localizado.

• É responsável por converter os dados de streaming em dados históricos persistentes e armazená-los no armazenamento de objectos.

• Ele também lida com a recuperação de estado na memória para o componente WAL no nó de streaming.

Armazenamento de recuperação

Delegador de consultas

O Query Delegator é executado em cada nó de streaming e é responsável pela execução de consultas incrementais num único fragmento. Ele gera planos de consulta, encaminha-os para os nós de consulta relevantes e agrega os resultados.

Além disso, o Query Delegator é responsável pela transmissão das operações Delete para outros Query Nodes.

O Query Delegator coexiste sempre com o componente WAL no mesmo nó de streaming. Mas se a coleção estiver configurada com multi-replicação, então N-1 delegadores serão implementados nos outros nós de streaming.

Tempo de vida do WAL e espera para ficar pronto

Ao separar os nós de computação do armazenamento, o Milvus pode facilmente transferir o WAL de um nó de streaming para outro, alcançando alta disponibilidade no serviço de streaming.

Tempo de vida do WAL

Espera para estar pronto

Quando o WAL vai ser transferido para um novo nó de streaming, o cliente irá verificar que o antigo nó de streaming rejeita alguns pedidos. Entretanto, o WAL será recuperado no novo nó de streaming, o cliente aguardará que o wal no novo nó de streaming esteja pronto para servir.

esperar que esteja pronto