MongoDB Sharding: samouczek krok po kroku z przykładem

W czym jest Sharding MongoDB?

Sharding to koncepcja w MongoDB, który dzieli duże zbiory danych na małe zbiory danych w wielu zbiorach MongoDB instancje.

Czasami dane wewnątrz MongoDB będzie tak ogromny, że zapytania dotyczące tak dużych zbiorów danych mogą powodować duże obciążenie procesora na serwerze. Aby zaradzić tej sytuacji, MongoDB ma koncepcję Shardingu, która polega w zasadzie na dzieleniu zestawów danych na wiele MongoDB instancje.

Kolekcja, która może być pokaźnych rozmiarów, jest w rzeczywistości podzielona na wiele kolekcji, zwanych „odłamkami”. Logicznie rzecz biorąc, wszystkie odłamki działają jak jedna kolekcja.

Zalety shardingu w MongoDB

Przed wdrożeniem klastra sharded warto zrozumieć, dlaczego zespoły decydują się na sharding. Główne korzyści to:

• Skalowalność pozioma: Dane są rozprowadzane na wielu serwerach, zamiast zmuszać pojedynczą maszynę do ciągłego rozrastania się.
• Większa przepustowość: Operacje odczytu i zapisu są wykonywane równolegle na wszystkich fragmentach, dzięki czemu klaster obsługuje więcej żądań na sekundę.
• Większa pojemność magazynowa: Połączony dysk składający się ze wszystkich fragmentów może pomieścić zbiory danych o wiele większe niż ten, który mógłby pomieścić jeden serwer.
• Duża dostępność: Gdy każdy fragment jest wdrażany jako zestaw replik, awaria pojedynczego węzła nie powoduje wyłączenia klastra.
• Zrównoważony ładunek: MongoDB Balancer automatycznie redystrybuuje fragmenty danych, aby zapobiec sytuacji, w której pojedynczy fragment stanie się punktem aktywnym.

Łącznie te zalety sprawiają, że sharding staje się standardowym podejściem do skalowania MongoDB poza zasięgiem pojedynczego serwera.

Jak wdrożyć sharding

Fragmenty są implementowane przy użyciu klastrów, które są niczym innym jak grupą MongoDB instancje.

Składniki Shardu obejmują:

1. Tak ciężko – To jest rzecz podstawowa i to jest nic innego jak MongoDB instancja, która przechowuje podzbiór danych. W środowiskach produkcyjnych wszystkie fragmenty muszą należeć do zestawów replik.
2. Serwer konfiguracyjny - Jest to MongoDB instancja przechowująca metadane dotyczące klastra, czyli zasadniczo informacje o różnych MongoDB instancje, które będą przechowywać dane fragmentu.
3. Router - Jest to MongoDB instancja, która zasadniczo odpowiada za przekierowywanie poleceń wysyłanych przez klienta do odpowiednich serwerów.

Dzielenie na kawałki krok po kroku Cluster Przykład

Krok 1) Utwórz oddzielną bazę danych dla serwera konfiguracji.

mkdir /data/configdb

Krok 2) Zacząć MongoDB instancja w trybie konfiguracji. Załóżmy, że mamy serwer o nazwie Serwer D, który będzie naszym serwerem konfiguracji. Aby skonfigurować serwer jako serwer konfiguracji, musimy uruchomić poniższe polecenie.

mongod --configdb ServerD:27019

Krok 3) Uruchom instancję mongos, określając serwer konfiguracji.

mongos --configdb ServerD:27019

Krok 4) Z powłoki mongo połącz się z instancją mongos.

mongo --host ServerD --port 27017

Krok 5) Jeśli masz serwer A i serwer B, które należy dodać do klastra, wydaj poniższe polecenia.

sh.addShard("ServerA:27017")
sh.addShard("ServerB:27017")

Krok 6) Włącz partycjonowanie bazy danych. Jeśli więc potrzebujemy partycjonować bazę danych Employeedb, wydaj poniższe polecenie.

sh.enableSharding("Employeedb")

Krok 7) Włącz sharding dla kolekcji. Jeśli więc chcemy shardować kolekcję Employee, wydaj poniższe polecenie.

sh.shardCollection("Employeedb.Employee", { "Employeeid": 1, "EmployeeName": 1 })

Jak wybrać klucz fragmentu w MongoDB

Kluczem fragmentu jest indeksowane pole lub zestaw pól, które MongoDB Służy do decydowania, który fragment przechowuje każdy dokument. Ponieważ klucz steruje dystrybucją danych, jego właściwy wybór jest najważniejszą decyzją we wdrożeniu partycjonowanym. Niewłaściwy klucz koncentruje dane i ruch na jednym fragmencie, niwecząc korzyści płynące z partycjonowania.

Silny klucz fragmentu ma na ogół następujące cechy:

• Wysoka kardynalność: Pole powinno mieć wiele możliwych wartości, aby dane mogły zostać podzielone na wiele drobnych fragmentów.
• Niska częstotliwość: Żadna pojedyncza wartość nie powinna dominować, w przeciwnym razie dokumenty dzielące tę wartość zostaną umieszczone w jednym fragmencie.
• Zmiana niemonotoniczna: Klucze, które ciągle się zwiększają, takie jak znaczniki czasu, wysyłają każdy nowy zapis do tego samego fragmentu, tworząc punkt aktywny.

MongoDB Obsługuje dwie strategie shardingu oparte na kluczu. Sharding zakresowy dzieli dane na ciągłe zakresy i odpowiada zapytaniom zakresowym, natomiast sharding haszowany stosuje funkcję haszującą, aby równomiernie rozłożyć zapisy na shardy. Zespoły często zaczynają od shardingu haszowanego, gdy zapisy są intensywne, i przechodzą na sharding zakresowy, gdy dominują odczyty oparte na zakresach. Niezależnie od wybranej strategii, przed zatwierdzeniem przetestuj klucz pod kątem realistycznych wzorców zapytań, ponieważ klucza shardingu nie można łatwo zmienić po załadowaniu danych.

Fragmentowanie kontra replikacja w MongoDB

Sharding i replikacja to funkcje uzupełniające się, ale odrębne. Poniższa tabela przedstawia różnice, aby ułatwić prawidłowe zastosowanie każdej z nich. W praktyce klastry produkcyjne korzystają z obu jednocześnie.

Krótko mówiąc, partycjonowanie zaspokaja potrzebę skalowalności, replikacja zaspokaja potrzebę dostępności, a solidne wdrożenie łączy w sobie oba te aspekty.

FAQ