O que fazer quando o Qdrant precisa de mais capacidade

Vertical primeiro: operações mais simples, sem sobrecarga de rede, bom para até ~100 milhões de vetores por nó, dependendo das dimensões e quantização. Horizontal quando: os dados excedem a capacidade de um único nó, é necessária tolerância a falhas, é necessário isolar inquilinos ou há gargalo de IOPS (mais nós = mais IOPS independentes).

Configuração distribuída mais básica

• 3 nós, 3 shards com replication_factor: 2 para escalabilidade sem tempo de inatividade

Um mínimo de 3 nós é importante para consenso e tolerância a falhas. Com 3 nós, você pode perder 1 nó sem tempo de inatividade. Com 2 nós, perder 1 nó causa tempo de inatividade para operações de coleção. Um fator de replicação de 2 significa que cada shard tem 1 réplica, então você tem 2 cópias dos dados. Isso permite escalabilidade e manutenção sem tempo de inatividade. Com replication_factor: 1, o tempo de inatividade zero não é garantido mesmo para operações em nível de ponto, e a manutenção do cluster requer tempo de inatividade.

Escolhendo o número de shards

Shards são a unidade de distribuição de dados. Mais shards permitem mais nós e melhor distribuição, mas adicionam sobrecarga. Menos shards reduzem a sobrecarga, mas limitam a escalabilidade horizontal.

Para um cluster de 3 a 6 nós, o número recomendado de shards é de 6 a 12. Isso permite 2 a 4 shards por nó, o que equilibra distribuição e sobrecarga.

Alterando o número de shards

Use quando: o número de shards não é divisível igualmente pelo número de nós, causando distribuição desigual, ou quando é necessário rebalancear.

O rebalanceamento de shards é caro e demorado, devendo ser usado como último recurso se a distribuição regular de dados não for possível. O rebalanceamento de shards é projetado para ser transparente para as operações do usuário; atualizações e buscas devem continuar funcionando durante o rebalanceamento, com um pequeno impacto no desempenho.

Mas a operação de rebalanceamento de shards em si é demorada e requer a movimentação de grandes quantidades de dados entre os nós.

• Disponível no Qdrant Cloud Rebalanceamento de Shards
• O rebalanceamento de shards não está disponível para implantações auto-hospedadas.

Melhores alternativas: pré-provisionar shards inicialmente ou iniciar um novo cluster com a configuração correta e migrar os dados.

O que NÃO fazer

• Não pule para o horizontal antes de esgotar o vertical (adiciona complexidade sem ganho)
• Não defina shard_number que não seja um múltiplo do número de nós (distribuição desigual)
• Não use replication_factor: 1 em produção se precisar de tolerância a falhas
• Não adicione nós sem rebalancear shards (use a API de movimentação de shards para redistribuir)
• Não reduza a RAM sem testes de carga (a evacuação do cache causa incidentes de latência de dias)
• Não atinja o limite de coleção usando uma coleção por inquilino (use particionamento de payload)