Mi chiedo da dove venga questo meme. Innanzitutto, niente garantisce davvero che qualsiasi cosa venga scritta sull'HDD effettivo a causa di tutti i livelli di memorizzazione nella cache, e anche i tradizionali RDBMS non tentano di scrivere sui file tutto il tempo, altrimenti non sarebbero così veloci, ma i dettagli variano notevolmente (vedi per esempio lavaggio adattivo in InnoDB ).
Dovresti occuparti solo del primo livello che è essenzialmente la domanda quando il database tenta di scrivere su disco. Ora c'è il primo livello di memorizzazione nella cache:invece di scrivere nelle tabelle/raccolte effettive, molti DB (incluso MongoDB) utilizzano il journaling:scrivi in un file di sola aggiunta che verrà regolarmente unito ai file di dati effettivi. In tutto va giù ed è nel diario, stai bene.
Ora la domanda è se vuoi scrivere sul diario e come farlo. In MongoDB, puoi controllarlo usando il scrivi preoccupazione
, ovvero puoi fare in modo che il codice dell'applicazione attenda fino a quando MongoDB non ha scritto nel journal per una scrittura specifica (o per tutte le scritture). In MongoDB, l'attesa del commit del journal richiede al massimo 10 ms con la configurazione predefinita se il journal e i file di dati si trovano su dispositivi a blocchi diversi, 33 ms se si trovano sullo stesso dispositivo a blocchi. Il journalCommitInternval può anche essere modificato se necessario.
Ho raccolto alcuni dettagli sul journaling di MongoDB in un'altra risposta .
Come nota a margine, la durata non ha molto a che fare con le transazioni. Le transazioni forniscono isolamento e coerenza, ad es. puoi cambiare più cose in una volta sola e ai lettori è garantito che otterranno il nuovo o il vecchio, ma non uno stato intermedio. In altre parole, un database sicuro per le transazioni potrebbe essere un database in memoria che non scrive affatto sul disco.
