Ich frage mich, woher dieses Meme kommt. Zuerst nichts garantiert wirklich, dass alles auf die eigentliche Festplatte geschrieben wird, wegen all der Caching-Schichten, und selbst traditionelle RDBMS versuchen nicht die ganze Zeit, in Dateien zu schreiben, sonst wären sie nicht so schnell, aber die Details variieren stark (siehe für Beispiel adaptives Leeren in InnoDB ).
Sie sollten sich nur mit der ersten Schicht befassen, die im Wesentlichen die Frage ist, wann die Datenbank versucht, auf die Festplatte zu schreiben. Jetzt gibt es die erste Caching-Schicht:Anstatt in die eigentlichen Tabellen/Sammlungen zu schreiben, verwenden viele DBs (einschließlich MongoDB) Journaling:Schreiben Sie in eine Append-Only-Datei, die regelmäßig wieder in die eigentlichen Datendateien zusammengeführt wird. Wenn alles untergeht und es im Tagebuch steht, geht es dir gut.
Nun stellt sich die Frage, ob Sie an das Tagebuch schreiben wollen und wie das geht. In MongoDB können Sie dies mit dem Write Concern
steuern , d. h. Sie können Ihren Anwendungscode warten lassen, bis MongoDB für einen bestimmten Schreibvorgang (oder für alle Schreibvorgänge) in das Journal geschrieben hat. In MongoDB dauert das Warten auf das Journal-Commit mit der Standardkonfiguration höchstens 10 ms, wenn sich das Journal und die Datendateien auf verschiedenen Blockgeräten befinden, 33 ms, wenn sie sich auf demselben Blockgerät befinden. Das journalCommitInternval kann bei Bedarf auch geändert werden.
Ich habe einige Details zum Journaling von MongoDB in einer anderen Antwort
Nebenbei bemerkt, Haltbarkeit hat nicht wirklich viel mit Transaktionen zu tun. Transaktionen sorgen für Isolierung und Konsistenz, z. Sie können mehrere Dinge auf einmal ändern und die Leser erhalten garantiert entweder den neuen oder den alten Zustand, aber keinen Zwischenzustand. Mit anderen Worten, eine transaktionssichere Datenbank könnte eine In-Memory-Datenbank sein, die überhaupt nicht auf die Festplatte schreibt.
