Me pregunto de dónde viene este meme. Primero, nada realmente garantiza que cualquier cosa se escriba en el disco duro real debido a todas las capas de almacenamiento en caché, e incluso los RDBMS tradicionales no intentan escribir en los archivos todo el tiempo, de lo contrario no serían tan rápidos, pero los detalles varían mucho (ver para ejemplo vaciado adaptativo en InnoDB ).
Solo debe preocuparse por la primera capa, que es esencialmente la pregunta cuando la base de datos intenta escribir en el disco. Ahora está la primera capa de almacenamiento en caché:en lugar de escribir en las tablas/colecciones reales, muchas bases de datos (incluido MongoDB) usan el registro en diario:escriba en un archivo de solo anexar que se fusionará periódicamente en los archivos de datos reales. Si algo cae y está en el diario, estás bien.
Ahora la pregunta es si quieres escribir en el diario y cómo hacerlo. En MongoDB, puede controlar esto usando preocupación de escritura
, es decir, puede hacer que el código de su aplicación espere hasta que MongoDB haya escrito en el diario para una escritura específica (o para todas las escrituras). En MongoDB, la espera de la confirmación del diario toma como máximo 10 ms con la configuración predeterminada si los archivos de datos y el diario están en diferentes dispositivos de bloque, 33 ms si están en el mismo dispositivo de bloque. El journalCommitInternval también se puede modificar si es necesario.
Reuní algunos detalles sobre el diario de MongoDB en otra respuesta .
Como nota al margen, la durabilidad realmente no tiene mucho que ver con las transacciones. Las transacciones proporcionan aislamiento y coherencia, p. puede cambiar varias cosas de una sola vez y se garantiza que los lectores obtendrán el nuevo o el antiguo, pero no un estado intermedio. En otras palabras, una base de datos segura para transacciones podría ser una base de datos en memoria que no escribe nada en el disco.
