Zastanawiam się, skąd pochodzi ten mem. Po pierwsze, nic naprawdę gwarantuje, że wszystko jest zapisywane na faktycznym dysku twardym ze względu na wszystkie warstwy pamięci podręcznej, a nawet tradycyjne RDBMS nie próbują zapisywać do plików przez cały czas, w przeciwnym razie nie byłyby tak szybkie, ale szczegóły znacznie się różnią (zobacz przykład adaptacyjne płukanie w InnoDB ).
Powinieneś zajmować się tylko pierwszą warstwą, która jest zasadniczo pytaniem, kiedy baza danych próbuje zapisać na dysku. Teraz jest pierwsza warstwa buforowania:Zamiast zapisywać do rzeczywistych tabel/kolekcji, wiele baz danych (w tym MongoDB) używa kronikowania:Zapisuje do pliku tylko do dołączania, który będzie regularnie scalany z rzeczywistymi plikami danych. Jeśli wszystko pójdzie na dół i jest w dzienniku, wszystko w porządku.
Teraz pytanie brzmi, czy chcesz pisać do dziennika i jak to zrobić. W MongoDB możesz to kontrolować za pomocą zastrzeżenia dotyczącego zapisu
, tzn. możesz kazać kodowi aplikacji czekać, aż MongoDB zapisze do dziennika konkretny zapis (lub wszystkie zapisy). W MongoDB oczekiwanie na zatwierdzenie dziennika trwa maksymalnie 10 ms przy domyślnej konfiguracji, jeśli dziennik i pliki danych znajdują się na różnych urządzeniach blokowych, 33 ms, jeśli znajdują się na tym samym urządzeniu blokowym. journalCommitInternval może być również modyfikowany w razie potrzeby.
Zebrałem kilka szczegółów na temat dziennika MongoDB w innej odpowiedzi .
Na marginesie, trwałość nie ma tak naprawdę wiele wspólnego z transakcjami. Transakcje zapewniają izolację i spójność, m.in. możesz zmienić wiele rzeczy za jednym razem, a czytelnicy mają gwarancję otrzymania nowego lub starego, ale nie jakiegoś stanu pośredniego. Innymi słowy, baza danych bezpieczna dla transakcji może być bazą danych w pamięci, która w ogóle nie zapisuje na dysku.
