Arhitectura MongoDB: structură, terminologii, cerințe și beneficii
Publicat: 2020-12-28Cuprins
Prezentare generală
Nu există nicio îndoială că internetul este coloana vertebrală a economiei mondiale moderne. Astăzi, aproape 4,7 miliarde de oameni din lume folosesc platforma virtuală în fiecare zi, folosind aplicații bazate pe internet pentru știri, cumpără haine, comandă mâncare, ascultă muzică, fac naveta la și de la birou și multe altele.
Cu un număr atât de mare de utilizatori care fac contribuții digitale zilnic, nu este de mirare că cantități uriașe de date nestructurate sunt generate în spațiul cibernetic în fiecare zi. Aflați mai multe despre domeniul viitor MongoDB.
Acest lucru a dat naștere unei nevoi urgente pentru o nouă paradigmă de baze de date care să poată stoca, servi și suporta aplicații „Big Data” (așa cum au ajuns să fie cunoscute) 24/7, fără a se defecta.
Introduceți NoSQL.
Ascensiunea bazelor de date NoSQL
NoSQL, cunoscut sub numele de „Nu numai SQL”, este o alternativă la bazele de date SQL limitate de schemele lor de tabel fixe. Fiind extrem de flexibil, NoSQL depășește acest dezavantaj structural al bazelor de date SQL și este echipat pentru scalare orizontală. Bazele de date NoSQL au fost concepute pentru a spori productivitatea dezvoltatorilor, armându-i cu un model de date simplu și elegant pentru operațiuni complexe de procesare și gestionare a datelor.
În linii mari, aceste modele de stocare a datelor au venit în 4 tipuri - Document, valoare-cheie, coloană largă și grafic. Ne vom concentra pe bazele de date de documente și arhitectura MongoDB în acest blog (baza de date lider NoSQL)
Structura MongoDB
Sursa: documentația MongoDB
Arhitectura MongoDB urmează un model de date flexibil. Spre deosebire de RDBMS, care impune o declarație de schemă înainte de a introduce date, MongoDB nu impune o structură fixă a documentului.
Terminologii
Câmpuri
O pereche cheie-valoare dintr-un document, este omologul unei coloane din bazele de date relaționale
Document
Acesta este echivalentul unei înregistrări în RDBMS
Colecții
Un grup de documente se numește colecție. Acesta este analog cu un tabel RDBMS
Diferențele dintre RDBMS și arhitectura MongoDB
Se alătură
În RDBMS, datele pot fi distribuite între mai multe tabele și unite pentru a le accesa într-o singură vizualizare. O astfel de operație JOIN nu este posibilă în MongoDB. În schimb, toate datele sunt stocate într-o singură colecție, dar pot fi separate prin imbricare sau documente încorporate
Normalizare
RDBMS garantează normalizarea datelor pentru a evita duplicatele și înregistrările orfane. Flexibilitatea MongoDB elimină nevoia de normalizare
Structura
RDBS este folosit mai ales în sectorul bancar, unde structura exactă a bazei de date este cunoscută a priori. MongoDB acceptă volume uriașe de date nestructurate și este extensibil în aplicații cloud, mobile, web și Big Data.
Nevoia și beneficiile arhitecturii MongoDB
Arhitectura MongoDB poate face față schimbărilor structurale din mers, ceea ce este nevoia momentului. Acest lucru este perfect pentru scenariile în care nu aveți vizibilitate în prealabil asupra structurii bazei de date.
Următoarele sunt câteva dintre beneficiile sale cheie
Bazat pe documente
Poate găzdui schimbările fluxului de date în mod dinamic, adaptându-se la cerințele de afaceri în schimbare în timp real
Interogări ad-hoc – limbaj de interogare puternic care poate returna câmpuri specificate. De asemenea, permite capabilități de căutare foarte granulare. (câmp, gamă, expresii comune și multe altele)
Indexarea
Puteți indexa orice câmp dintr-un document pentru a accelera procesul de recuperare a datelor.
Să facem acum o scufundare profundă în arhitectura MongoDB .
Dar înainte de a face asta, trebuie să înțelegem teorema CAP.
Teorema CAP
CAP denotă trifecta de consistență, disponibilitate și toleranță de partiție.
Să vedem ce înseamnă fiecare termen în acest context
Consecvență
Dacă scrieți date într-o bază de date distribuită, ar trebui să puteți accesa aceleași date de la orice nod din sistem în orice moment. Este vorba despre păstrarea integrității datelor scrise.
Disponibilitate
Este vorba despre minimizarea timpului de nefuncționare al unui sistem. Operațiunile de citire/scriere ar trebui să aibă loc pe orice mașină din cluster, fără greș.
Toleranță de partiție sau toleranță la erori
indică capacitatea unui sistem de a continua să funcționeze fără probleme chiar și în cazul unei partiții de rețea, adică diferite părți ale cluster-ului ar trebui să poată vorbi între ele și să se sincronizeze eficient.
Teorema CAP afirmă că un sistem distribuit TREBUIE să fie tolerant la partiții. Orice partiție de rețea nu poate duce la prăbușirea întregului sistem.
Cu alte cuvinte, puteți garanta doar un parametru din „Consistență” și „Disponibilitate” într-un sistem distribuit, celălalt fiind Toleranța partiției.
Acest lucru dă naștere unui triunghi ca acesta:
Sursa: Data Science Pedia
MongoDB alege întotdeauna consecvența asupra disponibilității ori de câte ori există o partiție în sistem (CP). Acesta blochează toate operațiunile de scriere până când poate asigura execuția corectă a acelor scrieri.
Arhitectura MongoDB
MongoDB folosește arhitectura single-master, ceea ce înseamnă că există o mașină principală care se ocupă de toate operațiunile de scriere pe partea clientului. Toate celelalte instanțe pe care le adăugați ulterior în cluster constituie nodurile secundare, care se ocupă de obicei de toate operațiunile de citire.
Acestea sunt, practic, copii de rezervă ale serverului primar ca un sistem de siguranță împotriva prăbușirii primare.
Toate aceste servere sunt grupate în seturi de replicare. Puteți avea mai multe seturi de replicare, fiecare având propriile servere primare și secundare.
Sursa: Documentația MongoDB
În cazul în care primarul scade, sistemul alege un nou primar din toate nodurile secundare. Dar acest lucru se întâmplă în mod arbitrar, în funcție de locul în care primește cele mai rapide răspunsuri ping din toate sistemele. Trebuie să aveți un număr impar de servere în cluster (minimum 3) pentru ca un primar să poată fi ales cu majoritate.
Dacă nu doriți să cheltuiți bani pe trei servere, puteți numi un nod „Arbitru” a cărui singură sarcină este să voteze pentru alegerea primarului.
Sharding
Sharding în MongoDB vă permite să vă distribuiți Big Data în mai multe baze de date.
Sursa: Documentația MongoDB
Aveți o aplicație cu milioane de utilizatori. Sharding vă permite să împărțiți acești utilizatori (pe baza unui index unic, cum ar fi un ID de utilizator) în seturi de replici diferite. Folosind un proces numit mongoS, Serverul de aplicații vorbește cu serverele de configurare (mai exact 3) pentru a înțelege ce „Shard” conține datele pe care le caută. mongoS rulează un proces Load Balancer în fundal pentru a distribui automat încărcarea (în acest caz, numărul de utilizatori) uniform între toate fragmentele.
Concluzie
Dacă doriți să aflați mai multe despre MongoDB și operațiunile bazei de date, consultați ideile de proiecte MongoDB. Puteți explora Diploma PG în Știința datelor de la upGrad. Un curs de 12 luni conceput pentru profesioniști care lucrează, beneficiezi de consiliere cuprinzătoare în carieră și oportunități de angajare, împreună cu prestigiosul IIIT Bangalore Alumni Status.
Sperăm că acest articol v-a ajutat să înțelegeți cum funcționează arhitectura MongoDB și cum funcționează sistemul. Pentru a afla mai multe, vă rugăm să vă uitați la celelalte bloguri ale noastre.
Învață cursuri de dezvoltare software online de la cele mai bune universități din lume. Câștigați programe Executive PG, programe avansate de certificat sau programe de master pentru a vă accelera cariera.
