La durabilidad es la "D" en las propiedades "ACID" (A:atomicidad, C:consistencia, I:aislamiento), popularizadas por los sistemas tradicionales de administración de bases de datos relacionales (RDBMS). La durabilidad es la garantía de que los datos escritos se han guardado y sobrevivirán de forma permanente. Las bases de datos NoSQL como MongoDB brindan a los desarrolladores un control detallado sobre la durabilidad de sus llamadas de escritura. Esto permite a los desarrolladores elegir diferentes modelos de durabilidad, seguridad y rendimiento para diferentes clases de datos. Sin embargo, esto también impone al desarrollador la carga de discernir y comprender los matices de las diferentes opciones de seguridad de escritura. En esta publicación, veremos las diferentes opciones de seguridad de escritura proporcionadas en el controlador de Java.
En la jerga de MongoDB, esto se llama "Preocupación de escritura". Las inquietudes escritas varían de "débil" a "fuerte". Los problemas de escritura débil pueden conducir a un mayor rendimiento, pero brindan menos seguridad de datos y los problemas de escritura fuerte son viceversa.
El controlador Java le permite especificar sus opciones de seguridad de escritura usando varios constructores telescópicos. Aquí está el constructor con todas las opciones:
WriteConcern(int w, int wtimeout, boolean fsync, boolean j, boolean continueOnError)
Como puedes ver, este constructor tiene muchas opciones. Para que sea más fácil para los desarrolladores, se proporcionan "Etiquetas" para los valores de preocupación de escritura comunes:no reconocido, reconocido, registrado, sincronizado y replicado reconocido. Cada etiqueta se asigna a una determinada invocación del constructor anterior.
Modo MongoDB no reconocido
Este es el modo "dispara y olvida". El controlador MongoDB no intenta acusar recibo de las operaciones de escritura. Por ejemplo, si su servicio MongoDB está inactivo y está utilizando este modo, todos los errores se ignoran silenciosamente y sus datos se pierden. Obviamente, solo debe usar este modo para datos de bajo valor donde el rendimiento de escritura es más importante que la pérdida de una cierta cantidad de datos. Este modo se puede especificar de la siguiente manera:
new WriteConcern(0) / WriteConcern.UNACKNOWLEDGED
Modo MongoDB reconocido
Este es el modo de escritura predeterminado para MongoDB. En este modo, el controlador MongoDB intenta acusar recibo de las operaciones de escritura en el servidor, lo que permite que el controlador detecte cualquier error de red, errores de claves duplicadas, etc. Sin embargo, esto no garantiza que los datos se guarden en el disco. Si el servidor MongoDB falla después de reconocer la escritura, pero antes de enviarla al disco, los datos se perderán. Este modo se puede especificar de la siguiente manera:
new WriteConcern(1) / WriteConcern.ACKNOWLEDGED
Modo MongoDB con registro
En este modo, el servidor MongoDB reconoce la escritura solo después de enviar los datos al diario. Al usar este modo, incluso si el servidor falla al reiniciar el servidor, los datos se vuelven a aplicar desde el diario. Obviamente, el registro en diario debe estar habilitado para que esto funcione. Todos los sistemas de producción deben tener habilitado el registro en diario, y puede obtener más información sobre esto en nuestra publicación ¿Debería habilitar el registro en diario de MongoDB?
En un escenario de conjunto de réplicas, las inquietudes de escritura del diario solo se aplican al primario. De forma predeterminada, el diario se confirma en el disco cada 100 ms. Cuando especifica una escritura con la opción de diario, el diario se confirma en el disco en 30 ms. Por lo tanto, si especifica j:true para cada escritura, su rendimiento será de un máximo de 1000/30 =33,3 escrituras/seg. Si desea un mejor rendimiento, deberá procesar por lotes sus actualizaciones y configurar j:true para la última actualización del lote. Este modo se puede especificar de la siguiente manera:
WriteConcern( 1, 0, false, true ) / WriteConcern.JOURNALLED
Modo Fsynced MongoDB
En este modo, el servidor MongoDB reconoce la escritura solo después de que la escritura se escribe en el disco. Este modo se puede especificar de la siguiente manera:
new WriteConcern(true) / WriteConcern.FSYNCED
Modo MongoDB reconocido por réplica
Los modos de seguridad de escritura anteriores se aplican solo a un único servidor. Cuando ejecuta conjuntos de réplicas, tiene la opción de controlar cuántas réplicas necesita escribir su escritura antes de que se considere exitosa. Por ejemplo, con una preocupación de escritura de "w:2", la escritura debe escribirse en un primario y al menos en un secundario antes de que se considere exitosa. Esto reduce el rendimiento pero le brinda una mayor seguridad. Si no conoce la cantidad de réplicas de antemano, puede usar la etiqueta WriteConcern.MAJORITY para asegurarse de que los datos se guarden en la mayoría de las réplicas. Esta es la opción más segura en MongoDB. Si va a utilizar esta opción, también asegúrese de establecer el valor "wtimeout" para indicar cuánto tiempo debe esperar el comando antes de devolver el error:
new WriteConcern(2)/ REPLICA_ACKNOWLEDGED new Majority()/ WriteConcern.MAJORITY
Las siguientes etiquetas han quedado obsoletas (o planean estarlo):ERRORS_IGNORED, NORMAL, SAFE, FSYNC_SAFE, JOURNAL_SAFE, REPLICAS_SAFE. Utilice las opciones más nuevas en lugar de estas opciones. Como siempre, si tiene algún comentario o pregunta, comuníquese con nosotros a [email protected].
