Revisar as opções de implantação

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

O MongoDB Vector Search mantém o índice inteiro na memória, portanto, você precisa garantir que haja memória suficiente para o índice do MongoDB Vector Search e o 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 temporal.

Quando não estiver usando a quantização, o MongoDB Vector Search armazena todos os vetores de fidelidade na memória. Se você ativar a quantização automática, o MongoDB Vector Search armazenará os vetores quantizados, que exigem significativamente menos recursos, na memória e os vetores de fidelidade total no disco. Você pode visualizar a diferença entre os requisitos de disco e memória para índices de vetor visualizando as colunas Size e Required Memory na página de pesquisa do MongoDB da interface do usuário 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ê habilitar a quantização automática em sua definição de índice do MongoDB Vector Search, também deverá considerar o espaço em disco ao dimensionar o cluster. Isso ocorre porque o MongoDB Vector Search armazena vetores de precisão total também no disco para pesquisa ENN e para reclassificação se você tiver configurado a quantização automática. Portanto, certifique-se de que haja uma proporção apropriada de disco para RAM no hardware que você usa. Considere a possibilidade de 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 24:1 de armazenamento para RAM para quantização binária.

{
  "fields":[
    {
      "type": "vector",
      "path": "my-embeddings",
      "numDimensions": 1024,
      "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 do índice original divisão em 24 partes para facilitar a representação da fração. O 25 no numerador contabiliza uma alocação de espaço adicional, que é de aproximadamente 1/24 do tamanho original do índice, para dados adicionais necessários para armazenar vetores binários. Tanto o índice original quanto o gráfico Hierarchical Navigable Small Worlds ainda estão armazenados no disco. O fator de tamanho grande é 1/24 em vez de 1/32 porque o gráfico HNSW não é compactado.

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 MongoDB Vector Search , você pode implantar um cluster Flex, um cluster dedicado ou usar um sistema local do Atlas .

Arquitetura de nó

Para ambientes de teste e criação de protótipos, recomendamos uma arquitetura de nó na qual os processos do MongoDB e o MongoDB Search sejam executados no mesmo nó. No diagrama a seguir deste modelo de implantação, o processo mongot do MongoDB Search é executado ao lado de mongod em cada nó no Atlas cluster e eles compartilham os mesmos recursos.

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

Quando você executa uma query, o MongoDB Search usa 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 roteia a query para mongot no mesmo nó. Para clusters fragmentados, os dados do cluster são particionados em instâncias mongod (shards) e cada processo mongot só pode acessar os dados na instância mongod no mesmo nó. Portanto, você não pode executar queries no MongoDB Search que tenham como alvo um shard específico. mongos roteia a query para todos os shards, fazendo estas dispersar e reunir queries. Se você usar zonas para distribuir uma collection fragmentada em um subconjunto dos shards no cluster, o MongoDB Search roteará a query para a zona que contém os shards da collection que você está consultando e executará suas $search queries apenas nos shards onde a coleção está localizada.

Depois que a query é roteada para um processo mongot do MongoDB Search, o processo mongot executa a pesquisa e a pontuação e retorna os IDs dos documento e outros metadados da pesquisa dos resultados correspondentes para o processo mongod correspondente. O processo mongod então realiza uma pesquisa completa do documento implicitamente para os resultados correspondentes e retorna os resultados ao cliente. Se você usar a opção $search concurrent em sua query, o MongoDB Search ativará o paralelismo intraquery. Para saber mais, consulte Parallelize Query Execution Across Segments.

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

Dimensionando seu Cluster para Prototipagem do seu Aplicativo

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

Para as camadas do cluster M10, M20 e M30, 25% é reservado para o MongoDB , e o 75% restante é para outras operações, incluindo seu índice do MongoDB Vector Search . Para camadas de cluster M40+, 50% é reservado para o MongoDB e o restante é para outras operações, incluindo seu índice do MongoDB 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ó na qual os processos do MongoDB e os processos do MongoDB Search são 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 sistema, o processo mongot do MongoDB Search é 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 MongoDB Vector Search indexa e processa suas queries de forma semelhante a um sistema em que os processos mongod e mongot são executados no mesmo nó. Para saber mais, consulte Como indexar campos para o Vector Search e Executar queries do Vector Search. Para saber mais sobre como implantar nós de pesquisa separadamente, consulte Nós de pesquisa para isolamento de volume 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 processo mongot do MongoDB Search executa a pesquisa e a pontuação e retorna os IDs dos documento e os metadados dos resultados correspondentes para mongod. O mongod então realiza uma pesquisa completa do documento para os resultados correspondentes e retorna os resultados ao cliente. Se você usar a opção $search concurrent em sua query, o MongoDB Search ativará o paralelismo intraquery. Para saber mais, consulte Parallelize Query Execution Across Segments.

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 agrupamento do Atlas , o Atlas pausará e então excluirá todos os sistemas de Vector Search MongoDB 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.

• Processe automaticamente queries do MongoDB Vector Search simultaneamente, melhorando o tempo de resposta, especialmente em grandes conjuntos de dados. Para saber mais, consulte Execução paralela de consultas entre segmentos.

Dimensione seus nós de pesquisa para

A Vector Search do MongoDB mantém todo o índice na memória, então você precisa garantir que haja memória suficiente para o índice da Vector Search do MongoDB e JVM. Os nós de pesquisa permitem o isolamento do volume de trabalho sem o isolamento de dados, e quase 90% de sua alocação de RAM pode ser usada para armazenar os dados e índices vetoriais na memória, com o restante sendo usado 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 que o tamanho total de seus índices do MongoDB Vector Search . Também recomendamos que você verifique se tem CPUs disponíveis suficientes. A latência da query depende do número de CPUs disponíveis, o que pode impacto significativamente o nível de simultaneidade interna que acelera o desempenho da query.

Habilitar Encryption at rest

Por padrão, os processos de pesquisa e MongoDB são executados nos mesmos nós. Com essa arquitetura, a criptografia gerenciada pelo cliente se aplica aos dados do seu banco de dados , mas não se aplica aos índices de pesquisa.

Quando você habilita nós de pesquisa dedicados, os processos de pesquisa são executados em nós separados. Isso permite que você ative a criptografia de dados do nó de pesquisa, para que possa criptografar os dados do banco de dados e os índices de pesquisa com as mesmas chaves gerenciadas pelo cliente para uma cobertura abrangente de criptografia.

Para aprender mais, consulte Habilitar o gerenciamento de chaves do cliente para nós de pesquisa.

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.