Revisar as opções de implantação

Requisitos de memória para a indexação de vetores

O Atlas Vector Search mantém todo o índice na memória, então você precisa garantir que haja memória suficiente para o índice do Atlas Vector Search e a JVM. Cada índice é uma combinação dos vetores que estão sendo indexados e metadados adicionais. O tamanho do índice é determinado principalmente pelo tamanho dos vetores que você está indexando, com o espaço de metadados normalmente sendo relativamente nominal.

Considere os seguintes requisitos para um único vetor:

Vetores quantizados BinData. Para saber mais, consulte Ingestão de vetores quantizados.

O espaço necessário é dimensionado linearmente com o número de vetores que você está indexando e com a dimensionalidade do vetor. Você também pode usar a métrica Search Index Size para determinar a quantidade de espaço e memória necessária em seus nós de pesquisa.

Requisitos de armazenamento para vetores

Se você usar BinData ou vetores quantizados, você reduzirá significativamente os requisitos de recursos em comparação com não usar binData ou vetores quantizados. Você perceberá:

• O armazenamento em disco de vetores em mongod é reduzido em 66% ao usar vetores binData.

• O uso de RAM por vetores em mongot é reduzido em 3.75x (escalar) ou 24x (binário) devido à compactação vetorial ao usar quantização automática de vetores ou ingestão de vetores quantizados.

Quando você usa a quantização automática, o Atlas armazena os vetores de precisão total para reclassificação ou pesquisa exata no disco, com uso mínimo de RAM e cache para reclassificação.

Se você ativar a quantização automática na definição do índice de pesquisa do Atlas Vector Search, deve também considerar o espaço em disco ao dimensionar seu cluster. Isso ocorre porque o Atlas Vector Search armazena vetores de precisão total também no disco para a pesquisa ENN e para reavaliação, caso você tenha configurado a quantização automática. Portanto, garanta que haja uma proporção adequada de disco para RAM no hardware que você utiliza. Considere configurar nós de pesquisa que possam acomodar aproximadamente uma proporção de 4:1 de armazenamento para RAM para quantização escalar ou uma proporção de 24:1 de armazenamento para RAM para quantização binária.

{
  "fields":[
    {
      "type": "vector",
      "path": "my-embeddings",
      "numDimensions": 1536,
      "similarity": "euclidean",
      "quantization": "binary"
    }
  ]
}

Use a fórmula a seguir para calcular aproximadamente o espaço em disco para o seu índice habilitado para quantização binária com reclassificação:

Original index size * (25/24)

Aqui, o 24 no denominador representa o tamanho original do índice dividido em 24 partes para facilitar a representação da fração. O 25 no numerador considera uma alocação de espaço adicional, que é aproximadamente 1/24 do tamanho original do índice, para dados adicionais necessários ao armazenamento de vetores binários. Tanto o índice original quanto o grafo de Hierarchical Navigable Small Worlds ainda estão armazenados em disco. O fator de sobredimensionamento é 1/24 em vez de 1/32 porque o grafo HNSW não é comprimido.

1 GB * (25/24) = 1.042 GB

Para vetores para os quais você configurou a quantização automática, recomendamos alocar espaço livre em disco igual a 125% do tamanho estimado do índice.

Tipo de implementação

Para testar as queries do Atlas Vector Search, você pode implantar um cluster compartilhado ou dedicado ou implantações locais do Atlas.

Arquitetura de nó

Neste modelo de implantação, o processo de pesquisa mongot é executado ao lado do mongod em cada nó no cluster do Atlas. O processo mongod roteia queries para o mongot no mesmo nó e eles compartilham os mesmos recursos.

Por padrão, o Atlas ativa o processo de pesquisa mongot no mesmo nó que executa o processo mongod quando você cria seu primeiro índice do Atlas Vector Search. O processo mongot executa as ações descritas em Sobre o processo mongot .

Dimensionando seu Cluster para Prototipagem do seu Aplicativo

Quando o Atlas executa suas cargas de trabalho de banco de dados e pesquisa no mesmo nó, o armazenamento do MongoDB consome uma certa porcentagem da memória disponível (RAM) do nó, deixando o restante para o índice de Atlas Vector Search e o processo mongot.

Para as camadas de cluster M10, M20 e M30, 25% é reservado para o MongoDB e os 75% restantes são para outras operações, incluindo o índice Atlas Vector Search. Para camadas de cluster M40+, 50% é reservado para o MongoDB e o restante é destinado a outras operações, incluindo o índice do Atlas Vector Search.

Limitações

Você pode experimentar a contenção de recursos entre o mongod do banco de dados e os processos de mongot pesquisa. Isso pode afetar negativamente o desempenho de seu índice e a latência de suas queries. Recomendamos este modelo de implantação apenas para ambientes de teste e prototipagem. Para aplicativos prontos para produção e cargas de trabalho de pesquisa associadas, recomendamos a migração para nós de pesquisa dedicados.

Tipo de implementação

Para aplicativos prontos para produção, é necessário um cluster dedicado com nós de pesquisa separados para isolamento de carga de trabalho.

Cluster Tiers

Os clusters dedicados incluem M10 e níveis superiores. As camadas M10 e M20 são adequadas para ambientes de desenvolvimento e produção. No entanto, os níveis mais altos podem lidar com grandes conjuntos de dados e cargas de trabalho de produção. Recomendamos que você também implante nós de pesquisa dedicados para sua carga de trabalho de pesquisa. Isso permite que você dimensione sua implementação de pesquisa de forma independente e adequada.

Provedor de nuvem e região

Os nós de pesquisa estão disponíveis em todas as regiões da Google Cloud Platform, mas estão disponíveis apenas em um subconjunto de regiões da Amazon Web Services e do Azure . Você deve selecionar um provedor de nuvem e uma região onde os nós de pesquisa estejam disponíveis para sua implementação.

Todas as camadas de cluster estão disponíveis em regiões de provedores de nuvem com suporte. O provedor de nuvem e a região que você escolher afetam as opções de configuração e as camadas de pesquisa disponíveis para o cluster e o custo de execução do cluster.

Arquitetura de nó

Nesse modelo de implantação, o processo mongot é executado em nós de pesquisa, que são separados dos nós do cluster nos quais o processo mongod é executado. O Atlas implanta nós de pesquisa com cada cluster ou com cada fragmento no cluster.

Por exemplo, se você implantar dois nós de pesquisa para um cluster com três fragmentos, o Atlas implantará seis nós de pesquisa, dois para cada fragmento. Você também pode configurar o número de nós de pesquisa e a quantidade de recursos provisionados para cada nó de pesquisa.

Ao implantar nós de pesquisa separados, o Atlas atribui automaticamente um mongod para cada mongot para indexação. O mongot comunica com o mongod para ouvir e sincronizar as alterações de índice para os índices que armazena. O Atlas Vector Search indexa e processa suas consultas de forma semelhante a quando os processos mongod e mongot são executados no mesmo nó. Para saber mais, consulte Como indexar campos do Vector Search e Executar consultas do Vector Search. Para saber mais sobre a implantação de nós de pesquisa separadamente, consulte Nós de pesquisa para isolamento de carga de trabalho.

Quando você migra para os Nós de Pesquisa, o Atlas implanta os Nós de Pesquisa, mas não atende a queries nos nós até que ele crie com êxito todos os índices no cluster nos Nós de Pesquisa. Enquanto o Atlas cria os índices nos novos nós, ele continua a atender queries usando os índices nos nós do cluster. O Atlas começa a atender queries dos nós de pesquisa somente depois de criar com êxito os índices nos nós de pesquisa e remover os índices nos nós do cluster.

Se você excluir todos os nós de pesquisa em seu cluster, haverá uma interrupção no processamento dos resultados da query de pesquisa. Para saber mais, consulte Modificar um cluster. Se você excluir seu cluster do Atlas, o Atlas pausará e então excluirá todas as implantações do Atlas Vector Search associados (mongot processos).

Benefícios

Esse modelo de implantação oferece os seguintes benefícios:

• Utilize seus recursos com eficiência e, ao mesmo tempo, garantindo alta disponibilidade de seus recursos para volumes de trabalho de Atlas Search .

• Dimensione e expanda seu sistema do Atlas Search independentemente do sistema do banco de dados.

• Processar automaticamente as queries do Atlas Vector Search simultaneamente, melhorando o tempo de resposta, especialmente em grandes conjuntos de dados. Para saber mais, consulte Paralelizar a execução de queries entre segmentos.

Dimensione seus nós de pesquisa para

O Atlas Vector Search mantém todo o índice na memória, então você precisa garantir que haja memória suficiente para o índice do Atlas Vector Search e a JVM. Os nós de pesquisa permitem o isolamento da carga de trabalho sem isolamento de dados, e quase 90% da alocação de RAM pode ser usada para armazenar dados vetoriais e índices na memória, com o restante sendo utilizado para a JVM.

Cada índice é uma combinação dos vetores que estão sendo indexados e metadados adicionais. O tamanho do índice é determinado principalmente pelo tamanho dos vetores que você está indexando, com o espaço de metadados normalmente sendo relativamente nominal. Para aprender mais, consulte Requisitos de memória para indexação de vetores.

Ao implantar nós de pesquisa dedicados, você pode escolher entre diferentes níveis de pesquisa. Cada nível de pesquisa tem uma capacidade de RAM, uma capacidade de armazenamento e uma CPU padrão. Isso permite que você meça e dimensione seu cluster independentemente da implantação de banco de dados. Para dimensionar sua implantação de pesquisa separadamente, você pode fazer as seguintes alterações na configuração do cluster a qualquer momento:

• Ajuste o número de nós de pesquisa no seu cluster.

• Ajuste a CPU, a RAM e o armazenamento do nó alterando os níveis do Atlas Search .

Recomendamos que seu nó tenha RAM pelo menos 10% maior do que o tamanho total dos índices do Atlas Vector Search. Também recomendamos que você tenha suficientes CPUs disponíveis. A latência da consulta depende do número de CPUs disponíveis, o que pode impactar significativamente o nível da simultaneidade interna que acelera o desempenho da consulta.

Migrar para nós dedicados do Atlas Search

Os nós de pesquisa dedicados permitem que você meça e dimensione sua implantação de pesquisa separadamente do cluster. Eles também eliminam qualquer contenção de recursos que possa ocorrer em um cluster que executa o banco de dados e os processos de pesquisa no mesmo nó.

Para migrar para nós de pesquisa dedicados, faça as seguintes alterações na sua implantação:

1. Se a sua implantação estiver usando atualmente uma camada compartilhada, faça upgrade o cluster para uma camada superior. Nós de pesquisa dedicados são suportados apenas para M10 e camadas de cluster superiores. Para saber mais sobre como migrar para uma camada do cluster diferente , consulte Modifique o Cluster Tier.

2. Os nós de pesquisa dedicados estão disponíveis em um subconjunto das regiões da Amazon Web Services e do Azure, e em todas as regiões do Google Cloud Platform compatíveis. Certifique-se de implementar seu cluster em regiões onde os nós de pesquisa também estão disponíveis. Se o cluster existente estiver em regiões onde os nós de pesquisa não estão disponíveis, migre-o para regiões onde os nós de pesquisa estão disponíveis. Para saber mais, consulte Regiões do fornecedor de nuvem.

3. Habilite Search Nodes for workload isolation e configure nós de pesquisa. Para saber mais, consulte Adicionar nós de pesquisa.