Revisa las opciones de implementación

Requisitos de memoria para indexar 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 Atlas UI.

Considera los siguientes requisitos para un único vector:

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

El espacio requerido se escala linealmente con el número de vectores que se están indexando y con la dimensionalidad del vector. También puedes usar la métrica Search Index Size para determinar la cantidad de espacio y memoria que necesitas en tus 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 se utiliza la cuantificación automática, Atlas almacena los vectores de precisión completa para la repuntuación o la búsqueda exacta en el disco, con un uso mínimo de RAM y caché para la repuntuació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"
    }
  ]
}

Utilice la siguiente fórmula para calcular aproximadamente el espacio en disco para su índice habilitado con cuantificación binaria con rescore:

Original index size * (25/24)

Aquí, el 24 en el denominador representa el tamaño del índice original dividido en 24 partes para facilitar la representación de fracciones. El 25 en el numerador representa una asignación de espacio adicional, que es aproximadamente 1/24 del tamaño del índice original, para los datos adicionales necesarios para almacenar vectores binarios. Tanto el índice original como los Mundos Pequeños Navegables Jerárquicos Los gráficos aún se almacenan en el disco. El factor de sobredimensionamiento es 1/24 en lugar de 1/32 porque el gráfico 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 nodos

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 se ejecuta una query, MongoDB Search utiliza la preferencia de lectura configurada para identificar el nodo en el cual ejecutar el query. El query primero va al proceso de MongoDB, que es mongod para un set de réplicas o mongos para un clúster.

Para un clúster de set de réplicas, el proceso mongod enruta la query al mongot en el mismo nodo. Para los clústeres fragmentados, los datos de tu clúster están particionados en mongod instancias (particiones), y cada proceso de mongot sólo puede acceder a los datos en la instancia mongod en el mismo nodo. Por lo tanto, no se pueden ejecutar queries de MongoDB Search que apunten a una partición en particular. mongos enruta la consulta a todas las particiones de base de datos, convirtiéndolas en consultas scatter gather. Si usas zonas para distribuir una colección particionada en un subconjunto de las particiones en el clúster, MongoDB Search enrute la query a la zona que contiene las particiones para la colección que estás consultando y ejecuta tus $search queries sólo en las particiones donde se encuentra la colección.

Tras enrutar la consulta 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 los resultados coincidentes a su mongod proceso correspondiente. A continuación, el mongod proceso realiza una búsqueda completa del documento implícitamente para los resultados coincidentes y los devuelve al cliente. Si utiliza la $search opción concurrente en su consulta, MongoDB Search habilita el paralelismo entre consultas. 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, necesitás un clúster dedicado con Nodos de búsqueda para aislamiento de cargas de trabajo.separados

Cluster Tiers

Los clústeres dedicados incluyen M10 y niveles superiores. Los niveles M10 y M20 son adecuados para entornos de desarrollo y producción. Sin embargo, los niveles más altos pueden gestionar grandes conjuntos de datos y cargas de trabajo de producción. Recomendamos que también implementes nodos de búsqueda dedicados para tu carga de trabajo de búsqueda. Esto te permite escalar tu implementación de búsqueda de manera 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 sólo están disponibles en un subconjunto de AWS y Azure regiones. Debes seleccionar un proveedor de nube y una región donde los nodos de búsqueda estén disponibles para tu 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 nodos

Para entornos de producción, recomendamos una arquitectura de nodos en la que los procesos de MongoDB y los procesos de MongoDB Search se ejecutan en nodos separados. Para implementar nodos de búsqueda separados, consulte 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 se implementan nodos de búsqueda por separado, Atlas asigna automáticamente un mongod para cada mongot para la indexación. El mongot se comunica con el mongod para escuchar y sincronizar los cambios de índice de los índices que almacena. MongoDB Vector Search indexa y procesa tus consultas de forma similar a una implementación en la que tanto los procesos mongod como mongot se ejecutan en el mismo nodo. Para obtener más información, consulta Cómo indexar campos para búsqueda vectorial y Ejecutar consultas de búsqueda vectorial. Para obtener más información sobre cómo implementar los nodos de búsqueda por separado, consulta 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 ejecutes una query, esta se enruta al mongod según la preferencia de lectura configurada. El proceso mongod enruta la consulta de búsqueda a través de un balanceador de carga en el mismo nodo, lo que distribuye las solicitudes entre todos los procesos mongot.

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 de las coincidencias a mongod. A continuación, mongod realiza una búsqueda en el documento completo para obtener resultados coincidentes y devuelve los resultados al cliente. Si se utiliza la opción $search concurrente en el query, MongoDB Search permite el paralelismo intra-query. Para aprender más, se puede consultar Paralelización de la ejecución de queries entre segmentos.

Si borras todos los nodos de búsqueda en tu clúster, se interrumpirá el procesamiento de los resultados de tus consultas de búsqueda. Para aprender más, consulta Modificar un clúster. Si eliminas tu clúster de Atlas, Atlas pausa y luego elimina todas las implementaciones de MongoDB Vector Search asociadas (mongot 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.

• Dimensione y escale su implementación de búsqueda independientemente de su implementación de 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.

Dimensione sus 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 indexados y metadatos adicionales. El tamaño del índice se determina principalmente por el tamaño de los vectores que se indexan, siendo el espacio de metadatos generalmente nominal. Para obtener más información, consulte Requisitos de memoria para la indexación de vectores.

Cuando implementes nodos de búsqueda dedicados, puedes elegir entre diferentes niveles de búsqueda. Cada nivel de búsqueda tiene una RAM, capacidad de almacenamiento y CPU por defecto. Esto permite dimensionar y escalar el clúster independientemente de la implementación de la base de datos. Para escalar tu implementación de búsqueda por separado, puedes hacer los siguientes cambios en la configuración del clúster en cualquier momento:

• Ajuste la cantidad de nodos de búsqueda en su 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 su base de datos, pero no se aplica a los índices de búsqueda.

Cuando activas nodos de búsqueda dedicados, los procesos de búsqueda se ejecutan en nodos separados. Esto permite activar el cifrado de datos del nodo de búsqueda, para que puedas 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 integral.

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 tu implementación actualmente está utilizando un clúster de nivel gratuito o un clúster flexible, actualiza tu clúster a un nivel superior. Los Nodos de Búsqueda Dedicados solo son compatibles con M10 y niveles de clúster superiores. Para obtener más información sobre cómo migrar a un nivel de clúster diferente, consulta Modificar el Cluster Tier.

2. Los nodos de búsqueda dedicados están disponibles en un subconjunto de AWS y Azure regiones y en todas las regiones compatibles de Google Cloud. Asegúrese de implementar su clúster en regiones en las que los nodos de búsqueda también estén disponibles. Si tu clúster existente está en regiones donde los nodos de búsqueda no están disponibles, migra tu clúster a regiones donde los nodos de búsqueda estén disponibles. Para obtener más información, consulte Regiones del proveedor 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.