Ik vraag me af waar deze meme vandaan komt. Ten eerste, niets garandeert echt dat alles naar de eigenlijke HDD wordt geschreven vanwege alle caching-lagen, en zelfs traditionele RDBMS probeert niet altijd naar bestanden te schrijven, anders zouden ze niet zo snel zijn, maar de details variëren enorm (zie voor voorbeeld adaptieve flushing in InnoDB ).
U moet zich alleen bezighouden met de eerste laag, wat in wezen de vraag is wanneer de database naar schijf probeert te schrijven. Nu is er de eerste caching-laag:in plaats van naar de eigenlijke tabellen/verzamelingen te schrijven, gebruiken veel DB's (inclusief MongoDB) journaling:schrijf naar een bestand dat alleen kan worden toegevoegd en dat regelmatig weer wordt samengevoegd met de daadwerkelijke gegevensbestanden. Als er iets naar beneden gaat en het staat in het journaal, dan zit je goed.
Nu is de vraag of je naar het tijdschrift wilt schrijven en hoe je dat doet. In MongoDB kun je dit regelen met de write concern
, d.w.z. u kunt uw applicatiecode laten wachten totdat MongoDB naar het journaal heeft geschreven voor een specifieke schrijfbewerking (of voor alle schrijfbewerkingen). In MongoDB duurt het wachten op de journaalcommit maximaal 10 ms met standaardconfiguratie als de journaal- en gegevensbestanden zich op verschillende blokapparaten bevinden, 33 ms als ze zich op hetzelfde blokapparaat bevinden. De journalCommitInternval kan indien nodig ook worden gewijzigd.
Ik heb wat details verzameld over MongoDB's journalling in een ander antwoord .
Even terzijde:duurzaamheid heeft niet echt veel te maken met transacties. Transacties zorgen voor isolatie en consistentie, b.v. je kunt meerdere dingen in één keer veranderen en lezers krijgen gegarandeerd de nieuwe of de oude, maar niet een tussenstatus. Met andere woorden, een transactieveilige database kan een database in het geheugen zijn die helemaal niet naar de schijf schrijft.