Join us at MongoDB.local London on 7 May to unlock new possibilities for your data. Use WEB50 to save 50%.
Register now >
Docs Menu
Docs Home
/ /

Recomendaciones para configuraciones de ahorro de costos en Atlas

Para entender mejor y optimizar tus gastos, especialmente a medida que aumenta tu uso, MongoDB Atlas ofrece herramientas para gestionar y controlar los costos de la base de datos de tu organización.

Las siguientes recomendaciones aplican a todos paradigmas de implementación.

Considere estas estrategias para optimizar sus costos de Atlas.

Utilice Performance Advisor y las métricas de clúster para identificar clústeres sobredimensionados. Busque niveles bajos constantes. System Max: User CPU utilization (por debajo del 45%) o memoria RAM sobrante que nunca se utiliza por completo. Luego reduzca a un nivel que se adapte mejor a los patrones reales de la carga de trabajo.

Muchos equipos comienzan con clústeres más grandes y se olvidan de ajustar a medida que conocen sus verdaderos patrones de uso. Atlas ofrece opciones de baja CPU para cargas de trabajo más livianas y una posibilidad de dimensionamiento flexible que te permite asignar los recursos de acuerdo a la realidad en vez de adivinar. El dimensionamiento adecuado suele ser la palanca de costos más importante que puedes accionar.

Para aprender más, Reducir la escala de un clúster de forma reactiva.

  • Habilita el escalado automático en el nivel de clúster para reflejar el uso y evitar el sobreaprovisionamiento.

    El escalado a la baja ocurre una vez cada seis horas y debe cumplir con condiciones específicas. Para aprender más, consulta Reducción de escalado de un nivel de clúster.

    También puede moverse manualmente a un nivel de clúster inferior monitoreando regularmente el clúster. CPU, caché de WireTiger, memoria e IOP durante un 30 período continuo de días de uso normal. Generalmente, si el uso se mantiene constantemente por debajo 45del % de los recursos asignados, recomendamos reducir la escala.

  • Para clústeres dedicados, se recomienda escalar a un nivel inferior o pausar el clúster si no se va a utilizar durante un periodo prolongado.

    Recomendamos que utilices clústeres M10 o M30 para entornos de desarrollo y prueba. Para obtener más información, consulta la Guía de Tamaños de Clústeres de Atlas.

  • Para entornos de desarrollo y prueba, le recomendamos que:

Para clústeres particionados, analiza tu estrategia de escalado para evitar particiones activas. Una partición activa se produce cuando una partición en tu clúster recibe desproporcionadamente más tráfico o datos que otros, lo que te obliga a escalar todo el clúster cuando solo esa partición necesita más recursos.

Comprueba cómo se distribuyen tus colecciones en las particiones para detectar estas situaciones desiguales. Busca colecciones activas que aún no estén fragmentadas. Distribúyelos adecuadamente para que puedas reducir el tamaño general de tu clúster. También puedes configurar distintos enfoques de particionado para diferentes colecciones, según cómo uses cada una realmente. Primero intenta redistribuir el tráfico para que sea uniforme en todas las particiones, pero si esto no es posible, aprovecha la funcionalidad de partición independiente.

Cuando no se utiliza el escalado independiente de particiones, las particiones activas son costosas porque se termina pagando por escalar recursos que en realidad no se necesitan en todo el clúster. Cuando distribuyes la carga de manera más uniforme mediante el particionado inteligente, puedes ajustar tu configuración y evitar costos innecesarios. El ahorro depende de tu carga de trabajo específica, pero estos enfoques te ayudan a crecer de manera estable y rentable a medida que cambian los patrones de datos.

Para obtener más información, consulte Guía de escalabilidad de Atlas.

  • Copias de seguridad continuas son costosas, pero ofrecen la mayor seguridad para recuperar datos de cualquier punto en el tiempo dentro de la ventana de copias de seguridad en caso de desastre o error de lógica de código. Recomendamos que habilite copias de seguridad continuas únicamente para aplicaciones de producción en el nivel de datos más crítico.

  • Reducir la frecuencia de copias de seguridad para clústeres que almacenan datos menos críticos. Considera terminar completamente estos clústeres para entornos de desarrollo.

Siempre que sea posible, opte por transferencias de datos del mismo proveedor y en la misma región para minimizar los costos. Solo usa transferencias interregionales o a Internet cuando sea necesario, como en escenarios de recuperación ante desastres donde necesitas restaurar la aplicación en una región diferente. Ubicar su clúster en la misma región que la mayoría de su tráfico, generalmente donde aloja su aplicación, puede reducir en gran medida los costos de transferencia de datos.

Nota

Para aprender más y obtener orientación específica para su proveedor de nube, consulte Cómo reducir los costos de transferencia de datos.

Activa la compresión de red en tu controlador cliente para comprimir los datos entre el cliente y el servidor. Como ejemplo, puedes configurar la opción de compresión de red para tu controlador de Node.js. Atlas siempre comprime la comunicación intra-clúster.

Para obtener más información, consulte Cómo reducir los costos de transferencia de datos.

Revisa la configuración del pool de conexiones de tu aplicación y ajústalas adecuadamente para que coincidan con tus patrones reales de uso concurrente. La mayoría de las aplicaciones pueden reducir de forma segura el tamaño máximo del grupo a partir de la configuración por defecto mientras se agregan tiempos de espera adecuados de conexión y lógica de reintento.

Cada conexión a la base de datos consume recursos tanto de la aplicación como del clúster. Un exceso de recursos en los grupos de conexiones genera una sobrecarga innecesaria y puede afectar negativamente al rendimiento debido a la sobrecarga de la conexión.

Para obtener más información, consulte Límites de conexión de MongoDB Atlas y niveles de clúster.

Revisa todas las aplicaciones y procesos que acceden a tus datos para detectar ineficiencias. Asegúrate de que los queries no:

  • Vuelve a leer los datos que ya existen en el cliente.

  • Se deben volver a guardar los datos existentes en el clúster.

Para obtener más información, consulte Cómo reducir los costos de transferencia de datos.

Tip

Utilice la proyección para seleccionar qué campos de documento devolver de una consulta. Por defecto, las queries devuelven todos los campos en los documentos coincidentes. Para limitar la cantidad de datos que Atlas envía a las aplicaciones, puede incluir un documento de proyección para especificar o restringir los campos a devolver.

Las consultas que tardan mucho en ejecutarse pueden aumentar el uso de recursos, lo que requiere clústeres de nivel superior. Optimiza estas queries para reducir el consumo de recursos y, como resultado, los costos.

Programa optimizaciones trimestrales de consultas con tu equipo para revisar tus consultas más lentas y auditar tu huella de índice. Utilice Performance Advisor para identificar índices que faltan y perfilador del query para detectar operaciones costosas. Crea una hoja de cálculo sencilla para rastrear tus 10 queries más costosas y de su estado de optimización.

Las queries se degradan a medida que los datos crecen. Una query que funciona bien con 1GB puede fácilmente superar tu presupuesto con 100GB. Mientras tanto, los índices no utilizados consumen almacenamiento y ralentizan las escrituras sin aportar valor. Las revisiones regulares detectan desviaciones de rendimiento temprano y mantienen tu estrategia de indexación eficiente y deliberada.

Para obtener más información, consulte Analizar consultas lentas.

Un índice de búsqueda de MongoDB puede estar desactualizado debido a cualquiera de las siguientes razones:

  • La replicación se detuvo debido a la alta utilización del disco.

    Para los nodos dedicados de MongoDB Search, el umbral de pausa de replicación es del 90% y el umbral de reanudación de replicación es del 85% de utilización del disco para todas las escrituras en el clúster. Sin nodos dedicados de MongoDB Search, el umbral de pausa de replicación es del 96% y el umbral de reanudación de replicación es del 94% de utilización del disco para todas las escrituras en el clúster.

  • Si la replicación se detiene durante un período más largo que la ventana del oplog, el proceso MongoDB Search mongot desaparece del oplog y luego debe volver a sincronizarse.

    Este estado suele producirse cuando el punto de replicación actual ya no está disponible en el mongod oplog. Atlas reconstruye el índice si el proceso mongot se cae del registro de operaciones, lo que puede requerir muchos recursos y tomar una cantidad notable de tiempo.

  • El índice alcanzó el límite de dos mil millones de documentos.

  • La replicación falló debido a un error.

Todavía puedes realizar consultas al índice existente. Sin embargo, los resultados de las consultas sobre un índice desactualizado pueden contener datos obsoletos. Se puede incrementar el tamaño de los nodos de búsqueda para obtener más espacio en disco y, si no se supera actualmente el umbral de bloqueo, borrar los índices existentes para liberar espacio en disco. Alternativamente, use el error en el View status details ventana modal para solucionar el problema.

Para obtener más información,consulte Solucionar problemas de búsqueda de MongoDB.

Trabaje con su equipo de Atlas para revisar sus colecciones en busca de patrones que impliquen altos costes, como documentos grandes, arreglos no acotados o esquemas que requieran operaciones costosas. Busca oportunidades para integrar datos relacionados que se accedan juntos, manteniendo los documentos individuales dentro de tamaños razonables. Céntrese en eliminar patrones que requieran agregaciones complejas o búsquedas cruzadas entre colecciones cuando podrían funcionar estructuras de documentos más simples.

Un diseño de esquema deficiente aumenta silenciosamente los costes debido a consultas ineficientes y a la expansión del almacenamiento. El modelo orientado a documentos de Atlas elimina naturalmente las costosas operaciones relacionales cuando se diseña correctamente. Las colecciones bien diseñadas reducen la sobrecarga de cómputo, minimizan los requisitos del índice y mejoran el rendimiento de las consultas, todo lo cual impacta directamente en tu factura mensual.

Para obtener más información, consulte Diseño de esquema.

Utilice funciones como el archivo en línea o los índices TTL para trasladar datos antiguos de un almacenamiento en caliente más costoso a un almacenamiento en frío más económico, o eliminar datos que ya no necesite. Después de archivar los datos, puede acceder a ellos a través de Atlas Data Federation.

Utiliza regularmente la herramienta Cost Explorer para supervisar los patrones de gasto a nivel de organización, proyecto, clúster y servicio. Establece una frecuencia que se adapte a tus necesidades.

Configura alertas de facturación para umbrales clave, como cuando tus costos mensuales superan cierta cantidad. Por ejemplo: establecer una alerta cuando los costos superen los $100. Este enfoque proactivo te ayuda a evitar sorpresas.

Revise su factura mensualmente para evaluar los servicios de mayor costo utilizando las sugerencias de optimización de facturación anteriores. Esta es una práctica recomendada para identificar oportunidades de reducción de costos.

Si ves cambios inesperados en tu factura, verifica los costos de computación en la nube, que suelen ser la mayor parte de tu factura. Puedes revisar los costos de la computación en la nube en la tarjeta Summary By Service de cualquier factura dentro de la sección Atlas Billing. La vista Summary By Service muestra los costos de todos los clústeres por proveedor, nivel y región.

El paradigma de implementación y la topología que elija pueden cambiar sus costos de Atlas.

Para obtener más información sobre el ahorro de costos para las diferentes topologías, consulta Orientación sobre la alta disponibilidad de Atlas.

Aplique etiquetas consistentes a sus proyectos y clústeres de Atlas por equipo, entorno o centro de costos. Use etiquetas descriptivas como "equipo-marketing", "entorno-producción" o "proyecto-aplicación-móvil" para crear una clara visibilidad de la propiedad y el gasto en toda su organización.

Sin una etiquetación adecuada, la factura de tu Atlas se vuelve confusa al punto de que es imposible rastrear qué equipos o proyectos están generando los costos. El etiquetado de recursos transforma tu Cost Explorer en una poderosa herramienta de responsabilidad, facilitando la identificación de tendencias de costos, la asignación precisa de gastos y la detección de oportunidades de optimización por departamento o tipo de carga de trabajo.

Para obtener más información,consulte Etiquetas de recursos.

Volver

Cost Optimization