En MongoDB, una operación de escritura es Atómico a nivel de un solo documento, incluso si la operación modifica varios valores. Cuando se ejecutan varios comandos de actualización en paralelo, cada comando individual garantiza que la condición de la consulta siga coincidiendo.
Para garantizar que los comandos de actualización concurrentes no entren en conflicto entre sí, puede especificar el valor actual esperado de un campo en el filtro de actualización.
Ejemplo
Considere una colección con este documento:
db.games.insertOne( { _id: 1, score: 80 } )
Estas operaciones de actualización ocurren simultáneamente:
// Update A db.games.updateOne( { score: 80 }, { $set: { score: 90 } } ) // Update B db.games.updateOne( { score: 80 }, { $set: { score: 100 } } )
Una operación de actualización establece el documento score campo a 90 o 100. Una vez completada esta actualización, la segunda operación de actualización ya no coincide con el predicado de consulta { score: 80 } y no se realiza.
Advertencia
En el caso de operaciones de actualización concurrentes, especificar un filtro en un campo que no se está actualizando puede llevar a resultados inesperados. Por ejemplo, considera si estas operaciones de actualización ocurren simultáneamente:
// Update A db.games.updateOne( { _id: 1 }, { $set: { score: 90 } } ) // Update B db.games.updateOne( { _id: 1 }, { $set: { score: 100 } } )
Después de completar una operación de actualización, la operación restante sigue coincidiendo con el predicado de query { _id: 1 }. Como resultado, ambas operaciones de actualización se llevan a cabo y el valor score almacenado refleja la segunda operación de actualización. Esto es problemático porque el cliente que emitió la primera actualización no recibe ninguna indicación de que la actualización fue sobrescrita y que el valor score es diferente de lo esperado.
Para evitar conflictos en las operaciones de escritura cuando el filtro de actualización está en un campo diferente al que se está actualizando, se debe usar el operador $inc.
Por ejemplo, considera si estas operaciones de actualización ocurren simultáneamente:
// Update A db.games.updateOne( { _id: 1 }, { $inc: { score: 10 } } ) // Update B db.games.updateOne( { _id: 1 }, { $inc: { score: 20 } } )
Después de completar una Operación de actualización, la Operación restante todavía coincide con el predicado de query { _id: 1 }. Sin embargo, debido a que las operaciones modifican el valor actual de score, no se sobrescriben entre sí. Ambas actualizaciones se reflejan y el score resultante es 110.
Tip
Store Unique Values
Para garantizar que un campo solo tenga valores únicos, puede crear un índice único. Los índices únicos evitan que las inserciones y actualizaciones creen datos duplicados. Puede crear un índice único en varios campos para garantizar que la combinación de valores de campo sea única. Para ver ejemplos, consulte Crear un índice único.
Transacciones multi-documento
Cuando una sola operación de guardado (p. ej. db.collection.updateMany()) modifica múltiples documentos; la modificación de cada documento es atómica, pero la operación en su conjunto no es atómica.
Al realizar Operaciones de guardado multidocumento, ya sea a través de una sola Operación de guardado o de múltiples Operaciones de guardado, otras Operaciones pueden intercalarse.
Para situaciones que requieren atomicidad de las lecturas y escrituras en varios documentos (en una sola colección o en varias), MongoDB admite transacciones distribuidas, incluidas las transacciones en sets de réplica y clústeres fragmentados.
Para obtener más información, consulta transacciones
Importante
En la mayoría de los casos, una transacción distribuida incurre en un costo de rendimiento mayor que las escrituras de documentos individuales, y la disponibilidad de transacciones distribuidas no debería ser un sustituto para un diseño de esquema efectivo. Para muchos casos, el modelo de datos desnormalizado (documento incrustado y matrices) seguirá siendo óptimo para tus datos y casos de uso. Es decir, en muchos casos, modelar tus datos de forma adecuada minimizará la necesidad de transacciones distribuidas.
Para consideraciones adicionales sobre el uso de transacciones (como el límite de tiempo de ejecución y el límite de tamaño del oplog), consulta también las consideraciones de producción.