sql >> Base de Datos >  >> NoSQL >> MongoDB

Atomicidad, aislamiento y concurrencia en MongoDB

Las bases de datos relacionales más populares hoy en día son compatibles con  “ACID ” propiedades – Atomicidad, Consistencia, Aislamiento y Durabilidad. Los desarrolladores y DBA (Administradores de bases de datos) que trabajan con bases de datos relacionales tienen una buena comprensión del comportamiento de ACID. Sin embargo, cuando se trabaja con bases de datos NoSQL como la nube de MongoDB, existen algunas diferencias clave que es importante que comprenda. MongoDB ofrece una gran flexibilidad en almacenamiento, esquema y escalado, pero relaja algunas de las propiedades de ACID. Es esencial comprender las diferencias a medida que modela sus datos y ejecuta los comandos de MongoDB.

Atomicidad

Wikipedia define "Atomicidad"  de la siguiente manera:"En una transacción atómica , una serie de operaciones de base de datos todas ocurrir, o nada ocurre. Una garantía de atomicidad evita que las actualizaciones de la base de datos se produzcan solo parcialmente, lo que puede causar problemas mayores que el rechazo total de la serie. En otras palabras, atomicidad significa indivisibilidadirreductibilidad”.

Las operaciones de escritura de MongoDB son atómicas, solo al nivel de un solo documento. Si está modificando varios subdocumentos dentro de un documento, la operación sigue siendo atómica, pero si está modificando varios documentos, la operación no es atómica. Entonces, ¿cómo se logra un comportamiento atómico en varios documentos? Debe usar un patrón de "compromiso de dos fases" para lograr la atomicidad deseada. Aquí hay un gran ejemplo de la documentación de MongoDB sobre cómo implementar este patrón. El patrón de compromiso de dos fases no es trivial de implementar y hacerlo bien, así que asegúrese de que la atomicidad de escritura de múltiples documentos sea algo que desee buscar.

Aislamiento

Wikipedia define "aislamiento" de la siguiente manera:"En sistemas de bases de datos, aislamiento es una propiedad que define cómo/cuándo los cambios realizados por una operación se vuelven visibles para otras operaciones concurrentes”. Hay varias formas de lograr el aislamiento con sus operaciones de MongoDB, por ejemplo:

  1. Comando “buscarYModificarOperación()”

    Esta es una de las formas más sencillas de consultar y modificar documentos existentes. El comando puede devolver los valores anteriores de los documentos o los nuevos valores actualizados de los documentos. También puede ordenar los documentos coincidentes, insertar y seleccionar qué campos deben devolverse:

    db.collection.findAndModify( {
                                   query: <document>,
                                   sort: <document>,
                                   remove: <boolean>,
                                   update: <document>,
                                   new: <boolean>,
                                   fields: <document>,
                                   upsert: <boolean>
                               } );
  2. Patrón "Actualizar si es actual"

    Este patrón se especifica en la documentación de  MongoDB . Implica más trabajo manual pero te da más control.

  3. $Operador de aislamiento

    El operador $isolation ofrece una forma de aislar las escrituras en varios documentos. Sin embargo, el operador $isolation no proporciona una garantía de todo o nada; deberá usar algunas de las técnicas de atomicidad especificadas en la primera sección para lograrlo. Además, el operador $isolation no funciona para fragmentos. Este comando solía llamarse "$atomic"; ahora se le cambió el nombre correctamente a "$isolated".

Concurrencia

MongoDB utiliza bloqueos para evitar que varios clientes actualicen la misma información al mismo tiempo. MongoDB 2.2+ utiliza bloqueos de nivel de "base de datos". Por lo tanto, cuando una operación de escritura bloquea la base de datos, todas las demás operaciones de escritura en la misma base de datos (incluso si se trata de una colección separada) se bloquean esperando el bloqueo. MongoDB utiliza bloqueos "escritores codiciosos" que favorecen las escrituras sobre las lecturas. En 2.2+, ciertas operaciones de ejecución prolongada pueden generar sus bloqueos.

Seguridad de subprocesos

No todas las clases de cliente de MongoDB son seguras para subprocesos; consulte la documentación de su controlador específico para verificar si las clases que está utilizando son seguras para subprocesos. Por ejemplo, en el controlador de Java, la clase MongoClient es segura para subprocesos. Por lo tanto, puede usar una sola instancia de esta clase en todos sus subprocesos. Internamente, MongoClient usa un grupo de conexiones para administrar las conexiones al servidor MongoDB.

Como siempre, si tiene alguna pregunta, comuníquese con nosotros a [email protected].