Share
NoSQL bazele de date au apărut foarte mult în ultimii ani datorită structurii lor mai puțin constrânse, a schemei scalabile de design și a accesului mai rapid în comparație cu bazele de date tradiționale relaționale (RDBMS / SQL). MongoDB este o bază de date NoSQL orientată spre documente, care stochează date sub formă de obiecte asemănătoare JSON. A apărut ca una dintre bazele de date principale datorită schemei dinamice, scalabilității ridicate, performanței optime a interogării, indexării mai rapide și unei comunități active a utilizatorilor.
Dacă veniți dintr-un fundal RDBMS / SQL, înțelegerea conceptelor NoSQL și MongoDB poate fi dificilă în timp ce începeți, deoarece ambele tehnologii au un mod foarte diferit de reprezentare a datelor. Acest articol vă va ajuta să înțelegeți modul în care domeniul RDBMS / SQL, funcționalitățile acestuia, termenii și limbajul interogării se află în baza de date MongoDB. Prin cartografiere, vreau să spun că dacă avem un concept în RDBMS / SQL, vom vedea ce concept echivalent în MongoDB este.
Vom începe cu cartografierea conceptelor relaționale de bază cum ar fi tabelul, rândul, coloana etc. și se va deplasa pentru a discuta indexarea și asocierea. Apoi, vom examina interogările SQL și vom discuta interogările corespunzătoare ale bazei de date MongoDB. Articolul presupune că sunteți conștient de conceptele bazelor de date relaționale de bază și SQL, deoarece în tot articolul se va pune mai multă stres pe înțelegerea modului în care aceste concepte se află în MongoDB. Sa incepem.
Fiecare bază de date din MongoDB constă în colecții care sunt echivalente cu o bază de date RDBMS compusă din tabele SQL. Fiecare colecție stochează date sub formă de documente echivalente tabelelor care stochează date în rânduri. În timp ce un rând stochează datele din setul de coloane, un document are o structură JSON (cunoscută sub numele de BSON în MongoDB). În sfârșit, modul în care avem rânduri într-un rând SQL, avem câmpuri în MongoDB. În continuare este un exemplu de document (rând de citire) având câteva câmpuri (citiți coloane) care stochează datele utilizatorului:
Accentsconagua
"_id": ObjectId ("5146bb52d8524270060001f3"), "vârsta": 25, "oraș": "Los Angeles", "email": "[email protected]", "user_name": "Mark Hanks" Acest document este echivalent cu un singur rând din RDBMS. O colecție constă din multe astfel de documente, la fel cum o masă constă din mai multe rânduri. Rețineți că fiecare document dintr-o colecție are un caracter unic _id , care este un câmp de 12 octeți care servește drept cheie primară pentru documente. Câmpul este generat automat la crearea documentului și este utilizat pentru identificarea unică a fiecărui document.
Pentru a înțelege mai bine mapările, să luăm un exemplu de tabel SQL utilizatori și structura corespunzătoare în MongoDB. După cum se arată în figura 1, fiecare rând din tabela SQL se transformă într-un document și fiecare coloană într-un câmp din MongoDB.
Un lucru interesant pe care trebuie să-l concentrăm aici este faptul că diferitele documente dintr-o colecție pot avea scheme diferite. Deci, în MongoDB este posibil ca un document să aibă cinci câmpuri, iar celălalt document să aibă șapte câmpuri. Câmpurile pot fi ușor adăugate, eliminate și modificate oricând. De asemenea, nu există nici o constrângere asupra tipurilor de date ale câmpurilor. Astfel, la un moment dat un câmp poate ține int tip de date și la următoarea instanță poate deține o mulțime.
Aceste concepte trebuie să pară foarte diferite de cititorii care provin din mediul RDBMS în care structurile de tabelă, coloanele, tipurile de date și relațiile lor sunt predefinite. Această funcție de a utiliza schema dinamică ne permite să generăm documente dinamice la momentul executării.
De exemplu, luați în considerare următoarele două documente în interiorul aceleiași colecții, dar având scheme diferite (Fig. 2):
Primul document conține câmpurile adresa și DOB care nu sunt prezente în al doilea document, în timp ce al doilea document conține câmpuri sex și ocupaţie care nu sunt prezente în primul. Imaginați-vă dacă am fi proiectat acest lucru în SQL, am fi păstrat patru coloane suplimentare pentru adresa, DOB, sex și ocupaţie, dintre care unele ar stoca valori goale (sau nulă) și, prin urmare, ar ocupa spațiu inutil.
Acest model de schemă dinamică este motivul pentru care bazele de date NosSQL sunt extrem de scalabile din punctul de vedere al designului. Diferite scheme complexe (ierarhice, structurate pe arbori etc.) care ar necesita un număr de tabele RDBMS pot fi proiectate eficient folosind astfel de documente. Un exemplu tipic ar fi stocarea mesajelor utilizatorilor, a lor, a comentariilor și a altor informații asociate sub formă de documente. O implementare SQL pentru acelasi lucru ar avea in mod ideal tabele separate pentru stocarea posturilor, comentariilor si placilor, in timp ce un document MongoDB poate stoca toate aceste informatii intr-un singur document.
Relațiile în RDBMS sunt realizate folosind relații cheie primare și străine și interogarea celor care folosesc conexiuni. Nu există o mapare atât de simplă în MongoDB, dar relațiile de aici sunt concepute folosind documente încorporate și care leagă.
Luați în considerare un exemplu în care trebuie să stocăm informațiile despre utilizator și informațiile de contact corespunzătoare. Un design ideal SQL ar avea două tabele, să zicem user_information și informatii de contact, cu taste primare id și contact_id așa cum se arată în Fig informatii de contact tabel ar conține, de asemenea, o coloană numele de utilizator care ar fi cheia străină care să lege id câmpul user_information masa.
Acum vom vedea modul în care vom proiecta astfel de relații în MongoDB folosind abordările Legături documente și documente încorporate. Observați că, în schema SQL, adăugăm în general o coloană (cum ar fi id și contact_id în cazul nostru), care acționează ca o coloană primară pentru acest tabel. Cu toate acestea, în MongoDB, în general, utilizăm generarea automată _id domeniu ca cheie primară pentru identificarea unică a documentelor.
Această abordare va utiliza două colecții, user_information și informatii de contact ambele având unicitatea lor _id câmpuri. Vom avea un câmp numele de utilizator în informatii de contact document care se referă la _id câmpul user_information document care arată la care utilizator corespunde adresa de contact. (Vezi Fig. 4) Rețineți că în MongoDB relațiile și operațiunile lor corespunzătoare trebuie să fie luate în considerare manual (de exemplu prin cod), deoarece nu se aplică constrângeri și reguli cheie străine.
numele de utilizator câmpul din documentul nostru este pur și simplu un câmp care deține unele date și toată logica asociată cu acesta trebuie pusă în aplicare de noi. De exemplu, chiar dacă veți introduce unele numele de utilizator în informatii de contact document care nu există în user_information de colectare, MongoDB nu va arunca nici o eroare spunând că respectivul numele de utilizator nu a fost găsit în user_information (spre deosebire de SQL unde aceasta ar fi o constrângere cheie nevalidă).
A doua abordare este de a încorpora informatii de contact document în interiorul user_information un astfel de document (Fig. 5):
În exemplul de mai sus, am încorporat un mic document de informații de contact în interiorul informațiilor despre utilizator. În mod similar, documente complexe și date ierarhice pot fi încorporate astfel încât să se raporteze entităților.
De asemenea, care abordare a utilizării în cadrul abordării Linking and Embedded depinde de scenariul specific. Dacă este de așteptat ca datele care urmează a fi încorporate să crească într-o dimensiune mai mare, este mai bine să se utilizeze abordarea Legare, mai degrabă decât abordarea Embedded, pentru a evita ca documentul să devină prea mare. În general, abordarea embedded este utilizată în cazul în care trebuie încorporată o cantitate limitată de informații (cum ar fi adresa din exemplul nostru).
Pentru a rezuma, următoarea diagramă (Figura 6) reprezintă relațiile comune pe care le-am discutat:
Acum, că suntem mulțumiți de mapările de bază dintre RDBMS și MongoDB, vom discuta modul în care limba de interogare folosită pentru a interacționa cu baza de date diferă între ele.
Pentru interogările MongoDB, să presupunem o colecție utilizatori cu structura de document, după cum urmează:
"_id": ObjectId ("5146bb52d8524270060001f3"), "post_text": "Aceasta este o eșantionare", "user_name": "mark", "post_privacy": "public", "post_likes_count" Pentru interogările SQL, presupunem tabelul utilizatori având cinci coloane cu următoarea structură:
Vom discuta interogări legate de crearea și modificarea colecțiilor (sau a tabelelor), inserarea, citirea, actualizarea și eliminarea documentelor (sau a rândurilor). Există două interogări pentru fiecare punct, unul pentru SQL și altul pentru MongoDB. Voi explica interogările MongoDB numai pentru că suntem destul de familiarizați cu interogările SQL. Interogările MongoDB prezentate aici sunt scrise în shell-ul Mongo JavaScript, în timp ce interogările SQL sunt scrise în MySQL.
În MongoDB, nu este nevoie să creați în mod explicit structura de colectare (așa cum facem pentru tabelele folosind a CREATE TABLE interogare). Structura documentului este creată automat când prima inserare apare în colecție. Cu toate acestea, puteți crea o colecție goală utilizând createCollection comanda.
SQL: CREATE TABLE "posturi" ('id' int (11) NU NULL AUTO_INCREMENT, 'post_text' varchar (500) NOT NULL, 'user_name' varchar (20) NOT NULL, 'post_privacy' post_likes_count 'int (11) NU NULL, KEY PRIMARY (' id ')) MongoDB: db.createCollection ("posturi") Pentru a insera un document în MongoDB, folosim introduce care ia ca obiect un obiect cu perechi de valori cheie. Documentul introdus va conține generația automată _id camp. Cu toate acestea, puteți oferi în mod explicit o valoare de 12 octeți ca _id împreună cu celelalte domenii.
SQL: INSERT INTO 'posturi' ('id', 'post_text', 'user_name', 'post_privacy', 'post_likes_count') VALUES (NULL, „); MongoDB: db.posts.insert (user_name: "marca", post_text: "Aceasta este o mostră de post", post_privacy: "public", post_likes_count: 0) Nu este Modificați tabelul în MongoDB pentru a modifica structura documentului. Deoarece documentele sunt dinamice în schemă, schema se modifică după cum și în cazul în care orice actualizare are loc în document.
MongoDB utilizează găsi care este echivalentă cu SELECTAȚI comanda în SQL. Următoarele afirmații au citit pur și simplu toate documentele din posturi Colectie.
SQL: SELECT * FROM 'posturi' MongoDB: db.posts.find ()
Următoarea interogare face o căutare condiționată pentru documente care au nume de utilizator domeniu ca marcă. Toate criteriile pentru preluarea documentelor trebuie să fie plasate în primele bretele separate prin virgule.
SQL: SELECT * FROM 'posturi' WHERE 'user_name' = 'marca' MongoDB: db.posts.find (user_name: "mark"
Următoarea interogare preia anumite coloane, POST_TEXT și post_likes_count așa cum se specifică în al doilea set de brațe .
SQL: SELECT 'post_text', 'post_likes_count' din 'mesaje' MongoDB: db.posts.find (, post_text: 1, post_likes_count: 1)
Rețineți că implicit MongoDB returnează _id câmp cu fiecare declarație găsită. Dacă nu vrem acest câmp în setul nostru de rezultate, trebuie să specificăm _id cheie cu a 0 valoare în lista coloanelor care urmează să fie recuperate. 0 valoarea cheii indică faptul că dorim să excludem acest câmp din setul de rezultate.
MongoDB: db.posts.find (, post_text: 1, post_likes_count: 1, _id: 0)
Următoarea interogare preia câmpuri specifice pe baza criteriilor pe care le conține nume de utilizator este marcă.
SQL: SELECT 'post_text', 'post_likes_count' FROM 'posturi' WHERE 'user_name' = 'marca' MongoDB: db.posts.find (user_name: mark post_text: 1, post_likes_count: 1)
Vom adăuga acum încă un criteriu pentru a prelua posturile cu tipul de confidențialitate ca public. Câmpurile de criterii specificate prin virgule reprezintă logica ȘI condiție. Astfel, această declarație va căuta documente care au ambele nume de utilizator la fel de marcă și post_privacy la fel de public.
SQL: SELECT 'post_text', 'post_likes_count' FROM 'posturi' WHERE 'user_name' = 'mark' SI 'post_privacy' = 'public' MongoDB: db.posts.find (user_name: "mark", post_privacy: , POST_TEXT: 1, post_likes_count: 1)
Pentru a folosi logic SAU între criteriile din găsi metoda, folosim $ sau operator.
SQL: SELECT 'post_text', 'post_likes_count' din 'posturi' WHERE 'user_name' = 'mark' OR 'post_privacy' = 'public' MongoDB: db.posts.find ($ or: user_name: mark " , post_privacy: "public"], POST_TEXT: 1, post_likes_count: 1)
Apoi, vom folosi fel metoda care sortează rezultatul în ordinea ascendentă a lui post_likes_count(indicat de 1).
SQL: SELECT * FROM 'posturi' WHERE 'user_name' = ordine 'mark' prin post_likes_count ASC MongoDB: db.posts.find (user_name: mark ")) sort (post_likes_count: 1)
Pentru a sorta rezultatele în ordine descrescătoare, specificăm -1 ca valoare a terenului.
SQL: SELECT * FROM 'posturi' WHERE 'user_name' = comanda 'mark' prin post_likes_count DESC MongoDB: db.posts.find (user_name: "mark") sort (post_likes_count: -1)
Pentru a limita numărul de documente care urmează să fie returnate, vom folosi limită care specifică numărul de documente.
SQL: SELECT * FROM 'posturi' LIMIT 10 MongoDB: db.posts.find () limit (10)
Modul în care folosim ofset în SQL pentru a sări peste un număr de înregistrări pe care le folosim ocolire în MongoDB. De exemplu, următoarea afirmație ar aduce zece postări care sărită peste primele cinci.
SQL: SELECT * FROM 'posturi' LIMIT 10 OFFSET 5 MongoDB: db.posts.find () limit (10) .skip (5)
Primul parametru la Actualizați metoda specifică criteriile pentru selectarea documentelor. Al doilea parametru specifică operația de actualizare reală care trebuie efectuată. De exemplu, următoarea interogare selectează toate documentele cu nume de utilizator la fel de marcă și le stabilește post_privacy la fel de privat.
O diferență aici este că implicit, MongoDB Actualizați interogările actualizează numai un singur document (și primul). Pentru a actualiza toate documentele potrivite, trebuie să furnizăm un al treilea parametru care să precizeze multi la fel de Adevărat indicând faptul că vrem să actualizăm mai multe documente.
SQL: Posturi UPDATE SET post_privacy = "privat" WHERE user_name = "marchează" MongoDB: db.posts.update user_name: "mark", $ set: post_privacy: )
Eliminarea documentelor este destul de simplă și similară cu SQL.
SQL: DELETE FROM posturi WHERE user_name = "marchează" MongoDB: db.posts.remove (user_name: "mark")
MongoDB are un index prestabilit creat pe _id fiecare colecție. Pentru a crea noi indexuri pe câmpuri, folosim ensureIndex metodă specificând câmpurile și ordinea asociată de sortare indicată de 1 sau -1(ascendent sau descendent).
SQL: CREATE INDEX index_posts ON posturi (user_name, post_likes_count DESC) MongoDB: db.posts.ensureIndex (user_name: 1, post_likes_count: -1)
Pentru a vedea toți indicii prezenți în orice colecție, folosim getIndexes pe aceleași rânduri INDEX INDEX interogare SQL.
SQL: SHOW INDEX din mesaje MongoDB: db.posts.getIndexes ()
În acest articol, am înțeles modul în care conceptele și termenii elementari ai RDBMS / SQL se referă la MongoDB. Ne-am uitat la proiectarea relațiilor în MongoDB și am învățat cum funcționează funcționalitatea interogărilor SQL de bază în MongoDB.
După ce ați început să începeți cu acest articol, puteți să încercați interogări complexe, inclusiv agregare, reducerea hărților și interogări care implică mai multe colecții. Puteți obține, de asemenea, ajutorul unor instrumente online pentru a converti interogările SQL la interogări MongoDB la început. Puteți juca proiectarea unei scheme de baze de date MongoDB de probă pe cont propriu. Unul dintre exemplele cele mai bune pentru a face acest lucru ar fi o bază de date pentru a stoca mesajele utilizatorilor, plăcilor, comentariilor și comentariilor acestora. Acest lucru vă va oferi o imagine practică a designului flexibil al schemelor pe care le oferă MongoDB.
Simțiți-vă liber să comenteze orice sugestii, întrebări sau idei pe care doriți să le vedeți în continuare.
