Wdrożenia klastrów mają ogromne znaczenie dla zapewnienia wysokiej dostępności danych oraz ich ochrony. MongoDB poprawia to poprzez replikację i fragmentowanie, przy czym replikacja zapewnia skalowanie w pionie poprzez podnoszenie nadmiarowości, podczas gdy fragmentacja zwiększa skalowanie poziome.
Ogólnie rzecz biorąc, oba podejścia próbują rozłożyć obciążenie między członków, a tym samym zmniejszyć obciążenie, któremu może zostać poddany pojedynczy węzeł. Wydajność bazy danych może być wtedy postrzegana jako szybka w obsłudze użytkowników z operacjami przepustowości. Jednak bez architektury klastra prime może nie być tego samego poziomu wyników, nawet jeśli spróbujesz shardingu i replikacji.
Jeżeli liczba członków zestawu replik jest parzysta, wówczas członkom będzie trudno głosować i wybrać nowego głównego, jeśli istniejący w pewnym momencie ulegnie awarii. W tym blogu omówimy standardową architekturę wdrażania, której można użyć, ale może się ona różnić w zależności od wymagań aplikacji.
Strategie wdrażania MongoDB
Architektura zestawów replik jest bardzo determinująca pojemność i możliwości MongoDB.
Zestaw replik z trzema węzłami to standardowe wdrożenie klastra dla MongoDB w dowolnym środowisku produkcyjnym, ponieważ zapewnia nadmiarowość danych i odporność na błędy. Nadmiarowość jest ważna zwłaszcza w przypadku odzyskiwania bazy danych po awarii. Zestaw replik z trzema węzłami może stanowić podstawową architekturę wdrażania, ale może się on różnić w zależności od specyfikacji i wymagań aplikacji. Nie należy jednak czynić tego zbyt skomplikowanym, ponieważ może to prowadzić do większych problemów z konfiguracją.
Strategie fragmentowania MongoDB
Sharding zmniejsza obciążenie, nad którym ma pracować baza danych dla danego zapytania, zmniejszając liczbę dokumentów, z którymi trzeba się zmierzyć. W związku z tym usprawnia skalowanie poziome, umożliwiając rozbudowę bazy danych poza ograniczenia sprzętowe pojedynczego serwera. W zależności od zapotrzebowania na obciążenie węzły można dodawać lub usuwać z klastra, a MongoDB ponownie zrównoważy dane w optymalny sposób bez interwencji operacyjnej.
Niektóre z najlepszych strategii wdrażania klastra podzielonego na fragmenty obejmują:
Zapewnienie jednolitego rozmieszczenia kluczy fragmentów
Powodem shardingu jest skalowanie bazy danych w poziomie i zmniejszenie liczby operacji przepustowości, którym może zostać poddana pojedyncza instancja. Jeśli nie rozmieścisz kluczy odłamków równomiernie, możesz otrzymać niewielką liczbę odłamków. W przypadku kilku fragmentów operacje mogą być ograniczone przez pojemność pojedynczego fragmentu, co powoduje spowolnienie operacji odczytu i zapisu.
Części powinny być najpierw podzielone i rozprowadzone
Odłamki zawierają porcje danych, które są pogrupowane według pewnych kluczowych kryteriów odłamków. Podczas tworzenia nowej kolekcji podzielonej na fragmenty, przed załadowaniem jej danymi, należy utworzyć puste porcje i równomiernie rozmieścić je na wszystkich fragmentach. Kiedy będziesz zapełniać MongoDB danymi, łatwo będzie zrównoważyć obciążenie między zaangażowanymi fragmentami. Opcji numInitialChunks można użyć do zrobienia tego automatycznie, jeśli używasz fragmentowania opartego na hashowaniu. Jednak wartość całkowita powinna być mniejsza niż 8192 na fragment.
Liczba odłamków
Dwa shardy są często wymagane jako minimalna liczba do osiągnięcia znaczenia shardowania. Pojedynczy fragment jest przydatny tylko wtedy, gdy chcesz położyć fundament pod włączenie fragmentowania w przyszłości i nie ma potrzeby w czasie wdrażania.
Preferuj sharding w oparciu o zakres nad sharding w oparciu o hash
Sharding na podstawie zakresu jest korzystny, ponieważ zapewnia więcej fragmentów, dlatego operacje mogą być kierowane do najmniejszej niezbędnej liczby fragmentów, a częściej do pojedynczego fragmentu. Praktycznie może to być trudne, chyba że dobrze rozumiesz związane z nimi wzorce danych i zapytań. Fragmentacja haszowana poprawia równomierną dystrybucję operacji przepustowości kosztem zapewniania operacji opartych na gorszych zakresach.
Używaj zapytań typu Scatter-Gather tylko dla zapytań o dużej agregacji
Kwerendy, które nie mogą być kierowane na podstawie klucza fragmentu, powinny być rozgłaszane do wszystkich fragmentów w celu oceny, a ponieważ obejmują wiele fragmentów dla każdego żądania, nie skalują się liniowo, ponieważ dodawanych jest więcej fragmentów, co powoduje narzut co obniża wydajność bazy danych. Ta operacja nazywana jest zbieraniem rozproszonym i można jej uniknąć tylko wtedy, gdy w zapytaniu umieścisz klucz fragmentu.
Podejście to jest przydatne tylko w przypadku dużych zapytań agregujących, w których każde zapytanie może być uruchamiane równolegle na wszystkich fragmentach.
Strategie replikacji MongoDB
Replikacja poprawia skalowanie pionowe w MongoDB w taki sposób, że obciążenie jest rozdzielane między zaangażowanych członków. W środowisku produkcyjnym są to niektóre z rozważań, które należy wziąć pod uwagę, aby uzyskać optymalną architekturę klastra.
Liczba węzłów
Maksymalna liczba węzłów, które może mieć zestaw replik, to 50 z 7 członkami z prawem głosu. Każdy członek po 7-mej jest uważany za pozbawionego prawa głosu. Dobry klaster powinien zatem mieć 7 głosujących członków, aby ułatwić proces wyborczy.
Wyślij nieparzystą liczbę członków z prawem głosu, a jeśli masz tylko mniej niż 7, ale parzystą liczbę członków, będziesz musiał wyznaczyć arbitra jako innego członka z prawem głosu. Arbitrzy nie przechowują kopii danych, dlatego ich zarządzanie będzie wymagało mniej zasobów. Poza tym można ich podporządkować środowisku, którego nie można podporządkować innym członkom.
Rozważania dotyczące tolerancji błędów
Czasami niektórzy członkowie mogą stać się niedostępni w wyniku takich czynników, jak przerwy w dostawie prądu lub stany nieustalone i rozłączenia sieci. Liczba członków, którzy pozostają w zestawie i są w stanie wybrać prawybory, tworzy sytuację znaną jako tolerancja błędów. Jest to zatem różnica między całkowitą liczbą członków zestawu replik a większością głosujących członków potrzebną do wybrania podstawowego. Brak podstawowego oznacza, że operacje zapisu nie mogą być wykonane.
Poniższa tabela przedstawia przykładową relację między tymi trzema.
| Całkowita liczba członków zestawu replik | Większość wymagana do wyboru nowej prawybory | Tolerancja błędów |
| 3 | 2 | 1 |
| 4 | 3 | 1 |
| 5 | 3 | 2 |
| 6 | 4 | 2 |
| 7 | 5 | 2 |
Relacja nie jest tak bezpośrednia, ponieważ jeśli dodasz więcej elementów do zbioru, nie ma pewności, że tolerancja błędów wzrośnie, jak widać z tabeli. Dodatkowi członkowie zapewniają wsparcie dla dedykowanych funkcji, takich jak tworzenie kopii zapasowych i raportowanie.
Planowanie pojemności i równoważenie obciążenia dla dużych odczytów
Musisz mieć wolną pojemność dla swojego wdrożenia, dodając nowych członków, zanim bieżące zapotrzebowanie nasyci pojemność istniejącego zestawu.
W przypadku bardzo dużego ruchu związanego z odczytami należy dystrybuować odczyty przepustowości do elementów pomocniczych, a za każdym razem, gdy klaster się rozrasta, dodawać lub przenosić elementy do alternatywnych centrów danych, aby uzyskać nadmiarowość i zwiększyć dostępność danych.
Można również użyć operacji docelowych z zestawami znaczników, aby skierować operacje odczytu do określonych członków lub zmodyfikować kwestię zapisu, aby zażądać potwierdzenia od określonych członków.
Węzły powinny być rozmieszczone geograficznie
Centra danych mogą również ulec awarii z powodu jakiejś katastrofy . W związku z tym zaleca się trzymanie co najmniej jednego lub dwóch członków w oddzielnym centrum danych do celów ochrony danych. Jeśli to możliwe, użyj nieparzystej liczby centrów danych i wybierz dystrybucję, która maksymalizuje prawdopodobieństwo, że nawet w przypadku utraty centrum danych pozostali członkowie zestawu replik mogą stanowić większość lub przynajmniej dostarczyć kopię danych.
Zatrudnij rejestrowanie nieoczekiwanych awarii
Domyślnie jest to włączone w MongoDB. Powinieneś upewnić się, że ta opcja jest włączona, aby chronić utratę danych w przypadku przerw w działaniu usług, takich jak nagłe ponowne uruchomienie i awarie zasilania.
Wzorce wdrażania
Istnieją głównie dwa podejścia do wdrażania, to jest:
- Trzy zestawy replik członkowskich, które zapewniają minimalną zalecaną architekturę dla zestawu replik.
- Zestaw replik rozmieszczony w dwóch lub więcej centrach danych w celu ochrony przed awariami specyficznymi dla obiektu, takimi jak przerwy w dostawie prądu.
Wzorce zależą jednak od wymagań aplikacji, ale jeśli to możliwe, możesz połączyć cechy tych dwóch w swojej architekturze wdrażania.
Nazwy hostów i nazewnictwo zestawów replik
Użyj logicznej nazwy hosta DNS zamiast adresu IP podczas konfigurowania elementów zestawu replik lub elementów klastra podzielonego na fragmenty. Ma to na celu uniknięcie bólu związanego ze zmianami konfiguracji, które będziesz musiał wprowadzić w wyniku zmienionych adresów IP.
W przypadku nazewnictwa zestawów replik należy używać odrębnych nazw dla zestawów, ponieważ niektóre sterowniki grupują połączenia zestawu replik według nazwy zestawu replik.
Wnioski
Układ architektury zestawu replik określa pojemność i możliwości wdrożenia. Ochrona danych i wydajność systemu to podstawowe kwestie, które należy wziąć pod uwagę podczas konfigurowania architektury. Należy wziąć pod uwagę kluczowe czynniki, takie jak odporność na awarie, liczba elementów zestawu replik, optymalny klucz shardingu i wzorce wdrażania w celu zapewnienia wysokiej dostępności i ochrony danych. Geograficzne rozmieszczenie węzłów zestawu replik może rozwiązać wiele z tych czynników, zapewniając nadmiarowość i odporność na awarie w przypadku braku jednego z centrów danych.
