Po opracowaniu aplikacji i modelu bazy danych (kiedy nadszedł czas na przeniesienie środowiska do środowiska produkcyjnego) należy najpierw zrobić kilka rzeczy. Często programiści nie biorą pod uwagę dodatkowych ważnych kroków MongoDB przed wdrożeniem bazy danych w środowisku produkcyjnym. W związku z tym w trybie produkcyjnym napotykają podstawowe niepowodzenia, które nie są prezentowane w trybie deweloperskim. Czasami może być za późno lub raczej wiele danych zostanie utraconych w przypadku katastrofy. Poza tym niektóre z omówionych tutaj kroków pozwolą ocenić stan bazy danych, a tym samym zaplanować niezbędne środki przed katastrofą.
Użyj aktualnej wersji i najnowszych sterowników
Ogólnie rzecz biorąc, najnowsze wersje w dowolnej technologii mają ulepszone funkcje w odniesieniu do podstawowej funkcjonalności niż ich poprzednicy. Najnowsze wersje MongoDB są bardziej niezawodne i ulepszone niż ich poprzednicy pod względem wydajności, skalowalności i pojemności pamięci. To samo dotyczy powiązanych sterowników, ponieważ są one opracowywane przez głównych inżynierów baz danych i są aktualizowane częściej niż sama baza danych.
Rozszerzenia natywne zainstalowane dla Twojego języka mogą z łatwością stworzyć platformę dla szybkich i standardowych procedur testowania, zatwierdzania i uaktualniania nowych sterowników. Istnieje również oprogramowanie motoryzacyjne, takie jak Ansible, Puppet, SaltStack i Chef, które można wykorzystać do łatwej aktualizacji MongoDB we wszystkich węzłach bez ponoszenia kosztów i czasu.
Rozważ również użycie silnika pamięci masowej WiredTiger, ponieważ jest on najbardziej rozwinięty z nowoczesnymi funkcjami, które odpowiadają współczesnym oczekiwaniom dotyczącym baz danych
Zasubskrybuj listę mailingową MongoDB, aby otrzymywać najnowsze informacje dotyczące zmian w nowych wersjach i sterownikach oraz poprawek błędów, dzięki czemu możesz być na bieżąco.
Użyj 64-bitowego systemu do uruchomienia MongoDB
W systemach 32-bitowych procesy MongoDB są ograniczone do około 2,5 GB danych, ponieważ baza danych wykorzystuje pliki mapowane w pamięci do zwiększania wydajności. Staje się to ograniczeniem dla procesów, które mogą przekroczyć granicę prowadzącą do załamania. Główny wpływ będzie następujący:w przypadku błędu nie będzie można ponownie uruchomić serwera do czasu usunięcia danych lub migracji bazy danych do wyższego systemu, takiego jak 64-bitowy, co oznacza dłuższy czas przestoju aplikacji.
Jeśli musisz nadal korzystać z systemu 32-bitowego, Twoje kodowanie musi być bardzo proste, aby zmniejszyć liczbę błędów i opóźnienia dla operacji przepustowości.
Jednak w przypadku złożoności kodu, takiej jak potok agregacji i dane geograficzne, zaleca się użycie systemu 64-bitowego.
Upewnij się, że dokumenty są ograniczone do rozmiaru 16 MB
Dokumenty MongoDB są ograniczone do rozmiaru 16 MB, ale nie musisz zbliżać się do tego limitu, ponieważ spowoduje to pewne pogorszenie wydajności. W praktyce dokumenty mają przeważnie rozmiar KB lub mniejszy. Rozmiar dokumentu zależy od strategii modelowania danych między osadzaniem a odwoływaniem. Osadzanie jest preferowane tam, gdzie nie przewiduje się znacznego wzrostu rozmiaru dokumentu. Na przykład, jeśli masz aplikację społecznościową, w której użytkownicy publikują i zawiera komentarze, najlepszą praktyką będzie posiadanie dwóch kolekcji, w których jeden przechowuje informacje o postach.
{
_id:1,
post: 'What is in your mind?',
datePosted: '12-06-2019',
postedBy:'xyz',
likes: 10,
comments: 30
}i drugi do przechowywania komentarzy do tego posta.
{
_id: ObjectId('2434k23k4'),
postId: 1,
dateCommented: '12-06-2019',
commentedBy:'ABCD',
comment: 'When will we get better again',
}Dzięki takim modelom danych komentarze będą przechowywane w innym zbiorze niż post. Zapobiega to rozrastaniu się dokumentu w kolekcji postów w przypadku, gdy będzie tak wiele komentarzy. Upewnij się, że unikasz wzorców aplikacji, które pozwoliłyby na nieograniczony wzrost dokumentów.
Upewnij się, że zestaw roboczy mieści się w pamięci
Baza danych może nie odczytać danych z pamięci wirtualnej (RAM), co prowadzi do błędów stron. Błędy stron zmuszają bazę danych do odczytywania danych z dysku fizycznego, co prowadzi do zwiększonego opóźnienia, a w konsekwencji opóźnienia w ogólnej wydajności aplikacji. Błędy stron zdarzają się z powodu pracy z dużym zestawem, który nie mieści się w pamięci. Może to być spowodowane tym, że niektóre dokumenty mają nieograniczony rozmiar lub słabą strategię dzielenia na fragmenty. Środki zaradcze w przypadku błędów strony:
- Zapewnienie, że dokumenty są ograniczone do rozmiaru 16 MB.
- Zapewnienie dobrej strategii shardingu poprzez wybranie optymalnego klucza shardingu, który ograniczy liczbę dokumentów, którym zostanie poddana operacja przepustowości.
- Zwiększ rozmiar instancji MongoDB, aby pomieścić więcej zestawów roboczych.
Upewnij się, że masz zestawy replik na miejscu
W świecie baz danych nie jest idealnym rozwiązaniem poleganie na jednej bazie danych, ponieważ może dojść do katastrofy. Poza tym można by się spodziewać wzrostu liczby użytkowników bazy danych, stąd konieczność zapewnienia wysokiej dostępności danych. Replikacja jest kluczowym podejściem do zapewnienia wysokiej dostępności w przypadku przełączenia awaryjnego. MongoDB ma możliwość obsługi danych geograficznie:co oznacza, że użytkownicy z różnych lokalizacji będą obsługiwani przez najbliższy host w chmurze, co jest jednym ze sposobów zmniejszenia opóźnień dla żądań.
W przypadku awarii węzła podstawowego, węzły drugorzędne mogą wybrać nowy, aby nadążyć za operacjami zapisu, zamiast przestoju aplikacji podczas przełączania awaryjnego. W rzeczywistości niektóre platformy hostingu w chmurze, które są dość rozważne w przypadku replikacji, nie obsługują niezreplikowanej bazy danych MongoDB w środowiskach produkcyjnych.
Włącz rejestrowanie
O ile kronikowanie pociąga za sobą pewne pogorszenie wydajności, jest to również ważne. Kronikowanie usprawnia operacje zapisu z wyprzedzeniem, co oznacza, że w przypadku awarii bazy danych podczas aktualizacji, aktualizacja zostałaby gdzieś zapisana, a po ponownym uruchomieniu proces może zostać zakończony. Kronikowanie może łatwo ułatwić odzyskiwanie po awarii, dlatego powinno być domyślnie włączone.
Upewnij się, że skonfigurujesz strategię tworzenia kopii zapasowych
Wiele firm nie kontynuuje działalności po utracie danych ze względu na brak lub słabe systemy tworzenia kopii zapasowych. Przed wdrożeniem bazy danych w środowisku produkcyjnym upewnij się, że użyłeś jednej z tych strategii tworzenia kopii zapasowych:
- Mongodump :optymalny dla małych wdrożeń i tworzenia kopii zapasowych filtrowanych według określonych potrzeb.
- Kopiowanie podstawy :optymalne dla dużych wdrożeń i wydajne podejście do wykonywania pełnych kopii zapasowych i ich przywracania.
- Usługa zarządzania MongoDB (MMS) :zapewnia ciągłą kopię zapasową online dla MongoDB jako w pełni zarządzaną usługę. Optymalne dla klastra podzielonego na fragmenty i zestawów replik.
Pliki kopii zapasowych również nie powinny być przechowywane u tego samego dostawcy hosta bazy danych. Backup Ninja to usługa, której można użyć do tego.
Bądź przygotowany na powolne zapytania
Prawie można zrealizować powolne zapytania w środowisku programistycznym z powodu małej ilości danych. Jednak może to nie mieć miejsca w przypadku produkcji, biorąc pod uwagę, że będziesz mieć wielu użytkowników lub będzie zaangażowanych wiele danych. Jeśli nie użyjesz indeksów lub użyjesz klucza indeksowania, który nie jest optymalny, mogą pojawić się powolne zapytania. Niemniej jednak powinniśmy znaleźć sposób, który pokaże przyczynę powolnych zapytań.
W związku z tym postanawiamy włączyć MongoDB Query Profiler. O ile może to prowadzić do obniżenia wydajności, profiler pomoże w ujawnieniu problemów z wydajnością. Przed wdrożeniem bazy danych musisz włączyć profiler dla kolekcji, które podejrzewasz, że mogą mieć powolne zapytania, zwłaszcza te, które obejmują dokumenty z dużą ilością osadzonych.
Połącz się z narzędziem monitorującym
Planowanie wydajności jest bardzo istotnym przedsięwzięciem w MongoDB. Będziesz także musiał znać stan zdrowia swojego db w dowolnym momencie. Dla wygody podłączenie bazy danych do narzędzia monitorującego pozwoli Ci zaoszczędzić trochę czasu na uświadomieniu sobie, co musisz z czasem poprawić w swojej bazie danych. Na przykład graficzna reprezentacja wskazująca niską wydajność procesora w wyniku zwiększonej liczby zapytań pokieruje Cię do dodania większej ilości zasobów sprzętowych do systemu.
Narzędzia monitorujące mają również system ostrzegania za pośrednictwem poczty lub krótkich wiadomości, które w wygodny sposób informują o niektórych problemach, zanim przerodzą się w katastrofę. Dlatego w środowisku produkcyjnym upewnij się, że Twoja baza danych jest podłączona do narzędzia monitorującego.
ClusterControl zapewnia bezpłatne monitorowanie MongoDB w wersji Community.
Wdrażaj środki bezpieczeństwa
Bezpieczeństwo bazy danych to kolejna ważna cecha, którą należy ściśle wziąć pod uwagę. Musisz chronić instalację MongoDB w środowisku produkcyjnym, zapewniając przestrzeganie niektórych przedprodukcyjnych list kontrolnych bezpieczeństwa. Niektóre z rozważań to:
- Konfigurowanie kontroli dostępu opartej na rolach
- Włączanie kontroli dostępu i wymuszania uwierzytelniania
- Szyfrowanie połączeń przychodzących i wychodzących (TLS/SSL)
- Ograniczanie ekspozycji w sieci
- Szyfrowanie i ochrona danych
- Miej plan śledzenia dostępu i zmian w konfiguracjach bazy danych
Unikaj zewnętrznych wstrzyknięć, uruchamiając MongoDB z bezpiecznymi opcjami konfiguracji. Na przykład wyłączenie skryptów po stronie serwera, jeśli nie są używane operacje po stronie serwera JavaScript, takie jak mapReduce i $where. Użyj walidatora JSON do zbierania danych za pośrednictwem niektórych modułów, takich jak mangusta, aby upewnić się, że wszystkie przechowywane dokumenty są w prawidłowym formacie BSON.
Zagadnienia dotyczące sprzętu i oprogramowania
MongoDB ma niewiele wymagań sprzętowych, ponieważ jest wyraźnie zaprojektowany z dużym uwzględnieniem niezbędnego standardowego sprzętu. Poniżej przedstawiono główne rozważania dotyczące sprzętu dla MongoDB, które należy wziąć pod uwagę przed wdrożeniem do produkcji.
- Przypisz odpowiednią pamięć RAM i procesor
- Użyj silnika pamięci masowej WiredTiger. Zaprojektowany do korzystania z pamięci podręcznej systemu plików i wewnętrznej pamięci podręcznej WiredTiger, dzięki czemu zwiększa wydajność. Na przykład podczas pracy w systemie z 4 GB pamięci RAM pamięć podręczna WiredTiger wykorzystuje 1,5 GB pamięci RAM ( 0,5 * (4 GB -1 GB) =1,5 GB), podczas gdy system z 1,2 GB pamięci podręcznej WiredTiger wykorzystuje tylko 256 MB.
- Sprzęt NUMA. Istnieje wiele problemów operacyjnych, w tym niska wydajność i wysokie wykorzystanie procesów systemowych, dlatego należy rozważyć skonfigurowanie zasad przeplatania pamięci.
- Dysk i system pamięci masowej:używaj dysków półprzewodnikowych (SSD):MongoDB wykazuje lepszy stosunek ceny do wydajności dzięki dyskowi SSD SATA
Wnioski
Bazy danych w produkcji są bardzo ważne dla zapewnienia sprawnego funkcjonowania firmy, dlatego należy je traktować z dużą dozą rozwagi. Należy określić procedury, które mogą pomóc zredukować błędy, a raczej zapewnić łatwy sposób ich wyszukiwania. Poza tym wskazane jest skonfigurowanie systemu ostrzegania, który pokaże stan bazy danych z czasem na planowanie pojemności i wykrywanie problemów, zanim załagodzą one katastrofę.
