Overview
Puede estructurar su clúster con diferentes tipos de implementación, 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 búsquedas vectoriales.
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 | M0, Flex, or higher tierN/A | All N/A | Los procesos MongoDB y Search se ejecutan en el mismo nodo |
Aplicaciones de creación de prototipos | Clúster dedicado, fragmentado o no fragmentado |
| Todo | Los procesos MongoDB y Search se ejecutan en el mismo nodo |
Producción | Clúster dedicado con nodos de búsqueda separados, fragmentados o no |
| AWS y Azure en algunos regiones o Google Cloud en todas las regiones | Los procesos de MongoDB y de búsqueda se ejecutan en nodos diferentes |
Las siguientes secciones describen cada entorno:
Entornos de prueba y creación de prototipos
Para probar sus consultas de búsqueda y crear prototipos de su aplicación, recomendamos el tipo de implementación y la arquitectura de nodo 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 su uso excede los valores enumerados, migre 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 búsqueda de MongoDB, utilice clústeres gratuitos (
M0) y Flex.Para prototipar su aplicación, utilice
M10M20clústeres dedicados de, y de niveles superiores, o implemente nodos de búsqueda dedicados para aislar la carga de trabajo. Cuando su aplicación esté lista para producción y pueda gestionar grandes conjuntos de datos, escale a niveles superiores.- Proveedor de nube y región
Utilice cualquier región de proveedor de nube compatible.
El proveedor de nube y la región que elija afectan las opciones de configuración disponibles para los niveles del clúster y el costo de ejecución del 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.
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.
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
Al habilitar MongoDB Search, puede crear fácilmente búsquedas basadas en sus datos con un motor de búsqueda integrado y totalmente administrado que se sincroniza automáticamente con su base de datos. MongoDB Search ofrece un lenguaje de consulta completo que utiliza las etapas de la canalización de agregación de MongoDB Search, como $search y para la $searchMeta búsqueda de texto $vectorSearch completo, y para la búsqueda semántica, junto con otras etapas de la canalización de agregación de MongoDB y la clasificación de resultados basada en puntuaciones.
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
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. Para dar soporte a las aplicaciones listas para producción y sus cargas de trabajo de búsqueda,migre 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 niveles de clúster: almacenamiento en red | Al escalar un clúster, Atlas aprovisiona una nueva instancia. Una vez que la instancia está lista, Atlas conecta el almacenamiento en red e inicia Si |
Cluster Tier Scaling - Local SSD | When you scale an Atlas cluster using local SSD, you can't retain storage and reattach it to the new nodes. Therefore, Atlas performs an initial sync to rebuild the search indexes. Search queries fail until the initial sync is complete. |
Degradación de Lucene | En los casos excepcionales en los que necesites degradar Lucene, es posible que no puedas leer los formatos de índice de Lucene más nuevos. |
Ajuste de almacenamiento | Puede conservar el almacenamiento de red conectado a los nodos del clúster Atlas. Esto le permite ampliar o reducir la capacidad del volumen sin afectar a 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 | Al agregar un nuevo nodo al clúster, Atlas realiza una sincronización inicial para crear los índices de búsqueda. Las consultas de búsqueda que usan el nuevo nodo |
Reinicio o reemplazo de instancia |
|
| Cada vez que el proceso |
Entorno de producción
Para su aplicación lista para producción, recomendamos utilizar el tipo de implementación y la arquitectura de nodo que se describen 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 aplicaciones listas para producción, utilice clústeres dedicados de niveles
M10,M20y superiores. Estos clústeres de nivel superior pueden gestionar grandes conjuntos de datos y cargas de trabajo de producción.Le recomendamos que también implemente nodos de búsqueda dedicados. Si sus necesidades de búsqueda aumentan, puede ampliar su implementación de búsqueda independientemente de la ampliación de los nodos de MongoDB.
- 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.
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 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 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.
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.
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.
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 implementaciones de búsquedamongot de MongoDB asociadas ( 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
Al implementar nodos de búsqueda independientes, puede escalar el almacenamiento y el procesamiento independientemente de su clúster de MongoDB. Esto también le permite escalar la carga de consultas independientemente de MongoDB.
Para escalar los nodos de búsqueda horizontalmente, aumente o reduzca su número. Puede aprovisionar 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 los nodos de búsqueda verticalmente, seleccione diferentes niveles de búsqueda, CPU, RAM y configuraciones de almacenamiento que admitan sus cargas de trabajo de texto completo.
- Rendimiento
Al implementar nodos de búsqueda dedicados, mejora el rendimiento y la utilización de recursos para los procesos
mongodymongoty elimina la contención 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 de forma independiente de las operaciones de la base de datos principal, lo que proporciona aislamiento de la carga de trabajo, mientras que solo se generan cargos de red por el tráfico entre los nodos de búsqueda y los nodos de la base de datos.
Consejos para dimensionar y escalar los nodos de búsqueda
Para determinar los requisitos de memoria para los nodos de búsqueda, utilice 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 más alto con más RAM, como 8GB o más, esto permite que Atlas sirva la mayoría de los datos para el índice de búsqueda desde la memoria, minimizando las lecturas de disco y las fallas de página y, de esta manera, mejorando 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 admite nodos de búsqueda independientes enM10 clústeres dedicados ( o superiores). Los nodos de búsqueda se implementan en instancias NVMe de alto consumo de recursos. Debe implementar un mínimo de dos nodos. Se le facturará diariamente el uso de recursos por hora por 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.
Al habilitar nodos de búsqueda dedicados, los procesos de búsqueda se ejecutan en nodos separados. Esto le permite habilitar el cifrado de datos de nodos de búsqueda, lo que le permite 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 completa.
Nota
Los nodos de base de datos y los nodos de búsqueda utilizan diferentes métodos de cifrado con las mismas claves administradas por el cliente. Los nodos de base de datos utilizan el motor de almacenamiento cifrado WiredTiger, mientras que los nodos de búsqueda utilizan 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 le permite:
Cambie el tamaño y la escala de su implementación de búsqueda independientemente de su clúster.
Elimine la contención de recursos que pueda experimentar en un clúster que ejecuta la base de datos MongoDB y los procesos de búsqueda en el mismo nodo.
Para agregar nodos de búsqueda dedicados:
Cree su clúster como
M10o de nivel superior en un proveedor de nube y una región que admitan el aislamiento de nodos. Para obtener más información, 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 and Configure Search Nodes.
Migrar a nodos de búsqueda dedicados
Para migrar desde el entorno de ensayo a la producción y agregar nodos de búsqueda dedicados, realice los siguientes cambios en su implementación de ensayo y creación de prototipos existente:
Si su implementación utiliza un clúster Flex, cambie el nivel del clúster a uno superior. Los nodos de búsqueda dedicados solo son compatibles con
M10y niveles de clúster superiores.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.
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
Conmutación por error de nodo
Actualización
mongot
Si implementa mongot en nodos de búsqueda dedicados, mongod utiliza un proxy que enruta las consultas de búsqueda solo a los nodos en buen estado donde el proceso mongot está activo.