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 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.

The required space scales linearly with the number of vectors that you are indexing and with the vector dimensionality. You can also use the Search Index Size metric to determine the amount of space and memory you need on your Search Nodes.

Requisitos de armazenamento para vetores

If you use BinData or quantized vectors, you significantly reduce resource requirements compared to not using binData or quantized vectors. You will notice:

• 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 configuração de nós de pesquisa que possam acomodar aproximadamente uma proporção de armazenamento para RAM 4:1 para quantização escalar ou uma proporção de armazenamento para RAM 24:1 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 é 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 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 .

When you run a query, MongoDB Search uses the configured read preference to identify the node on which to run the query. The query first goes to the MongoDB process, which is mongod for a replica set cluster or mongos for a sharded cluster.

For a replica set cluster, the mongod process routes the query to the mongot on the same node. For sharded clusters, your cluster data is partitioned across mongod instances (shards) and each mongot process can only access the data on the mongod instance on the same node. Therefore, you can't run MongoDB Search queries that target a particular shard. mongos routes the query to all shards, making these scatter gather queries. If you use zones to distribute a sharded collection over a subset of the shards in the cluster, MongoDB Search routes the query to the zone that contains the shards for the collection that you are querying and runs your $search queries on just the shards where the collection is located.

After the query is routed to a MongoDB Search mongot process, the mongot process performs the search and scoring and returns the document IDs and other search metadata for the matching results to its corresponding mongod process. The mongod process then performs a full document lookup implicitly for the matching results and returns the results to the client. If you use the $search concurrent option in your query, MongoDB Search enables intra-query parallelism. To learn more, see Parallelize Query Execution Across Segments.

To learn more about the mongot process, see Query Processing.

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 mongot de pesquisa. Isso pode afetar negativamente o desempenho do índice e a latência das 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

For production-ready applications, you need a dedicated cluster with separate Search Nodes for Workload Isolation.

Cluster Tiers

Dedicated clusters include M10 and higher tiers. The M10 and M20 tiers are suitable for development and for production environments. However, the higher tiers can handle large datasets and production workloads. We recommend that you also deploy dedicated Search Nodes for your search workload. This allows you to scale your search deployment independently and appropriately.

Provedor de nuvem e região

Search Nodes are available in all the regions for Google Cloud but are only available in a subset of AWS and Azure regions. You must select a cloud provider and region where Search Nodes are available for your deployment.

Todas os tiers 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 os tiers 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.

When you deploy separate Search Nodes, Atlas automatically assigns a mongod for each mongot for indexing. The mongot communicates with the mongod to listen for and sync index changes for the indexes that it stores. MongoDB Vector Search indexes and processes your queries similar to a deployment where both the mongod and mongot processes run on the same node. To learn more, see How to Index Fields for Vector Search and Run Vector Search ANN and ENN Queries. To learn more about deploying Search Nodes separately, see Search Nodes for Workload Isolation.

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.

When you run a query, the query routes to the mongod based on the configured read preference. The mongod process routes the search query through a load balancer on the same node, which distributes the requests across all of the mongot processes.

The MongoDB Search mongot process performs the search and scoring and returns the document IDs and metadata for the matching results to mongod. The mongod then performs a full document lookup for the matching results and returns the results to the client. If you use the $search concurrent option in your query, MongoDB Search enables intra-query parallelism. To learn more, see Parallelize Query Execution Across Segments.

If you delete all the Search Nodes on your cluster, there will be an interruption in processing your search query results. To learn more, see Modify a Cluster. If you delete your Atlas cluster, Atlas pauses and then deletes all associated MongoDB Vector Search deployments (mongot processes).

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.

When you deploy dedicated Search Nodes, you can choose from different search tiers. Each search tier has a default RAM capacity, storage capacity, and CPU. This allows you to size and scale your cluster independently from your database deployment. To scale your search deployment separately, you can make the following changes to your cluster configuration at any time:

• 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

By default, MongoDB and search processes run on the same nodes. With this architecture, customer-managed encryption applies to your database data, but it does not apply to search indexes.

When you enable dedicated Search Nodes, search processes run on separate nodes. This allows you to enable Search Node Data Encryption, so you can encrypt both database data and search indexes with the same customer-managed keys for comprehensive encryption coverage.

Para saber mais, consulte Ativar 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. If your deployment is currently using a free tier cluster or a Flex cluster, upgrade your cluster to a higher tier. Dedicated Search Nodes are supported only for M10 and higher cluster tiers. To learn more about migrating to a different cluster tier, see Modify the Cluster Tier.

2. Dedicated Search Nodes are available on a subset of the AWS and Azure regions and in all supported Google Cloud regions. Make sure to deploy your cluster in regions where Search Nodes are also available. If your existing cluster is in regions where Search Nodes are not available, migrate your cluster to regions where Search Nodes are available. To learn more, see Cloud Provider Regions.

3. Enable Search Nodes for workload isolation and configure Search Nodes. To learn more, see Add Search Nodes.

Padrões de arquitetura

As with MongoDB Vector Search on Atlas, self-managed deployments use one of the same two architecture patterns: co-located or dedicated. The only exception is that on self-managed deployments, you provision and manage the hosts yourself.

Dimensionamento

Unlike Atlas, self-managed deployments have no predefined cluster or search tiers. You provision your own hardware or cloud instances. To choose a starting configuration and refine it based on your workload, see Introduction to mongot Deployment Sizing.