Jak MongoDB prace kroniki

Question

Oto mój widok, a ja nie jestem pewien, czy to dobrze, czy źle:

Dziennik dziennika jest „przerobić” log. Zapisuje modyfikację plików danych.

Na przykład, chcę zmienić wartość pola jednego rekordu z "a" na "b", wtedy mongodb znajdzie sposób na zmodyfikowanie pliku dbfile (zawiera całą przestrzeń nazw, dane, indeks itd.), następnie mongodb zapisz zmiany w dzienniku.

Po tym, mongodb wykonuje wszystkie prawdziwe modyfikacje pliku dbfile. Jeśli coś pójdzie nie tak, kiedy mongoDB uruchomi się ponownie, odczyta dziennik (jeśli istnieje). Następnie zmieni zmianę pliku dbfile, aby zestaw danych był spójny.

W dzienniku dane do zmiany nie są rejestrowane, ale zamiast tego należy zmienić plik dbfile.

Mam rację? gdzie mogę uzyskać więcej informacji na temat formatu czasopisma?

Answer 1

EDYCJA: mój oryginalny link do prezentacji 2011 na MongoSF przez Dwight jest już martwy, ale istnieje Bennyer z podobną zawartością 2012 presentation.

W przypadku, gdy przestanie działać w pewnym momencie, podam krótkie podsumowanie, jak działał dziennik w oryginalnym silniku pamięci masowej MMAP, ale należy zauważyć, że wraz z pojawieniem się modelu pluggable storage engine (MongoDB 3.0 i później), teraz zależy to całkowicie od mechanizmu przechowywania (i potencjalnie opcji), którego używasz - sprawdź więc.

Powrót do oryginalnego magazynu mechanizmu przechowywania danych (MMAP). Na bardzo podstawowym poziomie, dziennik zawiera szereg oczekujących operacji i wszystkie operacje są zapisywane w nim tak, jak to się dzieje - w zasadzie to tylko dodawanie sekwencyjnego zapisu na dysk.

Po zastosowaniu tych operacji i przepłukaniu ich na dysk, nie są już potrzebne w dzienniku i mogą zostać przeterminowane. W tym sensie dziennik zasadniczo działa jak bufor cykliczny dla operacji zapisu.

Wewnętrznie operacje w dzienniku są przechowywane w "grupach zatwierdzeń" - logicznej grupie operacji zapisu. Gdy operacja znajduje się w pełnej grupie zatwierdzania, można ją uznać za zsynchronizowaną z dyskiem jako częścią dziennika (i na przykład spełni wymagania dotyczące zapisu). Po nieczystym zamknięciu, mongod podejmie próbę zastosowania wszystkich kompletnych grup zatwierdzeń, które nie zostały wcześniej opróżnione na dysku, niekompletne grupy zatwierdzeń zostaną odrzucone.

Operacje w dzienniku nie są tym, co można zobaczyć w pliku oplog, są raczej prostszym zbiorem plików, przesunięciami (zasadniczo lokalizacjami dysku) i danymi do zapisania w lokalizacji. Pozwala to na wydajne odtwarzanie danych i kompaktowy format dziennika, ale sprawi, że zawartość będzie wyglądać jak bełkot (w przeciwieństwie do wspomnianego wcześniej oploga, który jest zasadniczo czytelny jako dokumenty JSON). Zasadniczo odpowiada na jedno z zadanych pytań - nie ma żadnej świadomości zawartości pliku bazy danych i zmian, które należy w nim wprowadzić, jest jeszcze prostsze - w zasadzie wie tylko, aby przejść do lokalizacji dysku X i zapisać dane Y, to jest to.

Zapisany, sekwencyjny charakter dziennika oznacza, że ​​pasuje on ładnie na obracający się dysk, a sekwencyjny wzorzec dostępu jest zwykle niezgodny z wzorcami dostępu do danych MMAP (choć niekoniecznie wzorce dostępu innych silników) . Dlatego czasami dobrym pomysłem jest umieszczenie dziennika na własnym dysku lub partycji w celu zmniejszenia rywalizacji o IO.