Réplica na Memória
Este tópico apresenta o mecanismo de réplica em memória (replicação) no Milvus que permite múltiplas réplicas de segmentos na memória de trabalho para melhorar o desempenho e a disponibilidade.
Para obter informações sobre como configurar réplicas na memória, consulte Configurações relacionadas ao nó de consulta.
Visão geral
Replica_Availiability
Com réplicas na memória, Milvus pode carregar o mesmo segmento em múltiplos nós de consulta. Se um nó de consulta falhar ou estiver ocupado com um pedido de pesquisa atual quando outro chegar, o sistema pode enviar novos pedidos para um nó de consulta inativo que tenha uma réplica do mesmo segmento.
Desempenho
As réplicas na memória permitem-lhe tirar partido de recursos extra de CPU e memória. É muito útil se você tiver um conjunto de dados relativamente pequeno, mas quiser aumentar a taxa de transferência de leitura com recursos extras de hardware. O QPS (consulta por segundo) e a taxa de transferência gerais podem ser significativamente melhorados.
Disponibilidade
As réplicas na memória ajudam o Milvus a recuperar mais rapidamente se um nó de consulta falhar. Quando um nó de consulta falha, o segmento não precisa ser recarregado em outro nó de consulta. Em vez disso, o pedido de pesquisa pode ser reenviado imediatamente para um novo nó de consulta sem ter de recarregar os dados novamente. Com várias réplicas de segmento mantidas simultaneamente, o sistema é mais resiliente em face de um failover.
Conceitos-chave
As réplicas na memória são organizadas como grupos de réplicas. Cada grupo de réplicas contém réplicas de fragmento. Cada réplica de fragmento tem uma réplica de fluxo contínuo e uma réplica histórica que correspondem aos segmentos crescentes e selados no fragmento (ou seja, canal DML).
Uma ilustração de como funciona a réplica na memória
Grupo de réplicas
Um grupo de réplicas consiste em vários nós de consulta que são responsáveis pelo tratamento de dados históricos e réplicas.
Réplica de fragmento
Uma réplica de fragmento é composta por uma réplica de fluxo contínuo e uma réplica histórica, ambas pertencentes ao mesmo fragmento. O número de réplicas de fragmentos num grupo de réplicas é determinado pelo número de fragmentos numa coleção especificada.
Réplica de fluxo contínuo
Uma réplica de streaming contém todos os segmentos crescentes do mesmo canal DML. Tecnicamente falando, uma réplica de streaming deve ser servida por apenas um nó de consulta numa réplica.
Réplica histórica
Uma réplica histórica contém todos os segmentos fechados do mesmo canal DML. Os segmentos fechados de uma réplica histórica podem ser distribuídos em vários nós de consulta dentro do mesmo grupo de réplicas.
Líder de fragmento
Um líder de fragmento é o nó de consulta que serve a réplica de fluxo em uma réplica de fragmento.
Detalhes do projeto
Balanço
Um novo segmento que precisa de ser carregado será atribuído a vários nós de consulta diferentes. Um pedido de pesquisa pode ser processado quando pelo menos uma réplica é carregada com sucesso.
Pesquisa
Cache
O proxy mantém uma cache que mapeia os segmentos para os nós de pesquisa e actualiza-a periodicamente. Quando o proxy recebe um pedido, Milvus obtém todos os segmentos selados que precisam de ser pesquisados a partir da cache e tenta atribuí-los aos nós de pesquisa uniformemente.
Para segmentos em crescimento, o proxy também mantém um cache channel-to-query-node e envia pedidos para os nós de consulta correspondentes.
Transferência em caso de falha
As caches no proxy nem sempre estão actualizadas. Alguns segmentos ou canais podem ter sido movidos para outros nós de consulta quando um pedido é recebido. Neste caso, o proxy receberá uma resposta de erro, actualizará a cache e tentará atribuí-la a outro nó de consulta.
Um segmento será ignorado se o proxy ainda não o conseguir encontrar depois de atualizar a cache. Isto pode acontecer se o segmento tiver sido compactado.
Se a cache não for exacta, o proxy pode não encontrar alguns segmentos. Os nós de consulta com canais DML (segmentos crescentes) devolvem respostas de pesquisa juntamente com uma lista de segmentos fiáveis com os quais o proxy pode comparar e atualizar a cache.
Melhoria
O proxy não pode atribuir pedidos de pesquisa aos nós de consulta de forma completamente igual e os nós de consulta podem ter recursos diferentes para servir os pedidos de pesquisa. Para evitar uma distribuição de recursos com cauda longa, o proxy atribuirá segmentos activos noutros nós de consulta a um nó de consulta inativo que também tenha esses segmentos.
