Co to jest dzielenie MongoDB i najlepsze praktyki?

Jak skalować MongoDB? Jakie są najlepsze praktyki dzielenia?

Podczas gdy elastyczny schemat jest sposobem, w jaki większość ludzi zapoznaje się z MongoDB, jest to również jedna z najlepszych baz danych (być może nawet najlepszych, jeśli chodzi o codzienne aplikacje) do obsługi bardzo, bardzo dużych zestawów danych. Chociaż uzasadnienie tego argumentu wymaga samego artykułu (mam nadzieję, że kiedyś znajdę na to czas!), Ogólną ideą jest to, że rozwiązania oparte na SQL nie obsługują dzielenia na fragmenty i ciężko pracują.

Najlepsze, na co możesz liczyć, to stworzenie klastra (który nie jest tak naprawdę związany z shardowaniem) lub wybranie rozwiązania zarządzanego, takiego jak Amazon RDS lub Google Cloud SQL, które stają się zbyt drogie w miarę wzrostu danych.

W tym artykule przyjrzymy się jednej z podstawowych technik poziome skalowanie bazy danych: dzielenie na fragmenty, dla MongoDB i polecam kilka najlepszych praktyk w tym zakresie. Uważam jednak, że lepiej zacząć od podstaw dzielenia, ponieważ wiele osób, które chcą skalować MongoDB, może nie znać go zbyt dobrze.

Jeśli jednak masz świadomość dzielenia, możesz przejrzeć następną sekcję.

Podstawy dzielenia

Być może zauważyłeś użycie słowa „poziomo” w ostatnim akapicie poprzedniej sekcji. Nie ruszając się w inny, masowy objazd, chcę szybko podnieść ten punkt. Skalowanie uważa się za dwojakiego rodzaju: albo otrzymujesz mocniejszą maszynę o większej pojemności (pionowy) lub podłączysz kilka mniejszych komputerów i utworzysz kolekcję (poziomy).

Teraz, biorąc pod uwagę, że nawet najlepsze obecnie serwery nie mają więcej niż 256 GB pamięci RAM lub 16 TB dysku twardego, wkrótce uderzysz w ścianę z cegieł, próbując skalować w pionie (lub „skalować w górę”, zgodnie z terminologią). Możesz jednak połączyć tak wiele pojedynczych komputerów (przynajmniej teoretycznie) i łatwo ominąć to ograniczenie.

Oczywiście wyzwaniem jest teraz koordynacja wszystkich tych maszyn.

Odłamki bazy danych

Termin „sharding” ogólnie odnosi się do baz danych, przy założeniu, że pojedyncza maszyna nigdy nie wystarczy do przechowywania wszystkich danych. Podczas dzielenia baza danych jest „dzielona” na osobne części, które znajdują się na różnych komputerach. Prostym przykładem może być: załóżmy, że firma ma maszyny, które mogą przechowywać do 2 milionów danych klientów. Teraz firma osiąga punkt krytyczny i prawdopodobnie wkrótce przekroczy 2,5 miliona użytkowników. Postanawiają więc podzielić swoją bazę danych na dwie części:

I magicznie pojemność systemu jest teraz podwojona!

Cóż, gdyby tylko życie było takie proste! ��

Wyzwania w dzieleniu bazy danych

Gdy tylko trochę zastanowiłeś się nad odłamkami, niektóre niecne wyzwania skłaniają ich do brzydkiej głowy.

Brak kluczy podstawowych

Gdy tylko wyjdziesz z jednej bazy danych, klucze podstawowe tracą swoje znaczenie. Na przykład, jeśli twoje klucze podstawowe są ustawione na automatyczne zwiększanie i przeniesiesz połowę danych do innej bazy danych, będziesz mieć dwa różne elementy danych dla każdego klucza podstawowego.

Brak kluczy obcych

Ponieważ w bazach danych nie ma obsługi wskazującej na podmioty spoza bieżącej bazy danych (cóż, nawet inna baza danych na tym samym komputerze nie jest obsługiwana, więc zapomnij o bazie danych na innym komputerze), koncepcja kluczy obcych jest odrzucana, ponieważ dobrze. Nagle baza danych staje się „głupia”, a problemem jest integralność danych.

Dziwne błędy danych

Jeśli jedna maszyna zgaśnie, użytkownikowi końcowemu może zostać wyświetlony komunikat „Ups, coś się zepsuło!” strona, co bez wątpienia będzie denerwować, ale po pewnym czasie życie będzie na dobrej drodze.

Teraz zastanów się, co dzieje się w podzielonej bazie danych. Załóżmy, że fragmentowana baza danych w naszym wcześniejszym przykładzie jest bankową bazą danych, a jeden klient wysyła pieniądze do drugiego. Załóżmy również, że dane pierwszego klienta żyją w pierwszym fragmencie, podczas gdy dane drugiego klienta żyją w drugim fragmencie (widzisz, dokąd idę z tym ?!). Jeśli maszyna zawierająca drugi odłamek zawiedzie, czy możesz sobie wyobrazić, w jakim stanie będzie system? Gdzie trafią pieniądze z transakcji? Co zobaczy pierwszy użytkownik? Co zobaczy drugi użytkownik? Co oboje zobaczą, gdy odłamki wrócą do sieci?

Zarządzanie transakcjami

Rozważmy również niezwykle ważny przypadek zarządzania transakcjami. Tym razem załóżmy, że system działa w 100% dobrze. Teraz dwie osoby (A i B) dokonują płatności na rzecz trzeciej (C). Jest bardzo prawdopodobne, że obie transakcje jednocześnie odczytują saldo konta C, co powoduje zamieszanie:

  • Saldo konta C = 100 USD.
  • Transakcja A odczytuje saldo C: 100 USD.
  • Transakcja B odczytuje saldo C: 100 USD.
  • Transakcja A dodaje 50 USD i aktualizuje saldo: 100 USD + 50 = 150 USD.
  • Transakcja B dodaje 50 USD i aktualizuje saldo: 100 USD + 50 = 150 USD.

Cholera! 50 dolarów po prostu zniknęło w powietrzu!

Tradycyjne systemy SQL ratują Cię przed tym, zapewniając wbudowane zarządzanie transakcjami, ale gdy tylko wyjdziesz z jednego komputera, toast.

Chodzi o to, że w takich systemach łatwo jest natknąć się na problemy związane z uszkodzeniem danych, z których niemożliwe jest odzyskanie. Wyrywanie włosów też nie pomoże! ��

Sharding MongoDB

Dla architektów oprogramowania emocje związane z MongoDB nie polegały tak bardzo na elastycznym schemacie, jak na wbudowanym wsparciu dla shardingu. Po podłączeniu zaledwie kilku prostych reguł i maszyn, byłeś gotowy do uruchomienia odłamkowego klastra MongoDB w krótkim czasie.

Poniższy obraz pokazuje, jak to wygląda w typowym wdrożeniu aplikacji internetowej.

Źródło zdjęcia: mongodb.com

Najlepsze w dzieleniu odłamków MongoDB jest to, że nawet równoważenie odłamków jest automatyczne. To znaczy, jeśli masz pięć odłamków, a dwa z nich są prawie puste, możesz powiedzieć MongoDB, aby przywrócił równowagę w taki sposób, aby wszystkie odłamki były jednakowo pełne.

Jako programista lub administrator nie musisz się bardzo martwić, ponieważ MongoDB za kulisami wykonuje większość ciężkich zadań. To samo dotyczy częściowej awarii węzłów; jeśli masz poprawnie skonfigurowane i uruchomione zestawy replik w klastrze, częściowe awarie nie wpłyną na czas pracy systemu.

Całe wyjaśnienie byłoby raczej krótkie, więc zamknę tę sekcję, mówiąc, że MongoDB ma kilka wbudowanych narzędzi do dzielenia, replikacji i odzyskiwania, dzięki czemu programiści mogą łatwo tworzyć aplikacje na dużą skalę. Jeśli potrzebujesz bardziej kompleksowego przewodnika po możliwościach dzielenia MongoDB, skorzystaj z oficjalne dokumenty są tym miejscem.

Możesz być tym również zainteresowany kompletny przewodnik dla programistów.

Najlepsze praktyki dzielenia danych na MongoDB

Chociaż MongoDB „po prostu działa” po wyjęciu z pudełka, nie oznacza to, że możemy spocząć na laurach. Odłamki mogą spowodować lub zniweczyć Twój projekt na zawsze, w zależności od tego, jak dobrze lub źle zostało wykonane.

Co więcej, istnieje wiele drobnych szczegółów do wyjaśnienia, w przeciwnym razie nierzadko zdarza się upadek projektów. Chodzi o to, aby nie przestraszyć cię, ale podkreślić potrzebę planowania i zachować szczególną ostrożność nawet przy drobnych decyzjach.

Klucz Sharding nieuchronnie kontroluje sharding w MongoDB, więc idealnie jest, abyśmy rozpoczęli naszą ankietę od tego.

Wysoka liczność

Kardynalność oznacza wielkość wariancji. Na przykład zbiór ulubionego kraju liczącego 1 milion ludzi będzie miał małe różnice (jest tylko tyle krajów na świecie!), Podczas gdy zbiór ich adresów e-mail będzie miał (idealnie) wysoką liczność. Dlaczego to ma znaczenie? Załóżmy, że wybierasz naiwny schemat dzielący dane na podstawie imienia użytkownika.

Tutaj mamy dość prosty układ; przychodzący dokument jest skanowany w poszukiwaniu nazwy użytkownika i w zależności od tego, gdzie pierwsza litera znajduje się w alfabecie angielskim, ląduje w jednym z trzech odłamków. Podobnie wyszukiwanie dokumentu jest łatwe: na przykład szczegóły dotyczące „Piotra” będą na pewno w drugim fragmencie.

Wszystko brzmi dobrze, ale chodzi o to, że nie kontrolujemy nazw użytkowników dokumentów przychodzących. Co zrobić, jeśli przez większość czasu otrzymujemy tylko nazwy z zakresu od B do F? Jeśli tak, w shard1 będziemy mieć tak zwaną „dużą” część: większość danych systemowych będzie tam zatłoczona, co skutecznie zmieni konfigurację w pojedynczy system bazy danych.

The Cure?

Wybierz klucz o dużej liczności – na przykład adres e-mail użytkowników lub możesz nawet wybrać klucz fragmentu złożonego, który jest kombinacją wielu pól.

Monotonicznie się zmienia

Częstym błędem w dzieleniu na fragmenty MongoDB jest użycie klawiszy monotonicznie rosnących (lub automatycznego zwiększania, jeśli chcesz) jako klucza fragmentu niezależnego.

Zasadniczo używany jest klucz podstawowy dokumentu. Pomysł tutaj ma dobre znaczenie, ponieważ w miarę tworzenia nowych dokumentów będą one równomiernie wpadać w jeden z dostępnych odłamków. Niestety taka konfiguracja jest klasycznym błędem. Dzieje się tak, ponieważ jeśli klucz fragmentu zawsze rośnie, po pewnym momencie dane zaczną się gromadzić po stronie fragmentów o wysokiej wartości, powodując nierównowagę w systemie.

Źródło zdjęcia: mongodb.com

Jak widać na obrazku, po przekroczeniu zakresu 20 wszystkie dokumenty zaczynają się gromadzić w części C, powodując powstanie monolitu. Rozwiązaniem jest skorzystanie ze schematu klucza shardingu, który tworzy klucz shardingu, mieszając jedno z dostarczonych pól i używając go do określenia porcji.

Źródło zdjęcia: Mongodb.com

Hashed shard key wygląda następująco:

{
"_ID" :"6b85117af532da651cc912cd"
}

. . . i można je utworzyć w powłoce klienta Mongo za pomocą:

db.collection.createIndex ({_id: hashedValue})

Odłamek wcześnie

Jedną z najbardziej przydatnych rad bezpośrednio z okopów jest odłamek wcześnie, nawet jeśli skończysz z małą, dwuczęściową gromadą. Gdy dane przekroczą 500 GB lub coś takiego, sharding staje się nieporządnym procesem w MongoDB i powinieneś być gotowy na paskudne niespodzianki. Poza tym proces ponownego równoważenia zużywa bardzo duże pasmo sieciowe, co może dusić system, jeśli nie będziesz ostrożny.

Jednak nie wszyscy są odłamkami. Jako ciekawy przykład (nauka jest naprawdę w komentarzach), zobacz tę ładną Percona blog.

Uruchamianie wyważarki

Innym dobrym pomysłem jest monitorowanie wzorców ruchu i uruchamianie modułu równoważenia fragmentów tylko w okresach małego ruchu. Jak już wspomniałem, samo równoważenie wymaga znacznej przepustowości, co może szybko doprowadzić cały system do pełzania. Pamiętaj, że niezrównoważone odłamki nie są przyczyną natychmiastowej paniki. Po prostu pozwól, aby normalne użytkowanie utrzymywało się, poczekaj na okazje o małym natężeniu ruchu i pozwól, aby moduł równoważący wykonał resztę!

Oto, jak możesz to osiągnąć (zakładając, że masz mały ruch w godzinach od 3 rano do 5 rano):

użyj config
db.settings.update (
{ _ID: "stabilizator" },
{$ set: {activeWindow: {start: "03:00", zatrzymać : "05:00" }}},
{upsert: true}
)

Wniosek

Oddzielanie i skalowanie dowolnej bazy danych jest trudnym przedsięwzięciem, ale na szczęście MongoDB sprawia, że ​​jest łatwiejsza w zarządzaniu niż inne popularne bazy danych.

Istotnie był czas, kiedy MongoDB nie był właściwym wyborem dla żadnego projektu (dzięki kilku krytycznym problemom i domyślnym zachowaniom), ale te już dawno minęły. Oprócz dzielenia, ponownego równoważenia, automatycznej kompresji, rozproszonej blokady na poziomie zagregowanym i wielu takich funkcji, MongoDB ma wiele mil do przodu, jest dziś pierwszym wyborem architekta oprogramowania.

Mam nadzieję, że ten artykuł był w stanie rzucić nieco światła na to, czym jest dzielenie fragmentów w MongoDB i na co deweloper musi się zwrócić, wybierając skalowanie. Aby dowiedzieć się więcej, możesz to otrzymać kurs online do opanowania MongoDB.

TAGI:

  • Baza danych

Jeffrey Wilson Administrator
Sorry! The Author has not filled his profile.
follow me
    Комментариев нет, будьте первым кто его оставит

    Комментарии закрыты.