Cree 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 el uso de la memoria permita margen de maniobra. Si un nodo se queda sin memoria disponible, puede volverse vulnerable al "asesino de memoria insuficiente" de Linux, que termina el nodo.mongod proceso.

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.

Debe utilizar un filtro de rechazo de operaciones si desea:

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

• Priorice las cargas de trabajo más importantes durante los momentos de sobrecarga rechazando las consultas menos importantes.

• Dale tiempo al clúster para recuperarse si está cerca de la utilización máxima 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 puede proteger sus consultas de operaciones no indexadas con la defaultMaxTimeMS entrada del servidor al clúster. Si una operación excede este tiempo de espera, MongoDB la cancela para evitar que las consultas se ejecuten demasiado tiempo y ocupen recursos. Esto le permite:

• Transfiera la responsabilidad de establecer tiempos de espera de los equipos de aplicaciones individuales a los equipos centrados en la base de datos.

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

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

Si tiene consultas que requieren un tiempo de espera diferente, como consultas de análisis, puede anularlas configurando el tiempo de espera a nivel de operación con el método maxTimeMS.

Aísle el impacto de las colecciones ocupadas y 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:

• Optimice 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 su colección en las siguientes circunstancias:

• Si su fragmento principal experimenta una carga de trabajo significativa debido a la presencia de múltiples colecciones no fragmentadas de alto rendimiento.

• Se anticipa que una colección no fragmentada experimentará un crecimiento futuro, lo 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.

• Sus fragmentos tienen una cantidad de datos mayor que la proporcional debido a la cantidad de colecciones no fragmentadas que se encuentran en ellos.

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

Instalar las últimas bibliotecas de cliente

Instale las bibliotecas cliente más recientes para su lenguaje desde MongoDB Client Libraries. Estas bibliotecas conectan y retransmiten consultas desde su aplicación a su base de datos. Usar las bibliotecas cliente más recientes habilita las funciones más recientes de MongoDB.

Luego, en su aplicación, importe 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

Utilice una cadena de conexión que especifique todos los nodos de su clúster Atlas para conectar su aplicación a su base de datos. Si su clúster realiza una elección de conjunto de réplicas y se elige un nuevo nodo principal, una cadena de conexión que especifique todos los nodos del clúster detectará el nuevo nodo principal sin lógica de 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 optimizado 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

Preocupación por escribir y leer

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 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, su controlador 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 de errores adecuada, un error puede impedir que su aplicación procese solicitudes hasta que se reinicie.

Su aplicación debería gestionar los errores sin fallos ni efectos secundarios. En el ejemplo anterior, una aplicación que insertaba un duplicado _id en una colecció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 de este ejemplo genera un error de "clave duplicada" la segunda vez que se invoca, ya que el campo _id debe ser único. Se detecta el error, se notifica al cliente y la aplicación continúa ejecutándose. Sin embargo, la operación de inserción falla, y usted decide si mostrar un mensaje al usuario, reintentar la operación o realizar otra acción.

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

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

• Escribir en una base de datos de respaldo. Esta es una buena estrategia cuando no se puede resolver el error, pero no se quiere arriesgar 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

Con el espíritu de las pruebas de caos, Atlas realizará elecciones de conjuntos de réplicas automáticamente para el mantenimiento periódico y ciertos cambios de configuración.

Para comprobar si su aplicación es resistente a las elecciones de conjuntos de réplicas, pruebeel proceso de conmutación por error simulando un evento de conmutación por error.