Revisar as opções de implantação

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

O Atlas Vector Search mantém o índice inteiro na memória, então você precisa garantir que haja memória suficiente para o índice do Atlas Vector Search e a JVM se o seu conjunto de dados incluir vetores de precisão total. 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.

Quando não se utiliza quantização, o Atlas Vector Search armazena os vetores de fidelidade total na memória. Se você ativar a quantização automática, o Atlas Vector Search armazenará os vetores quantizados, que exigem significativamente menos recursos, na memória e os vetores de alta fidelidade no disco. Você pode visualizar a diferença entre os requisitos de disco e memória para índices vetoriais visualizando as colunas Size e Required Memory na página Atlas Search da IU do Atlas.

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 queries do Atlas Vector Search, você pode implantar um cluster Flex, um cluster dedicado ou usar uma implantação local do Atlas.

Arquitetura de nó

Para ambientes de teste e prototipagem, recomendamos uma arquitetura de nó em que os processos do MongoDB e do Atlas Search executam no mesmo nó. No diagrama a seguir deste modelo de implantação, o processo Atlas Search mongot é executado junto com o mongod em cada nó no cluster Atlas e eles compartilham os mesmos recursos.

Por padrão, o Atlas ativa o processo do Atlas Search mongot no mesmo nó que executa o processo mongod quando você cria seu primeiro índice do Atlas Vector Search.

Quando você executa uma query, o Atlas Search utiliza a preferência de leitura configurada para identificar o nó no qual executar a query. A query primeiro vai para o processo do MongoDB, que é mongod para um cluster de conjunto de réplicas ou mongos para um cluster fragmentado.

Para um cluster de conjunto de réplicas, o processo mongod direciona a query para o mongot no mesmo nó. Para clusters fragmentados, os dados do seu cluster são particionados em mongod instâncias (fragmentos) e cada processo mongot só pode acessar os dados na instância mongod no mesmo nó. Portanto, você não pode executar queries do Atlas Search que tenham como alvo um fragmento específico. mongos roteia a query para todos os fragmentos, fazendo estas dispersar e reunir queries. Se você usar zonas para distribuir uma coleção fragmentada em um subconjunto dos fragmentos no cluster, o Atlas Search roteará a query para a zona que contém os fragmentos da coleção que você está fazendo query e executará suas queries $search somente nos fragmentos em que a coleção está localizada.

Após a query ser roteada para um processo mongot do Atlas Search, o processo mongot realiza a pesquisa e a pontuação e retorna os IDs dos documentos e outros metadados da pesquisa para os resultados correspondentes ao processo mongod. O processo mongod realiza uma busca completa de documentos de forma implícita para os resultados correspondentes e devolve os resultados ao cliente. Se você usar a opção $search concorrente em sua query, o Atlas Search ativará o paralelismo intraquery. Para saber mais, consulte Paralelizar a execução de query entre segmentos.

Para saber mais sobre o processo mongot, consulte Processamento de query.

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ó

Para ambientes de produção, recomendamos uma arquitetura de nós em que os processos do MongoDB e do Atlas Search sejam executados em nós separados. Para implantar nós de pesquisa separados, consulte Migrar para nós de pesquisa dedicados.

No diagrama a seguir deste modelo de implantação, o processo Atlas Search mongot é executado em nós de pesquisa dedicados, 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 shards, o Atlas implantará seis nós de pesquisa (dois por shard). 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 maneira semelhante a uma implantação onde 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.

Quando você executa uma query, a query é roteada para mongod com base na preferência de leitura configurada. O processo mongod encaminha a query de pesquisa por meio de um balanceador de carga no mesmo nó, que distribui as solicitações entre todos os processos mongot.

O Atlas Search mongot executa a pesquisa e pontuação e retorna os IDs dos documentos e metadados dos resultados correspondentes para mongod. Em seguida, o mongod executa uma pesquisa completa de documentos para os resultados correspondentes e retorna os resultados para o cliente. Se você usar a opção $search concorrente em sua query, o Atlas Search ativará o paralelismo intraquery. Para saber mais, consulte Paralelizar a execução de query entre segmentos.

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.

Habilitar Encryption at rest

Você pode ativar a criptografia em descanso com o gerenciamento de chaves do cliente para todos os dados nos nós de pesquisa para proteger suas cargas de trabalho do Atlas Vector Search com chaves de criptografia gerenciadas pelo cliente. Para aprender mais, consulte Habilitar o gerenciamento de chaves do cliente para nós de pesquisa.

Atualmente, esse recurso está disponível para nós de pesquisa no AWS.

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 sua implantação estiver usando um cluster de camada grátis ou um cluster Flex, faça upgrade do seu 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 outra camada do cluster, consulte Modificar 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.