Make the MongoDB docs better! We value your opinion. Share your feedback for a chance to win $100.
Click here >
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.

Considera estas estrategias para optimizar los costos de Atlas.

Utiliza el Performance Advisor y las métricas del clúster para identificar clústeres sobredimensionados. Busque consistentemente bajos 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, Escalado a la baja 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 se puede pasar manualmente a un nivel de clúster inferior mediante la supervisión regular del clúster. CPU, caché de WireTiger, memoria e IOPs durante un período continuo de 30 días de uso normal. Por lo general, si el uso está constantemente por debajo del 45% de los recursos asignados, recomendamos una reducción de 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 aprender más, consulte Orientación para la 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 una base de datos consume recursos tanto en tu aplicación como en el clúster. Los pools de conexiones sobreaprovisionados crean una sobrecarga innecesaria y, de hecho, pueden perjudicar el rendimiento debido al agotamiento de las conexiones.

Para obtener más información, consulte Límites de conexión de MongoDB Atlas y nivel 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 aprender más, se puede consultar Analizar queries lentas.

Un índice de MongoDB Search podría estar desactualizado por 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 para pausar la replicación es del 90% y el umbral para reanudarla es del 85% de utilización del disco para todas las escrituras del clúster. Sin nodos dedicados de MongoDB Search, el umbral para pausar la replicación es del 96% y el umbral para reanudarla es del 94% de utilización del disco para todas las escrituras del clúster.

  • Si la replicación se detiene durante un periodo superior al de la oplog window, el proceso de MongoDB Search mongot queda fuera del oplog y debe resincronizarse.

    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 aprender más, se puede consultar Solucionar problemas de MongoDB Search.

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 más información, consulte Diseño del esquema.

Utilice funciones como archivo en línea o índices TTL para mover datos antiguos de almacenamiento activo más costoso a almacenamiento frío menos costoso, o eliminar los datos que ya no se necesiten. Después de archivar los datos, puedes 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.

Cada mes, revisa tu factura para evaluar los servicios de mayor costo utilizando las sugerencias anteriores de optimización de facturación. Esta es una buena 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 los 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.

Aplicar etiquetas consistentes a sus proyectos y clústeres de Atlas por equipo, entorno o centro de costos. Utilice etiquetas descriptivas como "equipo-marketing", "env-producción" o "proyecto-aplicación-móvil" para crear una propiedad clara y visibilidad de gastos 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 aprender más, consulte las etiquetas de recursos.

Volver

Cost Optimization