Overview
The following sections describe deployment options for MongoDB Search on Atlas.
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 nodo |
|---|---|---|---|---|
Consultas de prueba | Clúster Flexible o Dedicado | Clúster gratuito, Flex o de nivel superior | All | MongoDB and Search processes run on the same node. |
Prototipado de aplicaciones | Clúster dedicado, particionado o sin partición |
| Todo | MongoDB and Search processes run on the same node. |
Producción | clúster dedicado con nodos de búsqueda separados, particionado o no particionado |
| AWS and Azure in some regions or Google Cloud in all regions | MongoDB and Search processes run on different nodes. |
Community Edition | Self-managed deployment. You install and operate | N/A. You provide your own hardware or cloud instances. | N/A. You choose your own infrastructure. | MongoDB and Search processes run on either a single or separate self-managed hosts. |
Las siguientes secciones describen cada entorno:
Entornos de pruebas y 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 totales para indexar
Menos de 10GB de datos indexados.
Menos de 10,000 consultas en un período de 7días
Si el uso supera los valores listados, migrar 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 MongoDB Search en clústeres en la nube, puedes implementar un clúster Flex o un clúster dedicado.
To test MongoDB Search queries locally, create a local Atlas deployment using the Atlas CLI. This could be a single-node replica set hosted on your local computer. Local deployments are limited by the CPU, memory, and storage resources of your local machine. When your application is ready for production, migrate your local Atlas deployment to a production environment.
- Cluster Tiers
Para probar sus consultas de MongoDB Search, use clústeres gratuitos (antes conocidos como
M0) y clústeres flexibles.For prototyping your application, use dedicated
M10,M20, and higher tier clusters or deploy dedicated Search Nodes for workload isolation. When your application is ready for production and to handle large datasets, scale to higher tiers.- Proveedor de nube y región
Utiliza cualquier región de proveedor de nube compatible.
The cloud provider and region that you choose affect the configuration options available for the cluster tiers and the cost of running the cluster.
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.
Para aprender cómo MongoDB Search procesa las query en esta arquitectura, 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
When you enable MongoDB Search, you can easily build search on top of your data with an integrated, fully managed search engine that automatically syncs to your database. MongoDB Search provides a rich query language that uses MongoDB Search aggregation pipeline stages like $search and $searchMeta for full-text search and $vectorSearch for semantic search in conjunction with other MongoDB aggregation pipeline stages, and score-based results ranking.
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
You might experience resource contention between the database mongod and the search mongot processes. This could negatively impact the performance of your index and latency of your queries. To support production-ready applications and their search workloads migrate to dedicated Search Nodes.
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:
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 nivel de clúster - SSDlocal | Cuando escalas un clúster de Atlas usando SSD local, 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 | In rare cases where you require downgrading Lucene, you might not be able to read newer Lucene index formats. |
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 decides migrar tu entorno de pruebas existente a producción, añade nodos de búsqueda dedicados a tu clúster. Para aprender más información, consulta Migrar a Nodos de Búsqueda Dedicados.
Si creas una nueva implementación de producción desde cero, asegúrate de utilizar
M10o clústeres de mayor nivel que sean compatibles con MongoDB Search en las regiones y zonas donde MongoDB Search está disponible, y añade Nodos de Búsqueda dedicados a tu 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.We recommend that you also deploy dedicated Search Nodes. If your search requirements increase, you can scale up your search deployment independently of scaling up the MongoDB nodes.
- Proveedor de nube y región
Use Search Nodes in all Google Cloud regions and in a subset of AWS and Azure regions. You must select a cloud provider and region where Search Nodes are available for your deployment.
All cluster tiers are available in supported cloud provider regions. The cloud provider and region that you choose affect the configuration options and search tiers available for the cluster and the cost of running the cluster.
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.
Para aprender cómo MongoDB Search procesa las query en esta arquitectura, 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
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
mongodcomomongot, 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.
Nota
The local SSDs used for Search Nodes require a 20% storage overhead to support index operations.
Costo de nodos de búsqueda
MongoDB supports separate Search Nodes on dedicated (M10 or higher) clusters. Search Nodes are deployed on compute-intensive instances with high-performance local storage. You must deploy a minimum of two nodes. You will be billed daily for hourly resource usage per node. To learn more, see Search Node Costs.
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.
When you enable dedicated Search Nodes, search processes run on separate nodes. This allows you to enable Search Node Data Encryption, so you can encrypt both database data and search indexes with the same customer-managed keys for comprehensive encryption coverage.
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 funcionalidad 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 **escalar** tu implementación de búsqueda de forma independiente de tu **implementación de la base de datos**.
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.
To deploy dedicated Search Nodes, you must have Project Owner access to the project.
Para agregar nodos de búsqueda dedicados:
Create your cluster as an
M10or higher tier in a cloud provider and region that supports node isolation. To learn more, see Create a Cluster.Dedicated Search Nodes are supported only for
M10and higher cluster tiers and in cloud provider regions that support node isolation.Enable Search Nodes for workload isolation and Configure Search Nodes.
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:
If your deployment uses a Flex cluster, change the cluster tier to a higher tier. Dedicated Search Nodes are supported only for
M10and higher cluster tiers.Deploy your cluster in regions where Search Nodes are also available. Dedicated Search Nodes are available on a subset of the AWS and Azure regions and in all supported Google Cloud regions. If your existing cluster is hosted in regions where Search Nodes aren't available, migrate your cluster to regions where Search Nodes are available. To learn more, see Cloud Provider Regions that Support Node Isolation.
Enable Search Nodes for workload isolation and configure Search Nodes. To learn more, see Add Search Nodes.
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
Failed to Execute search Command Error
Si implementas mongot para ejecutarlo junto con mongod y no configuras nodos de búsqueda, es posible que mongot finalice y devuelva el error Failed to Execute search Command durante cualquiera de los siguientes eventos:
Escalado 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.
MongoDB Community Edition
If you run MongoDB Search on MongoDB Community Edition or another self-managed deployment, Atlas does not manage mongot for you. Instead, you install, configure, and operate mongot yourself. The following sections summarize the available architecture patterns and sizing options. For complete deployment and sizing guidance, see MongoDB Search and MongoDB Vector Search on Self-Managed Deployments and Introduction to mongot Deployment Sizing.
Patrones de arquitectura
As with MongoDB Search on Atlas, self-managed deployments use one of the same two architecture patterns: co-located or dedicated. The only exception is that on self-managed deployments, you provision and manage the hosts yourself.
Dimensionamiento
Unlike Atlas, self-managed deployments have no predefined cluster or search tiers. You provision your own hardware or cloud instances. To choose a starting configuration and refine it based on your workload, see Introduction to mongot Deployment Sizing.