Dzięki silnikowi pamięci masowej MMAPv1 aktualizacje w miejscu są często wyróżniane jako strategia optymalizacji, ponieważ indeksy dla dokumentu wskazują bezpośrednio na lokalizacje plików i przesunięcia. Przeniesienie dokumentu do nowej lokalizacji przechowywania (szczególnie, jeśli istnieje wiele wpisów indeksu do zaktualizowania) wiąże się z większym obciążeniem dla MMAPv1 niż aktualizacja w miejscu, która wymaga tylko aktualizacji zmienionych pól. Zobacz:Charakterystyka przechowywania nagrań w MMAPv1.
WiredTiger nie obsługuje aktualizacji w miejscu, ponieważ wewnętrznie używa MVCC (kontrola współbieżności Multiversion), która jest powszechnie używana przez systemy zarządzania bazami danych. Jest to znaczące ulepszenie techniczne w stosunku do uproszczonego widoku w MMAP i pozwala na tworzenie bardziej zaawansowanych funkcji, takich jak poziomy izolacji i transakcje. Indeksy WiredTiger mają poziom pośredni (odnoszą się do wewnętrznego identyfikatora rekordu zamiast lokalizacji pliku i przesunięcia), więc przenoszenie dokumentów na poziomie przechowywania nie jest znaczącym problemem.
Jednak ten artykuł mówi również, że „Chociaż [WiredTiger] nie pozwala na aktualizacje w miejscu, może nadal działać lepiej niż MMAP w przypadku wielu obciążeń”.
Oznacza to, że chociaż MMAPv1 może mieć bardziej wydajną ścieżkę aktualizacji w miejscu, WiredTiger ma inne zalety, takie jak kompresja i ulepszona kontrola współbieżności. Być może można by skonstruować obciążenie składające się tylko z lokalnych aktualizacji kilku dokumentów, które mogłyby działać lepiej w MMAPv1, ale rzeczywiste obciążenia są zwykle bardziej zróżnicowane. Jedynym sposobem potwierdzenia wpływu danego obciążenia byłoby przetestowanie w reprezentatywnym środowisku.
Jednak ogólny wybór między MMAPv1 a WiredTiger jest dyskusyjny, jeśli chcesz zaplanować przyszłość:WiredTiger jest domyślnym silnikiem pamięci masowej od MongoDB 3.2, a niektóre nowsze funkcje produktu nie są obsługiwane przez MMAPv1. Na przykład MMAPv1 nie obsługuje większościowego problemu odczytu, co z kolei oznacza, że nie można go używać z serwerami konfiguracji zestawu replik (wymagane do shardingu w MongoDB 3.4+) lub Change Streams (MongoDB 3.6+). MMAPv1 zostanie wycofany w następnym głównym wydaniu MongoDB (4.0) i jest obecnie planowany do usunięcia w MongoDB 4.2.
Jakie są dokładne implikacje, o których muszę wiedzieć, kiedy używam WiredTiger? Na przykład, czy rozmiar bazy danych szybko wzrośnie bez aktualizacji na miejscu?
Wyniki przechowywania zależą od kilku czynników, w tym projektu schematu, obciążenia, konfiguracji i wersji serwera MongoDB. MMAPv1 i WiredTiger używają różnych strategii alokacji rekordów, ale obie będą próbowały użyć wstępnie przydzielonej przestrzeni, która jest oznaczona jako wolna/wielokrotnego użytku. Ogólnie rzecz biorąc, WiredTiger jest bardziej wydajny pod względem wykorzystania przestrzeni dyskowej, a ponadto ma tę zaletę, że zapewnia kompresję danych i indeksów. MMAPv1 przydziela dodatkową przestrzeń dyskową, aby spróbować zoptymalizować aktualizacje na miejscu i uniknąć przenoszenia dokumentów, chociaż można wybrać strategię „bez wypełniania” dla kolekcji, w których obciążenie nie zmienia rozmiaru dokumentu w czasie.
Odkąd po raz pierwszy wprowadzono go w MongoDB 3.0, poczyniono znaczne inwestycje w ulepszanie i dostrajanie WiredTiger pod kątem różnych obciążeń, dlatego gorąco zachęcam do testowania z najnowszą serią wydań produkcyjnych, aby uzyskać jak najlepsze wyniki. Jeśli masz konkretne pytanie dotyczące projektowania schematu i wzrostu ilości pamięci masowej, sugeruję opublikowanie szczegółów na DBA StackExchange do dyskusji.
Dowiedziałem się również, że WiredTiger w MongoDB 3.6 dodał możliwość przechowywania delt zamiast ponownego pisania całego dokumentu (https://jira.mongodb.org/browse/DOCS-11416). Co to dokładnie oznacza?
Jest to szczegół implementacji, który poprawia wewnętrzne struktury danych WiredTiger w niektórych przypadkach użycia. W szczególności WiredTiger w MongoDB 3.6+ może wydajniej pracować z małymi zmianami w dużych dokumentach (w porównaniu do poprzednich wersji). Pamięć podręczna WiredTiger musi być w stanie zwracać wiele wersji dokumentów, o ile są one używane przez otwarte sesje wewnętrzne (MVCC, jak wspomniano wcześniej), więc w przypadku dużych dokumentów z małymi aktualizacjami bardziej wydajne może być przechowywanie listy delt. Jednakże, jeśli gromadzi się zbyt wiele delt (lub delty zmieniają większość pól w dokumencie), to podejście może być mniej wydajne niż utrzymywanie wielu kopii pełnego dokumentu.
Gdy dane są zapisywane na dysku za pośrednictwem punktu kontrolnego, nadal należy napisać pełną wersję dokumentu. Jeśli chcesz dowiedzieć się więcej o niektórych elementach wewnętrznych, możesz skorzystać z serii filmów MongoDB Path To Transactions, przedstawiających rozwój funkcji obsługujących transakcje wielodokumentowe w MongoDB 4.0.
Nie rozumiem również, że obecnie większość (jeśli nie wszystkie) dysków twardych ma sektor o rozmiarze 4096 bajtów, więc nie można zapisać na dysku twardym tylko 4 bajtów (na przykład), ale zamiast tego należy zapisać cały blok 4096 bajtów (więc najpierw przeczytaj, zaktualizuj 4 bajty, a następnie zapisz). Ponieważ większość dokumentów ma często mniej niż 4096 bajtów, oznacza to, że przepisanie całego dokumentu jest konieczne w każdym przypadku (nawet w przypadku MMAP). Co przegapiłem?
Nie zagłębiając się zbytnio w szczegóły implementacji i próbując wyjaśnić wszystkie ruchome części zaangażowane, zastanów się, jak różne podejścia mają zastosowanie do obciążeń, w których aktualizowanych jest wiele dokumentów (zamiast na poziomie pojedynczego dokumentu), a także wpływ na wykorzystanie pamięci (przed dokumenty są zapisywane na dysku). W zależności od czynników, takich jak rozmiar dokumentu i kompresja, pojedynczy blok we/wy może reprezentować od ułamka dokumentu (maksymalny rozmiar 16 MB) do wielu dokumentów.
W MongoDB ogólny przepływ polega na tym, że dokumenty są aktualizowane w widoku w pamięci (na przykład w pamięci podręcznej WiredTiger), a zmiany są utrwalane na dysku w formacie dziennika tylko z dołączaniem przed okresowym opróżnianiem do plików danych. Jeśli system operacyjny musi tylko zapisywać bloki danych, które uległy zmianie, dotknięcie mniejszej liczby bloków danych wymaga mniej ogólnych operacji we/wy.
