Revisa las opciones de implementación

Requisitos de memoria para indexar vectores

MongoDB Vector Search almacena el índice completo en memoria, por lo que debe asegurarse de que haya suficiente memoria para el índice y la JVM si su conjunto de datos incluye vectores de precisión completa. 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 indexados, y el espacio para metadatos suele ser relativamente pequeño.

Cuando no se utiliza la cuantificación, MongoDB Vector Search almacena los vectores de fidelidad completa en memoria. Si habilita la cuantificación automática, MongoDB Vector Search almacena los vectores cuantificados, que requieren muchos menos recursos, en memoria y los vectores de fidelidad completa en disco. Puede ver la diferencia entre los requisitos de disco y memoria para los índices vectoriales consultando 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 indexa y su dimensionalidad. 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 utiliza BinData o vectores cuantificados, reducirá significativamente los requisitos de recursos en comparación con no utilizar binData ni vectores cuantificados. Notará lo siguiente:

• El almacenamiento en disco de vectores en mongod se reduce en 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 vectorial cuando se utiliza la cuantificación automática de vectores o la ingestión de vectores cuantificados.

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 habilita la cuantificación automática en la definición del índice de MongoDB Vector Search, también debe considerar el espacio en disco al dimensionar el clúster. Esto se debe a que MongoDB Vector Search almacena vectores de precisión completa en disco para la búsqueda de ENN y para la repuntuación si configuró la cuantificación automática. Por lo tanto, asegúrese de que el hardware que utiliza tenga una proporción adecuada de disco a RAM. Considere configurar nodos de búsqueda que admitan una proporción aproximada 4 de:1 de almacenamiento a RAM para la cuantificación escalar o 24 de:1 para la cuantificació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 que configuró la cuantificación automática, recomendamos asignar espacio libre en disco igual al 125% del tamaño del índice estimado.

Tipo de implementación

Para probar consultas de búsqueda vectorial de MongoDB, puede implementar un clúster Flex, un clúster dedicado o utilizar una implementación de Atlas local.

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.

De forma predeterminada, Atlas habilita el proceso de búsqueda de MongoDB mongot en el mismo nodo que ejecuta el proceso mongod cuando crea su primer índice de búsqueda vectorial de MongoDB.

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.

En un clúster de conjunto de réplicas, el mongod proceso enruta la consulta al mongot en el mismo nodo. En clústeres fragmentados, los datos del clúster se particionan en mongod instancias (fragmentos) y cada mongot proceso solo puede acceder a los datos de la mongod instancia del mismo nodo. Por lo tanto, no se pueden ejecutar consultas de MongoDB Search dirigidas a un fragmento específico. enruta lamongos consulta a todos los fragmentos, lo que las convierte en consultas de dispersión y recopilación. Si se utilizan 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 se está consultando y ejecuta las $search consultas solo en los fragmentos 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.

Dimensione su clúster para crear prototipos de su aplicación

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

Para los niveles de clúster M10, M20 y M30, el 25% se reserva para MongoDB y el 75% restante se destina a otras operaciones, incluido el índice de búsqueda vectorial de MongoDB. Para los niveles de clúster M40+, el 50% se reserva para MongoDB y el resto se destina a otras operaciones, incluido el índice de búsqueda vectorial de MongoDB.

Limitaciones

Podría experimentar una contención de recursos entre la base de datos mongod y los mongot procesos de búsqueda. Esto podría afectar negativamente el rendimiento del índice y la latencia de las 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, 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 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. Le recomendamos que también implemente nodos de búsqueda dedicados para su carga de trabajo de búsqueda. Esto le permite 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 del clúster están disponibles en las regiones compatibles con los proveedores de nube. El proveedor de nube y la región que elija afectarán las opciones de configuración y los niveles de búsqueda disponibles para el clúster, así como el costo de su funcionamiento.

Arquitectura de nodos

Para entornos de producción, recomendamos una arquitectura de nodos donde los procesos de MongoDB y los de búsqueda de MongoDB se ejecuten 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 implementación, el proceso de búsqueda de MongoDB 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 fragmento del clúster. Por ejemplo, si implementa dos nodos de búsqueda para un clúster con tres fragmentos, Atlas implementa seis nodos de búsqueda (dos por fragmento). También puede configurar el número de nodos de búsqueda y la cantidad de recursos aprovisionados para cada uno.

Al implementar nodos de búsqueda independientes, Atlas asigna automáticamente un mongod por cada mongot para la indexación. El se mongot comunica con el para mongod detectar y sincronizar los cambios de índice de los índices que almacena. MongoDB Vector Search indexa y procesa las 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 la búsqueda vectorial y Ejecutar consultas de búsqueda vectorial. Para obtener más información sobre la implementación de nodos de búsqueda por separado, consulte Nodos de búsqueda para el aislamiento de cargas de trabajo.

Al migrar a nodos de búsqueda, Atlas los implementa, pero no procesa consultas hasta que crea correctamente todos los índices del clúster en ellos. Mientras Atlas crea los índices en los nuevos nodos, continúa procesando consultas utilizando los índices de los nodos del clúster. Atlas comienza a procesar consultas desde los nodos de búsqueda solo después de crear correctamente los índices en ellos y eliminarlos de los nodos del clúster.

Al ejecutar una consulta, esta se dirige al mongod según la preferencia de lectura configurada. El mongod proceso dirige 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 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 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 pausará y eliminará todas las implementacionesmongot de MongoDB Vector Search asociadas ( procesos).

Beneficios

Este modelo de implementación proporciona los siguientes beneficios:

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

• Procesa automáticamente consultas de búsqueda vectorial de MongoDB simultáneamente, lo que mejora el tiempo de respuesta, especialmente en conjuntos de datos grandes. Para obtener más información, consulte Ejecución de consultas paralelas entre segmentos.

Dimensione sus nodos de búsqueda para producción

MongoDB Vector Search almacena el índice completo en memoria, por lo que es necesario garantizar que haya suficiente memoria para el índice y la JVM. Los nodos de búsqueda permiten aislar la carga de trabajo sin aislar los datos, y casi el 90% de su asignación de RAM se puede utilizar para almacenar los datos vectoriales y los índices en memoria, mientras que el resto se utiliza 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.

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, una capacidad de almacenamiento y una 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:

• Ajuste la cantidad de nodos de búsqueda en su clúster.

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

Recomendamos que su nodo tenga una RAM al menos un 10% mayor que el tamaño total de sus índices de MongoDB Vector Search. También le recomendamos asegurarse de tener suficientes CPU disponibles. La latencia de las consultas depende de la cantidad de CPU disponibles, lo que puede afectar significativamente el nivel de concurrencia interna que acelera el rendimiento de las consultas.

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.

Migrar 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, realice los siguientes cambios en su implementación:

1. Si su implementación utiliza actualmente un clúster de nivel gratuito o un clúster Flex, actualice su clúster 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 la migración a un nivel de clúster diferente, consulte Modificar Cluster Tier el.

2. Los nodos de búsqueda dedicados están disponibles en un subconjunto de las regiones de AWS y Azure, así como en todas las regiones compatibles con Google Cloud. 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.