Eu me pergunto de onde vem esse meme. Primeiro, nada realmente garante que qualquer coisa seja gravada no disco rígido real por causa de todas as camadas de cache, e mesmo RDBMS tradicionais não tentam gravar em arquivos o tempo todo, caso contrário, eles não seriam tão rápidos, mas os detalhes variam muito (consulte para exemplo limpeza adaptativa no InnoDB ).

Você deve se preocupar apenas com a primeira camada, que é essencialmente a questão quando o banco de dados tenta gravar no disco. Agora há a primeira camada de cache:em vez de gravar nas tabelas/coleções reais, muitos bancos de dados (incluindo o MongoDB) usam journaling:Gravar em um arquivo somente anexado que será regularmente mesclado de volta aos arquivos de dados reais. Em qualquer coisa vai para baixo e está no diário, você está bem.

Agora a questão é se você quer escrever para o diário e como fazê-lo. No MongoDB, você pode controlar isso usando o write concern , ou seja, você pode fazer com que o código do seu aplicativo espere até que o MongoDB grave no diário para uma gravação específica (ou para todas as gravações). No MongoDB, esperar pelo commit do journal leva no máximo 10ms com configuração padrão se o journal e os arquivos de dados estiverem em dispositivos de bloco diferentes, 33ms se estiverem no mesmo dispositivo de bloco. O journalCommitInternval também pode ser modificado, se necessário.

Reuni alguns detalhes sobre o journalling do MongoDB em outra resposta .

Como uma nota lateral, a durabilidade não tem muito a ver com transações. As transações fornecem isolamento e consistência, por exemplo. você pode alterar várias coisas de uma só vez e os leitores têm a garantia de obter o novo ou o antigo, mas não algum estado intermediário. Em outras palavras, um banco de dados seguro para transações pode ser um banco de dados na memória que não grava no disco.