Overview
Puedes estructurar tu clúster con diferentes tipos de implementaciones, proveedores de nube y niveles de clúster para satisfacer las necesidades de un entorno de preproducción o producción. Utilice estas recomendaciones para seleccionar el tipo de implementación, el proveedor de nube y la región, así como los niveles de clúster y búsqueda para realizar una búsqueda vectorial.
Entorno | Tipo de implementación | Nivel de clúster | Región del Proveedor de la Nube | Arquitectura de nodos |
|---|---|---|---|---|
Consultas de prueba | Flex or dedicated cluster Local deployment | Free cluster, Flex, or higher tier N/A | All N/A | Los procesos de MongoDB y búsqueda se ejecutan en el mismo nodo |
Prototipado de aplicaciones | Clúster dedicado, particionado o sin partición |
| Todo | Los procesos de MongoDB y búsqueda se ejecutan en el mismo nodo |
Producción | clúster dedicado con nodos de búsqueda separados, particionado o no particionado |
| AWS y Azure en algunos regiones o Google Cloud en todas las regiones | Los procesos de MongoDB y Search se ejecutan en diferentes nodos |
Las siguientes secciones describen cada entorno:
Entornos de prueba y creación de prototipos
Para probar tus consultas de búsqueda y prototipar tu aplicación, te recomendamos el tipo de implementación y la arquitectura de nodos que se describen en las siguientes secciones.
Esta configuración es la más adecuada para los siguientes casos de uso:
Menos de 2M de documentos en total para indexar
Menos de 10GB de datos indexados.
Menos de 10,000 consultas en un período de 7días
Si tu uso excede los valores listados, migra a nodos de búsqueda dedicados.
Las siguientes secciones describen esta arquitectura de nodo con más detalle.
- Tipo de implementación
Para probar consultas de búsqueda de MongoDB en clústeres en la nube, puede implementar un clúster Flex o dedicado.
Para probar las consultas de búsqueda de MongoDB localmente, cree una implementación local de Atlas mediante la CLI de Atlas. Esta podría ser un conjunto de réplicas de un solo nodo alojado en su equipo local. Las implementaciones locales están limitadas por los recursos de CPU, memoria y almacenamiento de su equipo local. Cuando su aplicación esté lista para producción, migre su implementación local de Atlas a un entorno de producción.
- Cluster Tiers
Para probar sus consultas de MongoDB Search, use clústeres gratuitos (antes conocidos como
M0) y clústeres flexibles.Para crear un prototipo de su aplicación, utilice clústeres dedicados en los
M10,M20y superiores niveles, o implemente nodos de búsqueda dedicados para el aislamiento de la carga de trabajo. Cuando tu aplicación esté lista para producción y para gestionar grandes conjuntos de datos, escala a niveles superiores.- Proveedor de nube y región
Utiliza cualquier región de proveedor de nube compatible.
El proveedor de nube y la región que elijas afectan las opciones de configuración disponibles para los niveles de clúster y el costo de ejecutar el clúster.
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 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.
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.
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 habilitas MongoDB Search, puedes construir fácilmente una función de búsqueda sobre tus datos con un motor de búsqueda totalmente integrado y gestionado, que se sincroniza automáticamente con tu base de datos. MongoDB Search proporciona un languaje del query rico que utiliza etapas del pipeline de agregación de MongoDB Search como $search y $searchMeta para la búsqueda de texto completo y $vectorSearch para la búsqueda semántica en conjunto con otras etapas del pipeline de agregación de MongoDB, y una clasificación de resultados basada en puntajes.
Dependiendo de los recursos provistos para su clúster, implementar ambos procesos en el mismo nodo puede ser más rentable que ejecutar el proceso de búsqueda en un nodo dedicado separado.
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. Para soportar aplicaciones listas para producción y sus cargas de trabajo de búsqueda, migra a nodos de búsqueda dedicados.
Costo
No hay cargos ni tarifas adicionales al habilitar MongoDB Search en su clúster. Sin embargo, podría observar un aumento en el uso de recursos en el clúster para colecciones indexadas o definiciones de índices grandes.
Considerations
Dado que los procesos mongod y mongot se ejecutan en el mismo nodo, mongot podría no estar disponible en determinadas circunstancias. La siguiente tabla describe las posibles causas:
Causa | Descripción |
|---|---|
Escalado de nivel de clúster - almacenamiento de red | Cuando escales un clúster hacia arriba o hacia abajo, Atlas aprovisiona una nueva instancia. Una vez que la instancia está lista, Atlas adjunta el almacenamiento de red e inicia Si |
Escalado de niveles de clúster:SSD local | Cuando escalas un clúster Atlas usando SSD local (SSD), no puedes conservar el almacenamiento y volver a adjuntarlo a los nuevos nodos. Por lo tanto, Atlas realiza una sincronización inicial para reconstruir los índices de búsqueda. Las consultas de búsqueda fallan hasta que se complete la sincronización inicial. |
Downgrade de Lucene | En casos excepcionales en los que se requiere realizar un downgrade de Lucene, es posible que no se puedan leer los formatos de índice de Lucene más recientes. |
Ajuste de almacenamiento | Se puede conservar el almacenamiento en red conectado a los nodos del clúster de Atlas. Esto le permite expandir o contraer la capacidad de volumen sin impacto en Sin embargo, conservar el almacenamiento en red puede no ser posible en ciertas regiones, cuando el clúster utiliza discos locales NVMe, o en otras circunstancias poco frecuentes. En estos casos, Atlas realiza una sincronización inicial y las consultas de búsqueda fallan hasta que se complete la sincronización inicial. |
| Durante una actualización de la versión |
Nuevo nodo | Cuando añades un nuevo nodo a tu clúster, Atlas realiza una sincronización inicial para crear los índices de búsqueda. Las consultas de búsqueda que utilizan el nuevo nodo |
Reinicio o reemplazo de instancia |
|
| Cada vez que el proceso |
Ambiente de producción
Para su aplicación lista para producción, recomendamos utilizar el tipo de implementación y la arquitectura de nodos descritos en las siguientes secciones.
Esta configuración es la más adecuada para los siguientes casos de uso:
Si decide migrar su entorno de pruebas actual a producción, agregue nodos de búsqueda dedicados a su clúster. Para obtener más información, consulte Migrar a nodos de búsqueda dedicados.
Si crea una nueva implementación de producción desde cero, asegúrese
M10de usar clústeres de nivel o superior que admitan MongoDB Search en las regiones y zonas donde MongoDB Search esté disponible, y agregue nodos de búsqueda dedicados a su entorno. Para obtener más información, consulte Agregar nodos de búsqueda dedicados.
- Tipo de implementación
Para las aplicaciones listas para producción, utiliza
M10,M20y los niveles superiores de clústeres dedicados. Estos clústeres de nivel superior pueden gestionar grandes conjuntos de datos y cargas de trabajo de producción.Recomendamos que también implementes nodos de búsqueda dedicados. Si tus requisitos de búsqueda aumentan, puedes escalar el despliegue de búsqueda de forma independiente al escalamiento de los nodos de MongoDB.
- Proveedor de nube y región
Utiliza los nodos de búsqueda en todas las regiones de Google Cloud y en una subgrupo 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 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 afectan las opciones de configuración y los niveles de búsqueda disponibles para el clúster, así como el coste 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 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.
Al implementar 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 detectar y sincronizar los cambios de índice de los índices que almacena. MongoDB 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 Clientes compatibles y Consultas e índices. 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.
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.
Nota
Escalar su clúster añadiendo nodos de búsqueda o modificando el nivel de búsqueda desencadena la reconstrucción completa del índice de búsqueda de MongoDB. Sin embargo, si su clúster en AWS o Azure tiene nodos de búsqueda dedicados para los que no ha habilitado el cifrado en reposo mediante la administración de claves del cliente, Atlas ofrece las siguientes optimizaciones:
Cuando escala sus nodos de búsqueda, Atlas usa una copia reciente de su índice en S3 o Azure Blob Storage en lugar de reconstruir todo el índice de búsqueda de MongoDB en el nuevo nodo.
Para los nodos existentes, Atlas toma y carga periódicamente una nueva lista incremental de archivos de índice. Atlas conserva los archivos de índice durante un máximo de catorce (14) días.
Esto aún no está disponible para clústeres con nodos de búsqueda dedicados en Google Cloud.
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
La implementación de nodos de búsqueda separados proporciona los siguientes beneficios:
- Alta disponibilidad
- Cuando implementa nodos de búsqueda separados, Atlas aplica un mínimo de dos nodos de búsqueda para garantizar que su carga de trabajo permanezca 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
mongodcomomongot, y eliminas la competencia de recursos entre estos procesos.Los nodos de búsqueda dedicados admiten la búsqueda simultánea de segmentos, lo que permite a MongoDB Search buscar en varios segmentos de índice simultáneamente. En algunos casos, la búsqueda simultánea de segmentos mejora el tiempo de respuesta de las consultas.
- 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 con un índice de búsqueda de 10GB y un total de 4GB de RAM en el nodo de búsqueda. En este caso, si otros procesos utilizan 1GB de RAM y solo hay 3GB disponibles para los datos del índice, los 7GB restantes (10GB - 3GB = 7GB) se paginan desde el disco, según sea necesario. La paginación frecuente desde el disco provoca un aumento de fallos de página, E/S de disco y espera de E/S 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.
Nota
Las SSDlocales usadas para los nodos de búsqueda requieren un 20% de almacenamiento adicional para soportar las operaciones del índice.
Costo de nodos de búsqueda
MongoDB admite nodos de búsqueda independientes enM10 clústeres dedicados ( o superior). Los nodos de búsqueda se implementan en instancias de alto rendimiento con almacenamiento local de alto rendimiento. Debe implementar un mínimo de dos nodos. Se le facturará diariamente por el uso de recursos por hora de cada nodo. Para obtener más información, consulte 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 habilitas nodos de búsqueda dedicados, los procesos de búsqueda se ejecutan en nodos independientes. Esto te permite activar 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 el mismo cifrado administrado por el cliente, lo que proporciona una cobertura completa de cifrado.
Nota
Los nodos de la base de datos y los nodos de búsqueda utilizan diferentes métodos de cifrado con las mismas claves gestionadas por el cliente. Los nodos de la base de datos usan el motor de almacenamiento cifrado WiredTiger, mientras que los nodos de búsqueda usan cifrado a nivel de disco.
Para obtener más información, consulta Permitir la gestión de claves de cliente para los nodos de búsqueda.
Importante
Esta característica está disponible en todos los proveedores de KMS, pero los Nodos de búsqueda deben estar en AWS.
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:
Crea tu clúster como un
M10o 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
M10y niveles de clúster superiores y en regiones de proveedores de nube que admiten el aislamiento de nodos.Activar Search Nodes for workload isolation y configurar 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:
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
M10y niveles de clúster superiores.Implemente su clúster en regiones donde también estén disponibles los nodos de búsqueda. Los nodos de búsqueda dedicados están disponibles en un subconjunto de las regiones de AWS y Azure, y en todas las regiones compatibles con Google Cloud. Si su clúster actual está alojado en regiones donde no hay nodos de búsqueda disponibles, migre su clúster a regiones donde sí los haya. Para obtener más información, consulte Regiones de proveedores de nube compatibles con el aislamiento de nodos.
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.
Cuando se implementan nodos de búsqueda dedicados, ocurre la siguiente secuencia de acciones:
Atlas crea los índices de búsqueda en los nodos de búsqueda y elimina los índices de los nodos del clúster.
Atlas dirige las consultas de búsqueda a los nodos de búsqueda.
MongoDB Search utiliza los índices de búsqueda para atender consultas en su clúster.
Solucionar problemas de implementación
Failed to Execute search Command Error
Si mongot implementa para que se ejecute junto con mongod y no configura los nodos de búsqueda, mongot podría finalizar y devolver el Failed to Execute search Command error durante cualquiera de los siguientes eventos:
Ampliación de un clúster
Failover de nodo
Actualización
mongot
Si se implementa mongot en nodos de búsqueda dedicados, mongod utiliza un proxy que dirige las consultas de búsqueda solo a los nodos saludables donde el proceso mongot está activo.