Resumen

  • En Atlas Core con Search Nodes separados, la pausa elimina los datos de esos nodos. Al reanudar, Atlas crea otros y reconstruye los índices; entretanto, $search y $vectorSearch quedan indisponibles.
  • Las métricas de búsqueda anteriores a la pausa no se conservan. Comparar el servicio exige guardar pruebas propias antes del cierre.
  • Durante la pausa se cobra almacenamiento. Para valorar el ahorro hay que incorporar la preparación de la vuelta y revisar la factura real de los recursos en funcionamiento.

El catálogo abre; el buscador sigue con el casco puesto

Un catálogo puede tener todos sus productos y llegar tarde a su demostración. Basta con que el mecanismo para encontrarlos todavía se esté construyendo. Ese es un escenario de compra perfectamente concreto para una empresa que decide pausar MongoDB Atlas y volver a encenderlo antes de enseñar su aplicación.

La documentación de MongoDB explica por qué. En Atlas Core con nodos de búsqueda independientes, pausar elimina los datos de Search Nodes. Reanudar crea nuevos nodos y reconstruye los índices. Mientras dura la reconstrucción, las etapas $search y $vectorSearch están indisponibles. Atlas Infinite, en su vista previa pública, no admite estos nodos; el análisis se refiere a la configuración de Core.

El cliente conserva la base de su trabajo y vuelve a preparar el instrumento de búsqueda. La plataforma se ocupa de ese trabajo automáticamente. La empresa compradora se ocupa de encajarlo antes de la cita. Hay una diferencia comercial entre delegar la obra y disponer ya del local abierto.

La distinción pesa más cuando varias áreas comparten el entorno. Quien decide cerrarlo puede ganar horas de consumo evitado. Quien tiene que usarlo recibe el horario de preparación. Y quien prometió la demostración necesita una búsqueda que devuelva resultados, no una conexión a la base de datos que haya superado su prueba. Repartir esas tres tareas entre tres personas no reduce su coste conjunto.

Una rebaja auténtica con billete de regreso

La política de costes del clúster dice que durante la pausa solo se cobra almacenamiento. También se cobra el correspondiente a la capacidad predeterminada. Para un entorno de uso esporádico, dejar de mantener capacidad de cómputo activa ofrece un motivo económico claro para suspenderlo.

El error de gestión aparece cuando se valora únicamente la ida. En una hoja de cálculo resulta fácil multiplicar las horas sin uso. Cuesta algo más preguntar cuántas veces habrá que preparar otra vez el entorno, quién hará las comprobaciones y cuánto margen habrá antes de usarlo. Esa segunda mitad determina si una reducción de consumo facilita el trabajo o solo lo cambia de hora.

Los nodos de búsqueda se cobran por horas, con una hora completa incluso cuando solo se ejecutan durante parte de ella. El número de nodos, su nivel de recursos y el tráfico con los nodos de base de datos intervienen en la factura. El comprador debe contrastar esas reglas con sus cargos reales y con el momento en que pudo usar la búsqueda. El documento de precios habla de recursos; no fija un nuevo inicio de cobro en el instante en que un índice se vuelve útil para el negocio.

Una pausa larga reparte la preparación entre muchas horas de descanso. Las interrupciones breves y repetidas vuelven a presentar la misma cuenta de trabajo. Para decidir, importa tanto la frecuencia como la duración. El mejor calendario no sale de admirar el botón: sale de medir el regreso.

La comparación pierde su pasado

El regreso también cambia el material disponible para evaluar el resultado. MongoDB avisa en su documentación de métricas de búsqueda de que no conserva las métricas previas a la pausa. Tras reanudar solo quedan las de los nuevos nodos. La continuidad del análisis no viene incluida en la reconstrucción.

Antes de cerrar, una empresa puede guardar sus propias pruebas: consultas representativas, resultados esperados, tiempos y condiciones de ejecución. Después repite la prueba y anota cualquier cambio de datos, definición de índices o configuración. Así tiene un antes y un después comparables, aunque los gráficos del servicio hayan empezado otra vida.

Esto evita una comedia bastante cara: finanzas exhibe una cifra de consumo menor, operaciones muestra una curva nueva y el equipo de producto recuerda que antes la demostración arrancaba más rápido. Los tres pueden tener razón. Sin una secuencia común de medidas, la reunión solo reparte convicciones.

Un relevo permite conservar al titular

MongoDB utiliza otra técnica en cambios ordinarios. Su guía de administración de índices describe la reconstrucción en segundo plano al modificar una definición, mientras el índice anterior sigue atendiendo consultas. En un cambio de topología de búsqueda, prepara los nuevos nodos antes de retirar los antiguos. El relevo llega cuando todavía hay alguien trabajando.

En una vuelta de la pausa, los datos de los nodos separados ya se han eliminado. Por eso conviene distinguir la suspensión de una actualización de definición o de un cambio de distribución. Meterlo todo en la carpeta «mantenimiento» oculta la pregunta operativa: ¿qué capacidad continúa sirviendo al usuario mientras se prepara la siguiente?

La comprobación puede empezar por getSearchIndexes(). El método devuelve el estado y queryable, que indica si se puede consultar el índice. Después viene la prueba que justifica haber comprado el servicio: las búsquedas que necesita la aplicación, con sus resultados y tiempos aceptables. Un catálogo se demuestra encontrando sus productos.

Faltan mediciones de clientes que unan reconstrucción, respuesta útil y factura; una vuelta breve y regular reforzaría el atractivo de las pausas frecuentes. Con la información disponible, el trato queda bien definido. Atlas automatiza la reconstrucción y reduce el consumo durante la suspensión. El comprador debe poner precio al tiempo de volver a estar preparado. Las obras pueden estar perfectamente contratadas y aun así exigir cambiar la hora de apertura.