Compile una aplicación resiliente con MongoDB Atlas

Gestión de memoria mejorada

Para ejecutar su aplicación de forma segura en producción, es importante asegurarse de que la utilización de memoria permita un margen de maniobra. Si un nodo se queda sin memoria disponible, puede verse afectado por el Linux Out of Memory Killer, que termina el proceso mongod.

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 producción si no se gestiona a tiempo.

MongoDB 8.0 te permite minimizar el impacto de estas operaciones utilizando filtros de rechazo de operaciones. Los filtros de rechazo de operación te permiten configurar MongoDB para rechazar las query hasta que vuelvas a habilitar las query con esa forma del query.

En otras palabras, una vez que identifiques una query lenta, no necesitas esperar a que los equipos de aplicaciones arreglen sus queries para contener el impacto de la query lenta. En su lugar, una vez que detectes un query de bajo rendimiento en tu perfilador del query, Panel de rendimiento en tiempo real o en los registros de query, puedes establecer un filtro de rechazo en esa forma del query. MongoDB luego impide que nuevas instancias de esa forma del query entrante se ejecuten. Una vez que corrijas la query, puedes volver a habilitar la forma del query.

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.

• Ten una última ronda de mitigación contra operaciones costosas que lleguen 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

Particionado permite escalar tu clúster horizontalmente. Con MongoDB, puedes fragmentar algunas colecciones, mientras permites que otras colecciones en el mismo clúster permanezcan sin fragmentar. Cuando se crea una nueva base de datos, la partición del clúster con la menor cantidad de datos se selecciona como partición primaria de esa base de datos por defecto. Todas las colecciones no particionadas de esa base de datos se encuentran en esa partición primaria por defecto. Esto puede causar un aumento del tráfico en la partición primaria a medida que aumenta la carga de trabajo, especialmente si el crecimiento de la carga de trabajo se centra en las colecciones no particionadas de la partición primaria.

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.

• Logra un mejor uso de 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ás ejecutando un diseño de implementación de una colección por clúster y deseas aislar a esos clientes según la prioridad o 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.

Puedes especificar todos los nodos de tu clúster usando cualquiera de las siguientes opciones:

• el formato estándar de cadena de conexión, 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 una cadena de conexión SRV optimizada para clústeres particionados utilizando los balanceadores de carga del servicio de nodos privados. Cuando se usa una cadena de conexión optimizada, Atlas limita el número de conexiones por mongos entre la aplicación y el clúster particionado. Las conexiones limitadas por mongos mejoran el rendimiento durante los picos en el número de conexiones.

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

Puedes ajustar la coherencia y la disponibilidad de tu aplicación utilizando niveles de confirmación de escritura (write concern) y niveles de consistencia de lectura. Preocupaciones más estrictas implican que las operaciones de la base de datos esperen garantías de coherencia de datos más fuertes, mientras que el alivio de los requisitos de coherencia proporciona una mayor disponibilidad.

Error Handling

Los comandos no válidos, las interrupciones de red y los errores de red que no se gestionan mediante escrituras reintentables generan errores. Consulte la documentación de la API de su controlador para obtener más información sobre los errores.

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.