Considerações sobre a alocação de recursos para sistemas mongot

Calcular um tamanho de índice de linha de base

Use a seguinte fórmula como ponto de partida para sua estimativa de espaço em disco:

Estimated Index Size = (Number of Documents) x (Avg. Size of Indexed Text per Doc) x (Expansion Factor)

O fator de expansão é crítico e depende muito da sua estratégia de tokenização. Use estes multiplicadores como guia:

Adicionar tamanho do índice vetorial

Para pesquisa vetorial, calcule o tamanho do índice separadamente e adicione-o ao total. O tamanho dos dados vetoriais brutos é uma linha de base razoável para esse valor.

Vector Index Size = (Total Number of Vectors) x (Vector Dimensions) x 4 bytes / dimension

Gerencie o consumo de memória para evitar a instabilidade

Usar mapeamentos estáticos

Se a estrutura do documento for imprevisível, desative os mapeamentos dinâmicos. O mapeamento dinâmico pode levar a uma "explosão de mapeamento" em que milhares de campos não intencionais são criados, consumindo RAM excessiva e causando instabilidade. Defina explicitamente seu índice com dynamic: false. Para saber mais, consulte Mapeamentos estáticos e dinâmicos.

Limitar campos de origem armazenados

Armazene somente o conjunto mínimo de campos exigidos para seus resultados de pesquisa dentro do próprio índice mongot. A busca de campos da collection primária do MongoDB geralmente é mais eficiente e reduz o espaço em disco usado pelo índice. Para saber mais, consulte Definir campos de origem armazenados no índice de pesquisa do MongoDB.

Contabilizar recursos de alta memória

Esteja ciente de que coleções de sinônimos e embeddedDocuments profundamente aninhados criam artefatos de memória significativos. Se você utilizar fortemente esses recursos, deverá alocar mais espaço de heap Java para o processo mongot.

Combine recursos com sua taxa de escrita

Alta taxa de gravação (>1,000 operação por segundo)

Esse volume de trabalho é limitado a CPU e a E/S. Provisione servidores com alta contagem de CPU e armazenamento rápido. Monitore a utilização da CPU do processo mongot e o comprimento da fila de E/S do disco. Se essas métricas forem consistentemente altas e o atraso de replicação estiver crescendo, você precisará escalar seu hardware.

Baixa taxa de gravação ( <100 operações por segundo)

As configurações de hardware padrão geralmente são suficientes.

Minimizar atraso de replicação

Consolide índices

Evite definir vários índices de pesquisa separados em uma única collection. Cada índice adiciona sobrecarga. Em vez disso, crie uma única e abrangente definição de índice.

Materializar visualizações complexas

Se você estiver indexando uma visualização complexa, o desempenho do change stream pode ser uma restrição. Considere a possibilidade de criar uma visualização materializada para fornecer uma fonte de dados simples e pré-agregados para mongot indexar.

Planejar reconstruções de índices

A alteração de uma definição de índice aciona uma reconstrução completa e com uso intensivo de recursos.

Uma reconstrução cria um novo índice além do antigo antes de alternar as solicitações de query para o novo índice. Certifique-se sempre de ter pelo menos 125% do tamanho do índice atual disponível como espaço livre em disco para acomodar esse processo sem ficar sem armazenamento.

Escale horizontalmente com fragmentação

Para volumes de trabalho de gravação extremamente exigidos, dimensionar um único nó mongot verticalmente pode não ser suficiente.

Se você antecipar cargas de gravação sustentadas superiores a 10,000 operações por segundo, a fragmentação é a estratégia de escalabilidade mais eficaz. Você precisa de um mínimo de 1 mongot por shard. mongot indexa collections somente dentro do fragmento ao qual está conectado, o que ajuda a distribuir a carga de indexação horizontalmente.

Estime os núcleos de CPU necessários

Para estabelecer uma linha de base da CPU, use seu alvo de Queries por Segundo (QPS). Um ponto de partida geral é 1 núcleos de CPU para cada 10 QPS.

Esta linha de base pressupõe queries simples. Para volumes de trabalho pesados com aggregations complexas, correspondência difusa ou queries regex, você só pode obter 2-5 QPS por núcleo. Por outro lado, a correspondência simples de termo pode gerar 20+ QPS por núcleo. Sempre teste o desempenho com uma mistura realista de consultas.

Alocar RAM para baixa latência

A RAM é o fator mais importante para queries rápidas.

Full Text Search

O objetivo é caber o máximo possível do índice no cache do sistema de arquivos do sistema operacional. Para um desempenho ideal, provisione RAM suficiente no nó mongot para corresponder ao tamanho total do índice no disco. Isso minimiza leituras de disco lentas.

Vector Search

Para pesquisa vetorial de baixa latência, o índice de gráfico HNSW deve existir na memória. Para calcular a RAM mínima necessária, use as etapas no procedimento de estimativa de tamanho do índice e adicione um buffer de 20-25% para a sobrecarga. Se o índice do vetor não couber na RAM, a latência da query aumentará.