Revisa las opciones de implementación

Requisitos de memoria para la indexación de vectores

MongoDB Vector Search mantiene todo el índice en la memoria, por lo que debes asegurarte de que haya suficiente memoria para el índice de MongoDB Vector Search y JVM si tu conjunto de datos incluye vectores de precisión total. Cada índice es una combinación de los vectores que se están indexando y metadatos adicionales. El tamaño del índice está determinado principalmente por el tamaño de los vectores que estás indexando, siendo el espacio de los metadatos normalmente relativamente nominal.

Cuando no se utiliza cuantización, MongoDB Vector Search almacena los vectores de fidelidad completa en memoria. Si activas la cuantificación automática, MongoDB Vector Search almacena los vectores cuantizados, que requieren muchos menos recursos, en la memoria y los vectores de fidelidad total en el disco. Puede ver la diferencia entre los requisitos de disco y memoria para los índices vectoriales consultando el Size y Required Memory columnas en la página de búsqueda de MongoDB de la Interfaz de Usuario de Atlas.

Considera los siguientes requisitos para un único vector:

Vectores cuantificados de BinData. Para obtener más información, consulte Ingerir vectores cuantificados.

El espacio requerido aumenta linealmente con la cantidad de vectores que se indexan y con la dimensionalidad de los vectores. También puede usar la Search Index Size métrica para determinar la cantidad de espacio y memoria que necesita en sus nodos de búsqueda.

Requisitos de almacenamiento para vectores

Si utilizas BinData o vectores cuantizados, reduces significativamente los requisitos de recursos en comparación con no utilizar binData o vectores cuantizados. Vas a notar:

• El almacenamiento en disco de los vectores en mongod se reduce un 66% cuando se utilizan binData vectores.

• El uso de RAM de los vectores en mongot se reduce en 3.75x (escalar) o 24x (binario) debido a la compresión de vectores al utilizar quantización automática de vectores o ingestión de vectores cuantizados.

Cuando utilizas la cuantización automática, Atlas almacena los vectores de precisión total para el re-puntuación o la búsqueda exacta en disco, con un uso mínimo de RAM y caché para re-puntuación.

Si habilitas la cuantización automática en tu definición de índice de Vector Search de MongoDB, también debes considerar el espacio en disco al dimensionar tu clúster. Esto se debe a que MongoDB Vector Search también almacena vectores de precisión completa en el disco para la búsqueda ENN y para la reevaluación si has configurado la cuantización automática. Por lo tanto, asegúrate de que haya una relación adecuada disco/RAM en el hardware que utilices. Considera configurar nodos de búsqueda que puedan acomodar aproximadamente una proporción de almacenamiento a RAM de 4:1 para la cuantización escalar o una proporción de almacenamiento a RAM de 24:1 para la cuantización binaria.

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

Utiliza la siguiente fórmula para calcular aproximadamente el espacio en disco para tu índice habilitado para cuantificación binaria con reponderación:

Original index size * (25/24)

Aquí, el 24 en el denominador representa el tamaño original del índice dividido en 24 partes para una representación fraccionaria más sencilla. El 25 en el numerador representa una asignación de espacio adicional, que equivale aproximadamente a 1/24 del tamaño original del índice, para almacenar datos adicionales necesarios para guardar vectores binarios. Tanto el índice original como el Hierarchical Navigable Small Worlds los grafos aún se almacenan en el disco. El factor de sobredimensionamiento es 1/24 en lugar de 1/32 porque el grafo HNSW no está comprimido.

1 GB * (25/24) = 1.042 GB

Para los vectores para los cuales configuraste la cuantización automática, se recomienda reservar un espacio libre en disco igual al 125% del tamaño estimado del índice.

Tipo de implementación

Para probar las queries de MongoDB Vector Search, puedes implementar un clúster Flex, un clúster dedicado o usar una implementación local de Atlas.

Arquitectura de nodo

Para entornos de prueba y creación de prototipos, recomendamos una arquitectura de nodo en la que los procesos de MongoDB y los procesos de MongoDB Search se ejecuten en el mismo nodo. En el siguiente diagrama de este modelo de implementación, el proceso de MongoDB Search mongot se ejecuta junto con mongod en cada nodo del clúster de Atlas y comparten los mismos recursos.

Por defecto, Atlas habilita el proceso mongot de MongoDB Search en el mismo nodo que ejecuta el proceso mongod cuando creas tu primer índice de MongoDB Vector Search.

Cuando ejecutas una consulta, MongoDB Search utiliza la preferencia de lectura configurada para identificar el nodo en el que ejecutarla. La consulta primero se dirige al proceso de MongoDB, que es mongod para un mongos clúster de réplicas o para un clúster fragmentado.

Para un clúster de conjunto de réplicas, el mongod proceso enruta la consulta al mongot en el mismo nodo. Para clústeres fragmentados, los datos del clúster se particionan entre mongod instancias (fragmentos) y cada mongot proceso solo puede acceder a los datos en la mongod instancia en el mismo nodo. Por lo tanto, no puede ejecutar consultas de MongoDB Search que se dirijan a un fragmento en particular. enruta lamongos consulta a todos los fragmentos, lo que hace que estas consultas sean de dispersión y recolección. Si utiliza zonas para distribuir una colección fragmentada en un subconjunto de los fragmentos del clúster, MongoDB Search enruta la consulta a la zona que contiene los fragmentos de la colección que está consultando y ejecuta sus $search consultas solo en los fragmentos donde se encuentra la colección.

Una vez que la consulta se dirige a un mongot proceso de MongoDB Search, el mongot proceso realiza la búsqueda y la puntuación, y devuelve los ID de los documentos y otros metadatos de búsqueda de los resultados coincidentes a su mongod proceso correspondiente. A continuación, el mongod proceso realiza una búsqueda completa de documentos de forma implícita para los resultados coincidentes y los devuelve al cliente. Si utiliza la $search opción concurrente en su consulta, MongoDB Search habilita el paralelismo dentro de la consulta. Para obtener más información, consulte Paralelizar la ejecución de consultas entre segmentos.

Para obtener más información sobre el mongot proceso,consulte Procesamiento de consultas.

Dimensiona tu clúster para prototipar tu aplicación

Cuando Atlas ejecuta tus cargas de trabajo de base de datos y búsqueda en el mismo nodo, el almacenamiento de MongoDB ocupa un cierto porcentaje de la memoria disponible del nodo (RAM), dejando el resto para el índice de MongoDB Vector Search y el proceso mongot.

Para los niveles de clúster M10, M20 y M30, se reserva el 25% para MongoDB y el 75% restante es para otras operaciones, incluido tu índice MongoDB Vector Search. Para los niveles de clúster M40+, se reserva el 50% para MongoDB y el resto para otras operaciones, incluido tu índice de MongoDB Vector Search.

Limitaciones

Es posible que experimente disputas de recursos entre la base de datos mongod y los procesos de búsqueda mongot. Esto podría afectar negativamente el rendimiento de tu índice y la latencia de tus consultas. Recomendamos este modelo de implementación solo para entornos de prueba y creación de prototipos. Para aplicaciones listas para producción y cargas de trabajo de búsqueda asociadas, recomendamos migrar a nodos de búsqueda dedicados.

Tipo de implementación

Para aplicaciones listas para producción, se necesita un clúster dedicado con nodos de búsqueda separados para el aislamiento de la carga de trabajo.

Cluster Tiers

Los clústeres dedicados incluyen M10 los niveles y superiores. Los M10 M20 niveles y son adecuados para entornos de desarrollo y producción. Sin embargo, los niveles superiores pueden gestionar grandes conjuntos de datos y cargas de trabajo de producción. Recomendamos implementar nodos de búsqueda dedicados para su carga de trabajo de búsqueda. Esto le permitirá escalar su implementación de búsqueda de forma independiente y adecuada.

Proveedor de nube y región

Los nodos de búsqueda están disponibles en todas las regiones de Google Cloud, pero solo en un subconjunto de regiones de AWS y Azure. Debe seleccionar un proveedor de nube y una región donde los nodos de búsqueda estén disponibles para su implementación.

Todos los niveles de clúster están disponibles en las regiones admitidas del proveedor de nube. El proveedor de nube y la región que elijas afectan las opciones de configuración y los niveles de búsqueda disponibles para el clúster, así como el costo de ejecutarlo.

Arquitectura de nodo

Para entornos de producción, recomendamos una arquitectura de nodos en la que los procesos de MongoDB y los procesos de MongoDB Search se ejecuten en nodos separados. Para implementar nodos de búsqueda separados, consulta Migrar a nodos de búsqueda dedicados.

En el siguiente diagrama de este modelo de despliegue, el proceso MongoDB Search mongot se ejecuta en nodos de búsqueda dedicados, que están separados de los nodos del clúster en los que se ejecuta el proceso mongod.

Atlas implementa nodos de búsqueda con cada clúster o con cada partición en el clúster. Por ejemplo, si implementas dos nodos de búsqueda para un clúster con tres particiones, Atlas implementa seis nodos de búsqueda (dos por partición). También puedes configurar el número de nodos de búsqueda y la cantidad de recursos aprovisionados para cada nodo de búsqueda.

Cuando implementa nodos de búsqueda independientes, Atlas asigna automáticamente un mongod a cada mongot para la indexación. El se mongot comunica con el para mongod escuchar y sincronizar los cambios de índice de los índices que almacena. MongoDB Vector Search indexa y procesa sus consultas de forma similar a una implementación donde los mongod mongot procesos y se ejecutan en el mismo nodo. Para obtener más información, consulte Cómo indexar campos para Vector Search y Ejecutar consultas de Vector Search. Para obtener más información sobre la implementación de nodos de búsqueda independientes, consulte Nodos de búsqueda para el aislamiento de cargas de trabajo.

Cuando se migra a Search Nodes, Atlas implementa los Search Nodes, pero no sirve queries en los nodos hasta que se compila exitosamente todos los índices en el clúster en los Search Nodes. Mientras Atlas construye los índices en los nuevos nodos, continúa sirviendo queries usando los índices en los nodos del clúster. Atlas comienza a atender queries desde los nodos de búsqueda sólo después de compilar correctamente los índices en los nodos de búsqueda y remover los índices en los nodos del clúster.

Cuando ejecutas una consulta, esta se enruta al mongod proceso según la preferencia de lectura configurada. El mongod proceso enruta la consulta de búsqueda a través de un balanceador de carga en el mismo nodo, que distribuye las solicitudes entre todos los mongot procesos.

El proceso de MongoDB Search mongot realiza la búsqueda y la puntuación, y devuelve los ID de los documentos y los metadatos de los resultados coincidentes a.mongod A mongod continuación, realiza una búsqueda completa de los documentos coincidentes y devuelve los resultados al cliente. Si utiliza la $search opción concurrente en su consulta, MongoDB Search habilita el paralelismo dentro de la consulta. Para obtener más información, consulte Paralelizar la ejecución de consultas en segmentos.

Si elimina todos los nodos de búsqueda de su clúster, se interrumpirá el procesamiento de los resultados de su consulta de búsqueda. Para obtener más información, consulte Modificar un clúster. Si elimina su clúster de Atlas, Atlas se detendrá y luego eliminará todas las implementacionesmongot de MongoDB Vector Search asociadas ( procesos).

Beneficios

Este modelo de implementación aporta las siguientes ventajas:

• Utiliza eficazmente tus recursos asegurando al mismo tiempo la alta disponibilidad de tus recursos para cargas de trabajo de búsqueda.

• Ajuste el tamaño y **escalar** su **implementación** de búsqueda de forma independiente de su **implementación de la base de datos**.

• Procese automáticamente las consultas de MongoDB Vector Search de manera concurrente, mejorando el tiempo de respuesta, especialmente en grandes conjuntos de datos. Para obtener más información, consulte Ejecución de query en paralelo entre segmentos.

Ajusta el tamaño de tus nodos de búsqueda para producción

MongoDB Vector Search mantiene todo el índice en memoria, por lo que necesitas asegurarte de que haya suficiente memoria para el índice de MongoDB Vector Search y para la JVM. Los nodos de búsqueda permiten el aislamiento de cargas de trabajo sin el aislamiento de datos, y casi el 90% de su asignación de RAM se puede usar para almacenar los datos de vectores e índices en la memoria, y lo que queda se puede usar para la JVM.

Cada índice es una combinación de los vectores a los que se les asigna un índice y metadatos adicionales. El tamaño del índice se determina principalmente por el tamaño de los vectores para los que estás realizando la indexación, siendo el espacio de metadatos típicamente relativamente nominal. Para obtener más información, consulte Requisitos de memoria para la indexación de vectores.

Al implementar nodos de búsqueda dedicados, puede elegir entre diferentes niveles de búsqueda. Cada nivel de búsqueda tiene una capacidad de RAM, almacenamiento y CPU predeterminadas. Esto le permite dimensionar y escalar su clúster independientemente de la implementación de su base de datos. Para escalar su implementación de búsqueda por separado, puede realizar los siguientes cambios en la configuración de su clúster en cualquier momento:

• Ajusta el número de nodos de búsqueda en tu clúster.

• Ajusta la CPU, la RAM y el almacenamiento del nodo cambiando los niveles de búsqueda.

Recomendamos que tu nodo tenga una memoria RAM al menos 10% mayor que el tamaño total de tus índices de MongoDB Vector Search. También recomendamos que se asegure de tener suficientes CPUs disponibles. La latencia de la query depende del número de CPU disponibles, lo que puede afectar significativamente el nivel de concurrencia interna que acelera el rendimiento de la query.

Activar el cifrado en reposo

Por defecto, MongoDB y los procesos de búsqueda se ejecutan en los mismos nodos. Con esta arquitectura, el cifrado gestionado por el cliente se aplica a los datos de la base de datos, pero no a los índices de búsqueda.

Al habilitar los nodos de búsqueda dedicados, los procesos de búsqueda se ejecutan en nodos separados. Esto permite habilitar el cifrado de datos del nodo de búsqueda, de modo que se pueden cifrar tanto los datos de la base de datos como los índices de búsqueda con las mismas claves administradas por el cliente para una cobertura de cifrado completa.

Para obtener más información, consulta Permitir la gestión de claves de cliente para los nodos de búsqueda.

Migre a nodos de búsqueda dedicados

Los nodos de búsqueda dedicados permiten dimensionar y escalar su implementación de búsqueda por separado de su clúster. También elimina cualquier conflicto de recursos que pueda experimentar en un clúster que ejecute tanto la base de datos como los procesos de búsqueda en el mismo nodo.

Para migrar a Nodos de Búsqueda dedicados, realiza los siguientes cambios en tu implementación:

1. Si su implementación utiliza actualmente un clúster de nivel gratuito o un clúster Flex, actualícelo a un nivel superior. Los nodos de búsqueda dedicados solo son compatibles con los M10 niveles de clúster y superiores. Para obtener más información sobre cómo migrar a un nivel de clúster diferente, consulte Modificar el nivel del clúster.

2. Los nodos de búsqueda dedicados están disponibles en un subconjunto de regiones de AWS y Azure, así como en todas las regiones de Google Cloud compatibles. Asegúrese de implementar su clúster en regiones donde también estén disponibles los nodos de búsqueda. Si su clúster actual se encuentra en regiones donde no están disponibles, migre su clúster a regiones donde sí lo estén. Para obtener más información, consulte Regiones de proveedores de nube.

3. Search Nodes for workload isolation Habilite y configure los nodos de búsqueda. Para obtener más información,consulte Agregar nodos de búsqueda.