Compile una aplicación resiliente con MongoDB Atlas

Gestión de memoria mejorada

Para ejecutar tu aplicación de forma segura en producción, es importante asegurarse de que la utilización de la memoria permita un margen de maniobra. Si un nodo se queda sin memoria disponible, puede volverse susceptible al Linux Out of Memory Killer que termina el mongod procesar.

MongoDB 8.0 utiliza un TCMalloc actualizado para todas las implementaciones de forma automática, lo que reduce el crecimiento promedio de la fragmentación de memoria con el tiempo. Esta menor fragmentación mejora la estabilidad operativa durante picos de carga y se traduce en una utilización de memoria mejorada en general.

Filtros de rechazo de operaciones

Una operación intensiva en recursos no intencionada puede causar problemas en la producción si no se gestiona rápidamente.

MongoDB 8.0 permite minimizar el impacto de estas operaciones mediante filtros de rechazo de operaciones. Estos filtros permiten configurar MongoDB para que rechace la ejecución de consultas hasta que se vuelvan a habilitar las consultas con esa forma de consulta.

En otras palabras, una vez que se identifica una consulta lenta, no es necesario esperar a que los equipos de la aplicación corrijan sus consultas para contener su impacto. En cambio, si se detecta una consulta con bajo rendimiento en el Analizador de Consultas, el Panel de Rendimiento en Tiempo Real o los registros de consultas, se puede establecer un filtro de rechazo para esa forma de consulta. MongoDB impide entonces que se ejecuten nuevas instancias de esa forma de consulta entrante. Una vez corregida la consulta, se puede volver a habilitar.

Debes utilizar un filtro de rechazo de operaciones si deseas:

• Contenga el impacto de las consultas lentas rápidamente mientras se está trabajando en la solución.

• Prioriza cargas de trabajo más importantes durante tiempos de sobrecarga rechazando queries menos importantes.

• Dale tiempo al clúster para recuperarse si está cerca del máximo uso de recursos.

Tiempos de espera a nivel de clúster para operaciones de lectura

Es importante asegurarse de que su proceso de desarrollo considere cuidadosamente la eficiencia de las queries antes de que lleguen a producción. Las excepciones pueden ocurrir siempre, pero tener una mitigación proactiva contra queries ineficientes puede ayudar a evitar problemas de rendimiento del clúster.

Con MongoDB 8.0, puedes proteger tus consultas de operaciones no indexadas con el defaultMaxTimeMS del lado del servidor que ingresa al clúster. Si una operación excede este tiempo de espera, MongoDB cancela la operación para evitar que las consultas se ejecuten durante demasiado tiempo y consuman recursos. Esto te permite:

• Traslada la responsabilidad de establecer límites de tiempo de los equipos de aplicaciones individuales a los equipos enfocados en bases de datos.

• Minimiza el impacto de un escaneo de colección si a la query le falta un índice.

• Disponer de una mitigación de última ronda contra operaciones costosas que llegan a producción.

Si tienes queries que requieren un tiempo de espera diferente, como las queries de análisis, puedes sobrescribirlas configurando el tiempo de espera a nivel de operación con el método maxTimeMS.

Aísla el impacto de colecciones ocupadas no fragmentadas

Lafragmentación permite escalar el clúster horizontalmente. Con MongoDB, se pueden fragmentar algunas colecciones, mientras que otras del mismo clúster permanecen sin fragmentar. Al crear una base de datos, el fragmento del clúster con la menor cantidad de datos se selecciona como el fragmento principal de forma predeterminada. Todas las colecciones sin fragmentar de esa base de datos residen en ese fragmento principal de forma predeterminada. Esto puede provocar un aumento del tráfico al fragmento principal a medida que aumenta la carga de trabajo, especialmente si este se centra en las colecciones sin fragmentar del fragmento principal.

Para distribuir mejor esta carga de trabajo, MongoDB 8.0 permite mover una colección no particionada a otras particiones desde la partición primaria mediante el comando moveCollection. Esto permite ubicar colecciones activas y ocupadas en particiones con un menor uso esperado de recursos. Con esto, puedes:

• Optimiza el rendimiento en cargas de trabajo más grandes y complejas.

• Lograr una mejor utilización de los recursos.

• Distribuye la fecha de manera más uniforme entre las particiones.

Recomendamos aislar tu colección en las siguientes circunstancias:

• Si tu partición primaria experimenta una carga de trabajo significativa debido a la presencia de varias colecciones no particionadas de alto rendimiento.

• Se anticipa que una colección sin particiones experimentará un crecimiento futuro, que podría convertirse en un cuello de botella para otras colecciones.

• Está ejecutando un diseño de implementación de una colección por clúster y desea aislar a esos clientes en función de la prioridad o las cargas de trabajo.

• Tus particiones tienen más datos de lo proporcional debido a la cantidad de colecciones no fragmentadas ubicadas en ellos.

Para aprender a mover una colección no particionada con mongosh, consulta Mover una colección.

Instale las Librerías de clientes más recientes

Instale las últimas Librerías de clientes para su lenguaje desde Librerías de clientes de MongoDB. Las librerías cliente conectan y transmiten consultas desde tu aplicación a tu base de datos. Utilizar las últimas Librerías de clientes permite acceder a las últimas funcionalidades de MongoDB.

Luego, en tu aplicación, importa la dependencia:

<dependencies>
    <dependency>
        <groupId>org.mongodb</groupId>
        <artifactId>mongodb-driver-sync</artifactId>
        <version>4.0.1</version>
    </dependency>
</dependencies>

dependencies {
  compile 'org.mongodb:mongodb-driver-sync:4.0.1'
}

// Latest 'mongodb' version installed with npm
const MongoClient = require('mongodb').MongoClient;

# Install the latest 'pymongo' version with pip and
# import MongoClient from the package to establish a connection.
from pymongo import MongoClient

Cadenas de conexión

Utiliza una cadena de conexión que especifique todos los nodos en tu clúster de Atlas para conectar tu aplicación a tu base de datos. Si tu clúster realiza una elección de set de réplicas y se elige un nuevo primario, una cadena de conexión que especifica todos los nodos de su clúster detecta el nuevo primario sin lógica de la aplicación.

Puede especificar todos los nodos de su clúster utilizando:

• el formato de cadena de conexión estándar, o

• el Formato de Conexión DNS lista de nodos iniciales (recomendado con Atlas).

La cadena de conexión también puede especificar opciones, especialmente retryWrites y writeConcern.

Atlas puede generar un Cadena de conexiónSRV para clústeres fragmentados que utilizan los balanceadores de carga de su servicio de punto final privado. Al usar una cadena de conexión optimizada, Atlas limita el número de conexiones por mongos entre su aplicación y su clúster fragmentado. La limitación de conexiones por mongos mejora el rendimiento durante picos de conexión.

Para obtener más información sobre las cadenas de conexión optimizadas para clústeres fragmentados detrás de un nodo privado, consulta ¿Cómo puedo optimizar el rendimiento de la conexión para clústeres fragmentados con nodos privados?

// Copy the connection string provided by Atlas
String uri = <your Atlas connection string>;
// Instantiate the MongoDB client with the URI
MongoClient client = MongoClients.create(uri);

// Copy the connection string provided by Atlas
const uri = <your Atlas connection string>;
// Instantiate the MongoDB client with the URI
const client = new MongoClient(uri);

# Copy the connection string provided by Atlas
uri = <your Atlas connection string>
# Pass your connection string URI to the MongoClient constructor
client = MongoClient(uri)

Escrituras y lecturas reintentables

Guardar y nivel de consistencia de lectura

Puede ajustar la consistencia y la disponibilidad de su aplicación mediante preocupaciones de escritura y lectura. Unas preocupaciones más estrictas implican que las operaciones de la base de datos esperan garantías de consistencia de datos más sólidas, mientras que una mayor flexibilidad en los requisitos de consistencia proporciona una mayor disponibilidad.

Error Handling

Los comandos no válidos, las interrupciones del servicio y los errores de red que no son gestionados por escrituras reintentables devuelven errores. Consulte la documentación de la API de su controlador para conocer los detalles del error.

Por ejemplo, si una aplicación intenta insertar un documento que contiene un valor _id que ya se utiliza en la colección de la base de datos, tu driver devuelve un error que incluye:

Unable to insert due to an error: com.mongodb.MongoWriteException:
E11000 duplicate key error collection: <db>.<collection> ...

{
    "name": : "MongoError",
    "message": "E11000 duplicate key error collection on: <db>.<collection> ... ",
    ...
}

pymongo.errors.DuplicateKeyError: E11000 duplicate key error collection: <db>.<collection> ...

Sin una gestión adecuada de errores, un error podría evitar que tu aplicación realice el procesamiento de solicitudes hasta que se reinicie.

Tu aplicación debe gestionar errores sin fallos ni efectos secundarios. En el ejemplo anterior de una aplicación que inserta un _id duplicado en una colección, esa aplicación podría gestionar los errores de la siguiente manera:

// Declare a logger instance from java.util.logging.Logger
private static final Logger LOGGER = ...
...
try {
    InsertOneResult result = collection.insertOne(new Document()
        .append("_id", 1)
        .append("body", "I'm a goofball trying to insert a duplicate _id"));
    // Everything is OK
    LOGGER.info("Inserted document id: " + result.getInsertedId());
// Refer to the API documentation for specific exceptions to catch
} catch (MongoException me) {
    // Report the error
    LOGGER.severe("Failed due to an error: " + me);
}

...
collection.insertOne({
    _id: 1,
    body: "I'm a goofball trying to insert a duplicate _id"
})
.then(result => {
    response.sendStatus(200) // send "OK" message to the client
},
err => {
    response.sendStatus(400); // send "Bad Request" message to the client
});

...
try:
    collection.insert_one({
        "_id": 1,
        "body": "I'm a goofball trying to insert a duplicate _id"
    })
    return {"message": "User successfully added!"}
except pymongo.errors.DuplicateKeyError as e:
    print ("The insert operation failed:", e)

La operación de inserción en este ejemplo arroja un error de "clave duplicada" la segunda vez que se invoca porque el campo _id debe ser único. Se detecta el error, se notifica al cliente y la aplicación sigue funcionando. Sin embargo, la operación de inserción falla y depende de ti decidir si mostrar un mensaje al usuario, reintentar la operación o hacer otra cosa.

Siempre se deben registrar los errores. Las estrategias comunes para el procesamiento adicional de errores incluyen:

• Devuelva el error al cliente con un mensaje de error. Esta es una buena estrategia cuando no puedes resolver el error y necesitas informar a un usuario de que no se puede completar una acción.

• Escribe en una base de datos de copias de seguridad. Esta es una buena estrategia cuando no puedes resolver el error pero no quieres arriesgarte a perder los datos de la solicitud.

• Reintente la operación más allá del único reintento predeterminado. Esta es una buena estrategia cuando puede resolver la causa de un error mediante programación y luego reintentarla.

Debe seleccionar las mejores estrategias para el contexto de su aplicación.

Prueba de conmutación por error

En el espíritu de pruebas de caos, Atlas realizará elecciones de set de réplicas automáticamente para tareas de mantenimiento periódicas y ciertos cambios de configuración.

Para comprobar si tu aplicación es resiliente a las elecciones del set de réplicas, prueba el proceso de failover simulando un evento de failover.