Osobiście wolę silnik pamięci masowej mmapv1 z trzech powodów.
Powód 1: Dojrzałość
To nie jest tak, że WiredTiger jest niedojrzały. Ale mmapv1 jest dobrze zrozumiany i przetestowany w bitwach w górę iw dół, tam iz powrotem, a także ponad i poza nią. WiredTiger miał ostatnio poważne problemy (więcej szczegółów na stronie http://jira.mongodb.com ) i nie jestem skłonny, aby moi klienci znaleźli kolejny trudny sposób.
Powód 2: Funkcje
Biorąc pod uwagę, WT ma kilka niesamowicie niesamowitych funkcji. Chodzi o to: nie widziałem nikogo, kto z nich skorzysta. Kompresja? Tak czy inaczej, poświęcasz dość ciężko, aby uzyskać wydajność za dość tanie miejsce na dysku. Brak problemu z migracją dokumentów podczas rozwijania dokumentów? Cóż, nadal mamy limit wielkości 16 MB i dodatkową złożoność osadzonych dokumentów, zwłaszcza gdy przesadzanie jest przesadzone.
Istnieją inne funkcje, ale w ogóle: Nie widzę zbyt dużo z nich korzystać już teraz .
Powód 3: Całkowity koszt posiadania
W przypadku nowych projektów WT może być w porządku, szczególnie od wersji 3.2, ponieważ poniższe zasady nie mają zastosowania.
Przeprowadzanie migracji danych jest drogie. Trzeba to zaplanować, plan musi zostać uzgodniony przez wszystkie zainteresowane strony, plany awaryjne muszą zostać stworzone i uzgodnione, migracja musi być przygotowana, wykonana i poddana przeglądowi. Teraz pomnóż czas potrzebny interesariuszom, którzy biorą udział w tym procesie, a koszty migracji danych gwałtownie wzrosną. Z drugiej strony zwrot z inwestycji wydaje się raczej niewielki. Możesz wziąć pod uwagę skalę, zamiast przeprowadzać migrację, jeśli weźmiesz pod uwagę te czynniki. Aby wywrzeć na tobie wrażenie: szacuję, że migracja jest odpowiednio planowana, wykonywana i sprawdzana w przybliżeniu na jeden „osobodni” na interesariusza. Przy kosztach 100 USD za godzinę na osobę i zaangażowanych tylko trzech ludzi (menedżer, DBA i programista), wynosi to 12 000 USD. Zauważ, że jest to ostrożny szacunek.
Wniosek
Wszystkie powyższe czynniki doprowadziły mnie do wniosku, że w ogóle nie używam WT. W tym momencie.
Aktualizacja
Ten post ma już kilka miesięcy, więc zasługuje na aktualizację
W dniu zapadalności
Moje oryginalne komentarze na temat dojrzałości są trochę przestarzałe. WiredTiger od jakiegoś czasu nie ma większych problemów i stał się domyślnym silnikiem pamięci masowej od wersji MongoDB 3.2
Funkcje
Moje oryginalne komentarze nadal mają pewną ważność, imho.
Kompresja
Jednak gdy nie masz większego wpływu na budżet lub, mówiąc bardziej ogólnie, wydajność nie jest najważniejsza, kompromis w zakresie wydajności jest raczej niewielki i zasadniczo zamieniasz niewielki wpływ na wydajność (w porównaniu do nieskompresowanego WT) na miejsce na dysku, wykorzystując to, co w innym przypadku byłoby bezczynne wokół: procesor.
Szyfrowanie
MongoDB 3.2 Enterprise wprowadził możliwość szyfrowania pamięci WiredTiger. W przypadku danych o zwiększonych potrzebach bezpieczeństwa jest to funkcja zabójcza i sprawia, że WT jest jedynym wybranym silnikiem pamięci, zarówno technicznie (MMAPv1 nie obsługuje szyfrowania), jak i koncepcyjnie. Pomijając oczywiście możliwość zaszyfrowania partycji dysku, chociaż w niektórych środowiskach możesz nie mieć takiej opcji.
Blokowanie na poziomie dokumentu
Muszę przyznać, że zasadniczo pominąłem tę cechę WT w powyższej analizie, głównie dlatego, że nie dotyczyła ona mnie ani moich klientów, kiedy napisałem oryginalną odpowiedź.
W zależności od konfiguracji, zwłaszcza gdy masz wielu współbieżnych klientów piszących, ta funkcja może znacznie zwiększyć wydajność.
Całkowity koszt posiadania
Przeprowadzanie migracji jest wciąż drogie. Biorąc jednak pod uwagę zmiany dojrzałości i zmieniony widok funkcji, migracja może być warta inwestycji, jeśli:
- Potrzebujesz szyfrowania (tylko wersja Enterprise!)
- Wydajność nie jest Twoim absolutnym priorytetem i możesz zaoszczędzić pieniądze na dłuższą metę (zachowawczo) używając kompresji
- Wiele procesów pisze jednocześnie, ponieważ wzrost wydajności może zaoszczędzić na skalowaniu w pionie lub w poziomie.
Zaktualizowany wniosek
Do nowych projektów używam teraz WiredTiger. Ponieważ migracja ze skompresowanego do nieskompresowanego magazynu WiredTiger jest raczej łatwa, zwykle zaczynam od kompresji, aby zwiększyć wykorzystanie procesora („uzyskaj więcej za grosze”). Jeśli kompresja ma zauważalny wpływ na wydajność lub UX, migruję do nieskompresowanego WiredTiger.
W przypadku projektów z wieloma równoległymi autorami odpowiedź na pytanie, czy migrować, czy nie, prawie zawsze brzmi „Tak” - chyba że budżet projektu zabrania inwestycji. W dłuższej perspektywie wzrost wydajności powinien się zwrócić, jeśli wdrożenie byłoby w rozsądny sposób zaplanowane. Jednak trzeba poświęcić trochę czasu na opracowanie obliczeń, ponieważ w niektórych przypadkach sterownik musi zostać zaktualizowany i mogą wystąpić problemy, które należy rozwiązać.
W przypadku projektów, które są obciążone budżetem i na razie nie mogą sobie pozwolić na więcej miejsca na dysku, migracja do skompresowanego WiredTiger może być opcją, ale kompresja powoduje pewne obciążenie procesora, co jest niespotykane w przypadku MMAPv1. Ponadto koszty migracji mogą być zbyt wysokie w przypadku takiego projektu.
