Wdrożenie bazy danych w klastrze to jedno, ale sposób, w jaki utrzymujesz DBM w klastrze, może być dużym przedsięwzięciem dla spójnego udostępniania aplikacji. Należy często aktualizować stan bazy danych, a zwłaszcza najważniejsze metryki, aby uzyskać wskazówkę, co zaktualizować, a raczej zmienić, aby uniknąć ewentualnych wąskich gardeł, które mogą się pojawić.
Istnieje wiele kwestii dotyczących MongoDB, które należy wziąć pod uwagę, zwłaszcza fakt, że jego instalacja i uruchomienie są dość łatwe, szanse na zaniedbanie podstawowych praktyk zarządzania bazą danych są wysokie.
Często programiści nie biorą pod uwagę przyszłego rozwoju i zwiększonego wykorzystania bazy danych, co w konsekwencji powoduje awarię aplikacji lub danych z pewnymi problemami z integralnością oprócz niespójności.
W tym artykule omówimy niektóre z najlepszych praktyk, które należy zastosować w przypadku klastra MongoDB, aby zapewnić wydajną wydajność aplikacji. Niektóre z czynników, które należy wziąć pod uwagę, to...
- Aktualizacja do najnowszej wersji
- Odpowiedni silnik pamięci
- Alokacja zasobów sprzętowych
- Replikacja i sharding
- Nigdy nie zmieniaj pliku konfiguracyjnego serwera
- Dobra strategia bezpieczeństwa
Aktualizacja do najnowszej wersji
Pracowałem z MongoDB od wersji sprzed 3.2 i szczerze mówiąc, sprawy nie były wtedy łatwe. Dzięki świetnym rozwiązaniom, poprawionym błędom i nowo wprowadzonym funkcjom, radzę zawsze aktualizować bazę danych do najnowszej wersji. Na przykład wprowadzenie struktury agregacji miało lepszy wpływ na wydajność niż poleganie na istniejącej już koncepcji Map-Reduce. W najnowszej wersji 4.0 można teraz korzystać z funkcji transakcji wielodokumentowych, która generalnie poprawia przepustowość. Najnowsza wersja zawiera również kilka dodatkowych operatorów konwersji typów, takich jak $toInt, $toString, $trim i $toBool. Operatory te znacznie pomogą w walidacji danych, dzięki czemu stworzą pewne poczucie spójności danych. Podczas aktualizacji zapoznaj się z dokumentacją, aby uniknąć drobnych błędów, które mogą przerodzić się w błędy.
Wybierz odpowiedni silnik pamięci masowej
MongoDB obsługuje obecnie 3 silniki pamięci masowej, czyli:silniki pamięci masowej WiredTiger, In-Memory i MMAPv1. Każdy z tych silników pamięci masowej ma zalety i ograniczenia w stosunku do innych, ale Twój wybór będzie zależał od specyfikacji aplikacji i podstawowej funkcjonalności silnika. Osobiście jednak wolę silnik pamięci masowej WiredTiger i polecam go tym, którzy nie są pewni, którego użyć. Silnik pamięci masowej WiredTiger jest dobrze dostosowany do większości obciążeń, zapewnia model współbieżności na poziomie dokumentu, punkty kontrolne i kompresję.
Niektóre rozważania dotyczące wyboru silnika pamięci masowej zależą od tych aspektów:
- Transakcje i atomowość: dostarczenie danych podczas wstawiania lub aktualizacji, które jest dokonywane tylko wtedy, gdy wszystkie warunki i etapy w aplikacji zostały pomyślnie wykonane. Operacje są zatem połączone w niezmienną jednostkę. Dzięki temu transakcja wielodokumentowa może być obsługiwana, jak widać w najnowszej wersji MongoDB dla silnika pamięci masowej WiredTiger.
- Typ blokowania: jest to strategia kontroli dostępu lub aktualizacji informacji. W czasie trwania blokady żadna inna operacja nie może zmienić danych wybranego obiektu, dopóki bieżąca operacja nie zostanie wykonana. W związku z tym w tym momencie wpływa to na zapytania, dlatego ważne jest ich monitorowanie i zmniejszenie większości mechanizmów blokowania, zapewniając wybór najbardziej odpowiedniego silnika pamięci masowej dla swoich danych.
- Indeksowanie: Aparaty magazynu w MongoDB zapewniają różne strategie indeksowania w zależności od przechowywanych typów danych. Wydajność tej struktury danych powinna być dość przyjazna dla twojego obciążenia i można to określić, biorąc pod uwagę każdy dodatkowy indeks jako mający pewien narzut na wydajność. Struktury danych zoptymalizowane pod kątem zapisu mają mniejsze obciążenie dla każdego indeksu w środowisku aplikacji o dużej liczbie wstawiania niż struktury danych zoptymalizowane pod kątem zapisu. Będzie to poważny problem, zwłaszcza w przypadku dużej liczby indeksów i wyboru niewłaściwego silnika pamięci masowej. Dlatego wybór odpowiedniego silnika pamięci masowej może mieć ogromny wpływ.
Przydział zasobów sprzętowych
W miarę jak nowi użytkownicy logują się do Twojej aplikacji, baza danych rośnie z czasem i wprowadzane będą nowe fragmenty. Nie można jednak polegać na zasobach sprzętowych utworzonych na etapie wdrażania. Nastąpi odpowiedni wzrost obciążenia, a zatem będzie wymagało więcej zasobów przetwarzania, takich jak procesor i pamięć RAM, do obsługi dużych klastrów danych. Często odnosi się to do planowania pojemności w MongoDB. Najlepsze praktyki dotyczące planowania wydajności obejmują:
- Stale monitoruj swoją bazę danych i dostosowuj ją zgodnie z oczekiwaniami. Jak wspomniano wcześniej, wzrost liczby użytkowników spowoduje odtąd więcej zapytań z ustawionym zwiększonym obciążeniem, zwłaszcza jeśli używasz indeksów. Możesz zacząć odczuwać ten wpływ na koniec aplikacji, gdy zacznie ona rejestrować zmianę procentu zapisów w stosunku do odczytów w czasie. W związku z tym, aby rozwiązać ten problem, konieczne będzie ponowne skonfigurowanie konfiguracji sprzętowych. Użyj narzędzia mongoperf i MMS do wykrywania zmian w parametrach wydajności systemu.
- Udokumentuj wszystkie wymagania dotyczące wydajności z góry. Kiedy napotkasz ten sam problem, będziesz miał przynajmniej punkt odniesienia, który zaoszczędzi Ci trochę czasu. Twoje nagranie powinno obejmować rozmiar danych, które chcesz przechowywać, analizę zapytań pod kątem opóźnień oraz ilość danych, do których chcesz uzyskać dostęp w danym momencie. W środowisku produkcyjnym musisz określić, ile żądań będziesz obsłużyć na sekundę i na koniec, ile opóźnień będziesz tolerować.
- Przeprowadź weryfikację koncepcji. Wykonaj projekt schematu/indeksu i zrozum wzorce zapytań, a następnie doprecyzuj oszacowanie rozmiaru zestawu roboczego. Zapisz tę konfigurację jako punkt odniesienia do testowania z kolejnymi wersjami aplikacji.
- Wykonuj testy przy prawdziwym obciążeniu pracą. Po przeprowadzeniu etapu koncepcji dowodu, wdrażaj dopiero po przeprowadzeniu znacznych testów z danymi ze świata rzeczywistego i wymaganiami dotyczącymi wydajności.
Replikacja i sharding
Są to dwie główne koncepcje zapewnienia wysokiej dostępności danych i zwiększonej skalowalności poziomej odpowiednio w klastrze MongoDB.
Dzielenie na fragmenty zasadniczo dzieli dane na serwery na małe porcje zwane fragmentami. Równoważenie danych między fragmentami jest automatyczne, fragmenty można dodawać lub usuwać bez konieczności przełączania bazy danych w tryb offline.
Replikacja na drugim końcu utrzymuje wiele nadmiarowych kopii danych w celu zapewnienia wysokiej dostępności. Jest to funkcja wbudowana w MongoDB i działa w sieciach rozległych bez potrzeby stosowania wyspecjalizowanych sieci. W przypadku konfiguracji klastra zalecam posiadanie co najmniej 2+ mongos, 3 serwerów konfiguracyjnych, 1 sharda i zapewnienie łączności między maszynami zaangażowanymi w sharded klaster. Użyj w konfiguracji nazwy DNS, a nie adresów IP.
W środowiskach produkcyjnych użyj zestawu replik zawierającego co najmniej 3 elementy i pamiętaj o wypełnieniu większej liczby zmiennych konfiguracyjnych, takich jak rozmiar oploga.
Podczas uruchamiania instancji mongod dla członków używaj tego samego pliku klucza.
Niektóre z kwestii związanych z kluczem shardkey powinny obejmować:
- Klucz i wartość są niezmienne
- Zawsze rozważ użycie indeksów w kolekcji podzielonej na fragmenty
- Polecenie aktualizacji sterownika powinno zawierać klucz shard
- Unikalne ograniczenia, które mają być utrzymywane przez klucz fragmentu.
- Klucz fragmentu nie może zawierać specjalnych typów indeksów i nie może przekraczać 512 bajtów.
Nigdy nie zmieniaj pliku konfiguracyjnego serwera
Po wykonaniu pierwszego wdrożenia zaleca się, aby nie zmieniać wielu parametrów w pliku konfiguracyjnym, w przeciwnym razie możesz wpaść w kłopoty, zwłaszcza z shardami. Najsłabszym ogniwem z shardingiem są serwery konfiguracyjne. Oznacza to, że wszystkie instancje mongod muszą być uruchomione, aby sharding działał.
Dobra strategia bezpieczeństwa
MongoDB było w ostatnich latach podatne na ataki zewnętrzne, dlatego ważnym przedsięwzięciem dla Twojej bazy danych było posiadanie pewnych protokołów bezpieczeństwa. Oprócz uruchamiania procesów w różnych portach, należy zastosować przynajmniej jeden z 5 różnych sposobów zabezpieczania baz danych MongoDB. Możesz rozważyć platformy takie jak MongoDB Atlas, które domyślnie zabezpieczają bazy danych poprzez szyfrowanie danych zarówno w trakcie przesyłania, jak i w spoczynku. Możesz używać strategii takich jak TLS/SSL dla wszystkich połączeń przychodzących i wychodzących.
Wniosek
Kontrola klastra MongoDB nie jest łatwym zadaniem i wymaga wielu obejść. Bazy danych rosną w wyniku większej liczby użytkowników, a tym samym zwiększonego zestawu obciążeń. On ma zatem mandat, aby zapewnić, że wydajność DBM jest zgodna z tą zwiększoną liczbą użytkowników. Najlepsze praktyki wykraczają poza zwiększanie zasobów sprzętowych i stosowanie niektórych koncepcji MongoDB, takich jak sharding, replikacja i indeksowanie. Jednak wiele niedogodności, które mogą się pojawić, można dobrze rozwiązać, aktualizując swoją wersję MongoDB. Częściej najnowsze wersje mają naprawione błędy, zintegrowane prośby o nowe funkcje i prawie nie mają negatywnego wpływu na aktualizację, nawet przy głównych numerach wersji.
