Opciones de implementación de la Búsqueda de MongoDB

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 MongoDB Search mongot en el mismo nodo que ejecuta el proceso mongod cuando creas tu primer índice MongoDB 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.

Después de que la query se enrute a un proceso mongot de MongoDB Search, el proceso mongot realiza la búsqueda y la puntuación, y devuelve los ID de documentos y otros metadatos de búsqueda para los resultados de coincidencia a su proceso mongod correspondiente. El proceso mongod luego realiza una búsqueda completa de documentos de forma implícita para obtener los resultados coincidentes y devuelve los resultados al cliente. Si se usa la opción $search concurrente en la 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.

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

Puede definir fuentes almacenadas campos en su índice de MongoDB Search para que el proceso mongot pueda almacenar los campos especificados en mongot. Luego puede utilizar la opción returnStoredSource en su consulta MongoDB Search para recuperar los campos almacenados para los documentos coincidentes directamente desde mongot en lugar de realizar una búsqueda completa de documentos en la base de datos.

Beneficios

Cuando activas MongoDB Search, puedes generar búsquedas fácilmente sobre tus datos con un motor de búsqueda integrado, totalmente gestionado y que se sincroniza automáticamente con tu base de datos. MongoDB Search ofrece un languaje del query robusto que utiliza etapas del pipeline de agregación de MongoDB Search como $search y $searchMeta para búsquedas de texto completo, y $vectorSearch para búsquedas semánticas junto con otras etapas del pipeline de agregación de MongoDB y clasificación de los resultados basada en puntuaciones.

Dependiendo de los recursos aprovisionados para tu clúster, implementar ambos procesos en el mismo nodo podría ser más rentable que ejecutar el proceso de búsqueda en un nodo dedicado por separado.

Limitaciones

Puedes experimentar una contención de recursos entre la base de datos mongod y los procesos de búsqueda mongot. Esto podría afectar negativamente al rendimiento de su índice y a la latencia de sus consultas. Para admitir aplicaciones listas para producción y sus cargas de trabajo de búsqueda, migra a nodos de búsqueda dedicados.

Costo

No hay tarifas ni cargos adicionales por habilitar MongoDB Search en tu clúster. Sin embargo, podrías observar un aumento en la utilización de recursos en el clúster para grandes colecciones indexadas o definiciones de índices.

Considerations

Puesto que los procesos mongod y mongot se ejecutan en el mismo nodo, es posible que mongot deje de estar disponible en determinadas circunstancias. En la siguiente tabla se describen las posibles causas:

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 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 implementas nodos de búsqueda por separado, Atlas asigna automáticamente un mongod para cada mongot para la indexación. El mongot se comunica con mongod para escuchar y sincronizar los cambios en los índices que almacena. MongoDB Search analiza y procesa tus búsquedas de manera similar a una implementación donde ambos los procesos mongod y mongot se ejecutan en el mismo nodo. Para obtener más información, consulta Clientes admitidos y Consultas e índices. Para obtener más información sobre la implementación de Nodos de búsqueda por separado, consulta Nodos de búsqueda para el aislamiento de la carga 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 elimina todos los nodos de búsqueda en su clúster, habrá una interrupción en el procesamiento de los resultados de su consulta de búsqueda. Para obtener más información, consulta Modificar un clúster. Si eliminas tu clúster de Atlas, Atlas pausa y luego elimina todas las implementaciones asociadas de MongoDB Search (mongot procesos).

Puede definir fuentes almacenadas campos en su índice de MongoDB Search para que el proceso mongot pueda almacenar los campos especificados en mongot. Luego puede utilizar la opción returnStoredSource en su consulta MongoDB Search para recuperar los campos almacenados para los documentos coincidentes directamente desde mongot en lugar de realizar una búsqueda completa de documentos en la base de datos.

Beneficios

El despliegue de nodos de búsqueda separados proporciona los siguientes beneficios:

Alta disponibilidad

Cuando implementas nodos de búsqueda separados, Atlas aplica un mínimo de dos nodos de búsqueda para garantizar que tu carga de trabajo siga operativa, con un tiempo de inactividad mínimo, en caso de una falla o interrupción.

Escalabilidad

Cuando despliegue nodos de búsqueda por separado, puede escalar el almacenamiento y la computación independientemente de su clúster de MongoDB. Esto permite también escalar la carga de queries de forma independiente de MongoDB.

Para escalar los nodos de búsqueda horizontalmente, incrementa o reduce el número de nodos de búsqueda. Puedes provisionar desde un mínimo de 2 hasta un máximo de 32 nodos de búsqueda. Para equilibrar la carga de consultas, MongoDB Search distribuye las consultas de búsqueda entre todos los nodos de búsqueda disponibles.

Para escalar verticalmente los Nodos de Búsqueda, seleccione diferentes niveles de búsqueda, configuraciones de CPU, RAM y almacenamiento que admitan sus cargas de trabajo de texto completo.

Rendimiento

Cuando implementas nodos de búsqueda dedicados, mejoras el rendimiento y la utilización de recursos tanto para los procesos mongod como mongot, y eliminas la competencia de recursos entre estos procesos.

Los nodos de búsqueda dedicados admiten búsqueda de segmentos concurrentes, lo que permite a MongoDB Search buscar varios segmentos de índices al mismo tiempo. El uso de una búsqueda de segmentos concurrentes mejora el tiempo de respuesta de las consultas en algunos casos.

Aislamiento de cargas de trabajo

La implementación de nodos de búsqueda dedicados no afecta directamente la transferencia de datos a los nodos principales de la base de datos. Los Nodos de Búsqueda gestionan las consultas de búsqueda por separado de las operaciones principales de la base de datos, proporcionando aislamiento de la carga de trabajo mientras solo incurres en cargos de red para el tráfico entre los Nodos de Búsqueda y los nodos de la base de datos.

Consejos para dimensionar y escalar nodos de búsqueda

Para determinar los requisitos de memoria para Search nodos, utiliza las siguientes métricas de Atlas:

• Tamaño del índice de búsqueda

• Memoria RAM total en el nodo de búsqueda

Considere una aplicación que tenga un 10GB de Índice de Búsqueda y 4GB de RAM total en el Nodo de Búsqueda. En este caso, si 1GB de RAM son utilizados por otros procesos y solo 3GB están disponibles para los datos del índice, el resto de 7GB de los datos del índice (10GB- 3GB = 7GB) se carga según sea necesario desde el disco. La paginación frecuente desde disco causa un aumento de fallos de página, operaciones de E/S en disco y IOWait de CPU, lo que resulta en una degradación del rendimiento.

Si utiliza un nivel de clúster de búsqueda superior con más RAM, como 8GB o más, esto permite que Atlas sirva la mayor parte de los datos para el índice de búsqueda desde la memoria, minimizando las lecturas en disco y los errores de página, mejorando así el rendimiento.

Costo de nodos de búsqueda

MongoDB admite nodos de búsqueda independientes en clústeres dedicados (M10 o superiores). Los nodos de búsqueda se implementan en instancias de uso intensivo de cómputo con almacenamiento local de alto rendimiento. Se deben implementar un mínimo de dos nodos. Se facturará diariamente por el uso de recursos por hora en cada nodo. Para obtener más información, consulta Costos de los nodos de búsqueda.

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.

Agregar nodos de búsqueda dedicados

Agregar nodos de búsqueda dedicados a un nuevo clúster permite:

• Cambia el tamaño y la escala de tu implementación de búsqueda de forma independiente a tu clúster.

• Elimina la competencia por recursos que puedas experimentar en un clúster que ejecuta tanto la base de datos MongoDB como los procesos de búsqueda en el mismo nodo.

Para agregar nodos de búsqueda dedicados:

1. Crea tu clúster como un M10 o un nivel superior en un proveedor de nube y una región que admitan el aislamiento de nodos. Para saber más, consulte Crear un clúster.

   Los nodos de búsqueda dedicados solo son compatibles con niveles de clúster M10 y superiores, y en las regiones del proveedor de nube que admiten el aislamiento de nodos.

2. Activa Search Nodes for workload isolation y Configura nodos de búsqueda.

Migre a nodos de búsqueda dedicados

Para migrar del entorno de staging a producción y agregar nodos de búsqueda dedicados, realiza los siguientes cambios en tu implementación actual de staging y prototipado:

1. Si tu implementación utiliza un clúster Flex, cambia el nivel de clúster a un nivel superior. Los nodos de búsqueda dedicados solo son compatibles con M10 y niveles de clúster superiores.

2. Implementa tu clúster en regiones donde también están disponibles los nodos de búsqueda. Dedicated Nodos de búsqueda están disponibles en una parte de las regiones de AWS y Azure, y en todas las regiones de Google Cloud compatibles. Si tu clúster actual está alojado en regiones donde no están disponibles los nodos de búsqueda, migra tu clúster a regiones donde los nodos de búsqueda estén disponibles. Para obtener más información, consulta Regiones de proveedores de nube que admiten el aislamiento de nodos.

3. Activa Search Nodes for workload isolation y configura nodos de búsqueda. Para obtener más información, consulta Agregar nodos de búsqueda.

   Cuando se implementan nodos de búsqueda dedicados, ocurre la siguiente secuencia de acciones:

   • Atlas compila los índices de búsqueda en los Search Nodes y remueve los índices de los nodos del clúster.

   • Atlas enruta las consultas de búsqueda a los nodos de búsqueda.

   • MongoDB Search utiliza los índices de búsqueda para servir queries en el clúster.

Solucionar problemas de implementación