Architektura MongoDB: struktura, terminologie, wymagania i korzyści
Opublikowany: 2020-12-28Spis treści
Przegląd
Nie ma wątpliwości, że internet jest kręgosłupem współczesnej gospodarki światowej. Dziś prawie 4,7 miliarda ludzi na świecie korzysta z wirtualnej platformy każdego dnia, korzystając z aplikacji internetowych do obsługi wiadomości, kupując ubrania, zamawiając jedzenie, słuchając muzyki, dojeżdżając do i z biura i nie tylko.
Przy tak dużej liczbie użytkowników, którzy codziennie dostarczają treści cyfrowe, nic dziwnego, że każdego dnia w cyberprzestrzeni generowane są ogromne ilości nieustrukturyzowanych danych. Dowiedz się więcej o przyszłym zakresie MongoDB.
To spowodowało pilną potrzebę stworzenia nowego paradygmatu bazy danych, który może przechowywać, obsługiwać i wspierać aplikacje „Big Data” (jak je nazywano) 24/7, bez awarii.
Wpisz NoSQL.
Powstanie baz danych NoSQL
NoSQL, powszechnie znany jako „Nie tylko SQL”, to alternatywa dla baz danych SQL, ograniczona przez ich stałe schematy tabel. Dzięki wysokiej elastyczności NoSQL eliminuje tę strukturalną wadę baz danych SQL i jest przystosowany do skalowania w poziomie. Bazy danych NoSQL zostały zaprojektowane w celu zwiększenia produktywności programistów, uzbrajając je w prosty i elegancki model danych do złożonych operacji przetwarzania danych i zarządzania.
Ogólnie rzecz biorąc, te modele przechowywania danych występują w 4 typach — dokument, klucz-wartość, szeroka kolumna i wykres. W tym blogu skupimy się na bazach danych dokumentów i architekturze MongoDB (wiodąca baza danych NoSQL)
Struktura MongoDB
Źródło: dokumentacja MongoDB
Architektura MongoDB jest zgodna z elastycznym modelem danych. W przeciwieństwie do RDBMS, który nakazuje deklarację schematu przed wstawieniem danych, MongoDB nie wymusza stałej struktury dokumentu.
Terminologie
Pola
Para klucz-wartość w dokumencie, jest odpowiednikiem kolumny w relacyjnych bazach danych
Dokument
Jest to odpowiednik rekordu w RDBMS
Kolekcje
Grupa dokumentów nazywana jest kolekcją. Jest to analogiczne do tabeli RDBMS
Różnice między architekturą RDBMS i MongoDB
Łączy
W RDBMS dane mogą być dystrybuowane do wielu tabel i łączone w celu uzyskania do nich dostępu w jednym widoku. Taka operacja JOIN nie jest możliwa w MongoDB. Zamiast tego wszystkie dane są przechowywane w jednym zbiorze, ale można je oddzielić za pomocą zagnieżdżonych lub osadzonych dokumentów
Normalizacja
RDBMS gwarantuje normalizację danych, aby uniknąć duplikatów i osieroconych rekordów. Elastyczność MongoDB eliminuje potrzebę normalizacji
Struktura
RDBS jest najczęściej używany w sektorze bankowym, gdzie dokładna struktura bazy danych jest znana a priori. MongoDB obsługuje ogromne ilości nieustrukturyzowanych danych i można ją rozszerzać w aplikacjach chmurowych, mobilnych, internetowych i Big Data.
Potrzeba i zalety architektury MongoDB
Architektura MongoDB może obsługiwać zmiany strukturalne w locie, co jest potrzebą godziny. Jest to idealne rozwiązanie w przypadku scenariuszy, w których nie masz wcześniej wglądu w strukturę bazy danych.
Oto niektóre z jego kluczowych zalet
Oparte na dokumencie
Może dynamicznie dostosowywać się do zmian przepływu danych, dostosowując się do zmieniających się wymagań biznesowych w czasie rzeczywistym
Zapytania ad hoc — potężny język zapytań, który może zwracać określone pola. Pozwala również na bardzo szczegółowe możliwości wyszukiwania. (pole mądry, zakres mądry, wspólne wyrażenia i więcej)
Indeksowanie
Możesz zindeksować dowolne pole w dokumencie, aby przyspieszyć proces wyszukiwania danych.
Zagłębmy się teraz głęboko w architekturę MongoDB .
Ale zanim to zrobimy, musimy zrozumieć twierdzenie CAP.
Twierdzenie CAP
CAP oznacza trifecta spójności, dostępności i tolerancji partycji.
Przyjrzyjmy się, co każdy termin oznacza w tym kontekście
Spójność
Jeśli zapisujesz dane do rozproszonej bazy danych, powinieneś mieć dostęp do tych samych danych z dowolnego węzła w systemie w dowolnym momencie. Chodzi o zachowanie integralności zapisanych danych.
Dostępność
Chodzi o zminimalizowanie przestojów systemu. Operacje odczytu/zapisu powinny być wykonywane na dowolnej maszynie w klastrze, bezbłędnie.
Tolerancja partycji lub tolerancja na uszkodzenia
wskazuje na zdolność systemu do płynnego funkcjonowania nawet w przypadku partycji sieciowej, tj. różne części klastra powinny być w stanie komunikować się ze sobą i skutecznie synchronizować.
Twierdzenie CAP stwierdza, że system rozproszony MUSI być odporny na partycje. Żadne partycje sieciowe nie mogą spowodować awarii całego systemu.
Innymi słowy, możesz zagwarantować tylko jeden parametr spośród „Spójności” i „Dostępności” w systemie rozproszonym, a drugim jest tolerancja partycji.
Daje to początek trójkątowi takiemu:
Źródło: Pedia Nauki o Danych
MongoDB zawsze wybiera spójność ponad dostępność , gdy w systemie jest partycja (CP). Blokuje wszystkie operacje zapisu, dopóki nie zapewni dokładnego wykonania tych zapisów.
Architektura MongoDB
MongoDB wykorzystuje architekturę single-master, co oznacza, że za wszystkie operacje zapisu po stronie klienta odpowiada główna maszyna. Wszystkie inne instancje dodane później do klastra stanowią węzły drugorzędne, które zwykle obsługują wszystkie operacje odczytu.
Są to w zasadzie kopie zapasowe serwera podstawowego jako zabezpieczenie przed awarią głównego serwera.
Wszystkie te serwery są pogrupowane w zestawy replik. Możesz mieć wiele zestawów replik, z których każdy ma swój własny serwer główny i dodatkowy.
Źródło: Dokumentacja MongoDB
W przypadku awarii głównego węzła system wybiera nowy główny ze wszystkich węzłów drugorzędnych. Ale dzieje się to arbitralnie, w zależności od tego, gdzie otrzymuje najszybsze odpowiedzi ping z całego systemu. Musisz mieć nieparzystą liczbę serwerów w klastrze (minimum 3), aby główny mógł zostać wybrany większością.
Jeśli nie chcesz wydawać pieniędzy na trzy serwery, możesz wyznaczyć węzeł „Arbiter”, którego jedynym zadaniem jest głosowanie w sprawie wyboru głównego.
Fragmentacja
Sharding w MongoDB umożliwia dystrybucję Big Data w kilku bazach danych.
Źródło: Dokumentacja MongoDB
Masz aplikację, która ma miliony użytkowników. Dzielenie na fragmenty umożliwia partycjonowanie tych użytkowników (na podstawie unikalnego indeksu, takiego jak identyfikator użytkownika) na różne zestawy replik. Używając procesu zwanego mongoS, serwer aplikacji komunikuje się z serwerami konfiguracyjnymi (dokładnie 3), aby zrozumieć, który „odłamek” zawiera dane, których szuka. MongoS uruchamia proces Load Balancer w tle, aby automatycznie rozłożyć obciążenie (w tym przypadku liczbę użytkowników) równomiernie między wszystkie fragmenty.
Wniosek
Jeśli chcesz dowiedzieć się więcej o MongoDB i operacjach na bazach danych, zapoznaj się z pomysłami na projekty MongoDB. Możesz zapoznać się z dyplomem PG z nauki o danych od upGrad. 12-miesięczny kurs przeznaczony dla pracujących profesjonalistów, otrzymasz kompleksowe doradztwo zawodowe i możliwości pracy, wraz z prestiżowym statusem absolwentów IIIT Bangalore.
Mamy nadzieję, że ten artykuł pomógł Ci zrozumieć, jak działa architektura MongoDB i jak działa system. Aby dowiedzieć się więcej, zajrzyj na nasze inne blogi.
Ucz się kursów rozwoju oprogramowania online z najlepszych światowych uniwersytetów. Zdobywaj programy Executive PG, Advanced Certificate Programs lub Masters Programs, aby przyspieszyć swoją karierę.
