de Luc Claustres

Cum să decideți dacă MongoDB este potrivit pentru dvs.

În ultimii doi ani, am construit aplicații web în jur MongoDB. În acest scurt articol aș dori să răspund la unele dintre întrebările recurente sau neînțelegeri pe care majoritatea dezvoltatorilor le au atunci când îl evaluează:

  • Ce este licențierea?
  • Ce înseamnă că MongoDB este o bază de date NoSQL?
  • Dar performanțele MongoDB?
Cum sa decideti daca MongoDB este potrivit pentru dvs

Licențierea

Da, MongoDB este licențiat în baza Free Software Foundation GNU AGPL v3.0. Practic, acest lucru înseamnă că îmbunătățirile pe care le aduceți MongoDB trebuie comunicate comunității. Trebuie distribuit și codul sursă al oricărei lucrări derivate.

S-ar putea să vă întrebați dacă aplicația dvs. este o lucrare derivată. Trebuie să mărturisesc că nu am găsit niciodată o definiție simplă a unui astfel de termen. Cu toate acestea, în cazul specific al MongoDB, ei pur și simplu recunoașteți că aplicațiile care folosesc baza lor de date sunt o lucrare separată. Mai mult, driverele acceptate sunt eliberate sub Licență Apache v2.0. Acesta este un permis permisiv. Nu este necesar să vă publicați codul sursă, iar aplicația dvs. vorbește de obicei doar cu MongoDB folosind un driver.

În consecință, nu trebuie să vă preocupați de acordarea licențelor MongoDB pentru a vă crea aplicația în jurul acesteia. Ei trimit chiar scrisori semnate care afirmă promisiunea către departamentele juridice dacă există întrebări. De asemenea, oferă licențe comerciale dacă scrisoarea semnată nu este suficientă.

Notă: deși o mare experiență mă face să am încredere în această analiză, nu sunt avocat. Opinia prezentată aici este înțelegerea mea personală și nu este una oficială.

NoSQL

Da, MongoDB este o bază de date NoSQL. Acest cuvânt poate fi destul de confuz. Voi încerca să analizez cele mai comune idei, concentrându-mă asupra modului în care acest lucru se aplică MongoDB.

Orientat spre documente

În bazele de date tradiționale SQL, datele sunt aranjate sub formă de tabele și rânduri. Fiecare rând are un număr fix de coloane care pot stoca doar date de un anumit tip (de exemplu, Integer, Text, Datetime). Aceasta definește schemă a datelor dvs.

În MongoDB, datele sunt stocate sub formă de Obiecte BSON organizat în colecții. Datele sunt manipulate de obicei sub formă de Obiecte JSON. Acest lucru face ca maparea obiectelor în baza de date să fie o sarcină simplă, eliminând în mod normal orice similar cu un cartarea obiect-relațională.

Tranzacțional

Înainte de v4, MongoDB furniza doar tranzacții la nivel de document. Scrierile nu au fost niciodată aplicate parțial unui document inserat sau actualizat. Operația a fost atomică în sensul că fie eșuează, fie reușește. Pentru documentul în întregime, se spunea că este ACID la nivel de document. În consecință, nu a existat nicio posibilitate de modificări atomice care să se întindă pe mai multe documente. A trebuit să imitați tranzacțiile necesare în baza de date (de exemplu, folosind Comitere în 2 faze).

Din v4, MongoDB acceptă tranzacții ACID cu mai multe documente, făcându-l singura bază de date open source care combină modelul documentului cu garanțiile ACID.

Fără schemă (într-adevăr?)

Acest lucru înseamnă că nu trebuie să spuneți bazei de date structura datelor dvs. și tipurile primitive care vor fi utilizate înainte de a putea să le gestionați. Aceasta înseamnă, de asemenea, că puteți amesteca documente care au structuri diferite în aceeași colecție de date.

Unul dintre marile beneficii este că migrațiile schemei devin mai ușoare (majoritatea ajustărilor aduse bazei de date sunt transparente și automate). Este puțin probabil ca revenirea să cauzeze probleme. Un alt avantaj este că extinderea dinamică a modelelor de date existente cu atribute personalizate în timpul rulării este simplă.

Dar toate acestea nu înseamnă că nu aveți deloc nicio schemă. Daca nu este explicit declarat, strălucește implicit din logica aplicației dvs. Ar putea fi declarat în alte moduri de a gestiona validarea formularului / datelor. Oricum, trebuie să spuneți în mod explicit bazei de date cum să creați indici pentru a asigura performanțe bune.

Într-adevăr, proiectarea schemelor este piatra de temelie a realizării unor baze de date minunate, indiferent dacă sunt sau nu SQL. Dacă nu vă înțelegeți datele și limitările hardware și software, nu puteți proiecta eficient o schemă.

Non-relațional (într-adevăr?)

Aceasta înseamnă că nu trebuie să creați întotdeauna o relație între două documente pentru a gestiona structurile de date agregate.

Într-adevăr, în bazele de date relaționale, clauza SQL JOIN vă permite să combinați rânduri din două sau mai multe tabele folosind un câmp comun între ele. Bazele de date orientate spre documente, cum ar fi MongoDB, sunt proiectate pentru a fi stocate denormalizat date. În mod ideal, nu ar trebui să existe nicio relație între colecții: dacă aceleași date sunt necesare în două sau mai multe documente, acestea trebuie repetate. Unul dintre marile beneficii este că a operație de citire simplă este necesar pentru a obține toate datele.

Dar puteți totuși să creați relații și să consultați un alt document dacă doriți sau aveți nevoie:

  • după ID, îl puteți „completa” manual cu o a doua interogare sau folosind DBRefs
  • prin orice alt câmp, atunci puteți utiliza fișierul $lookupoperator

Acest lucru face MongoDB cu adevărat flexibil și vă permite să alegeți cum să gestionați relațiile dintre obiectele dvs. de la caz la caz.

Performanţă

Citeste, scrie

Da, MongoDB ca orice altă bază de date „adevărată” este concepută pentru a gestiona un volum imens de date. Pe scurt, sute sau mii de obiecte nu sunt nimic pentru o bază de date, deci nu trebuie să vă faceți griji dacă aveți astfel de numere. Puteți găsi o mulțime de repere în jur. Iată una simplă pentru a vă oferi o anumită ordine de mărime. Documentele stocate sunt într-adevăr simple și reprezintă de obicei o măsurare marcată cu timp:

{    value: random(0,100),    timestamp: date}

Datorită modului în care MongoDB delegă gestionarea memoriei în sistemul de operare, a avea documente mai complexe (care conțin de obicei zeci de atribute) nu afectează semnificativ rezultatele

Ambele atribute au fost indexate. MongoDB adaugă și indexează automat ID-ul unic al documentului. Am testat trei solicitări:

  • găsiți valoarea maximă a colecției folosind cadru de agregare
  • găsiți cele mai mari 100 de valori mai mari decât 99,9
  • obțineți un singur document după ID

„Cererea maximă” nu beneficiază de indexuri din cauza agregării, în timp ce cererile „mai mari decât” și „prin ID” o pot folosi. Veți vedea cum acest lucru este important pentru performanță.

Configurația testului a fost MongoDB 3.4.1 64 de biți – OS Windows 7 Pro SP1 – CPU Core i7–4712HQ 2.3GHz – 16Go RAM — SSD HD, iar rezultatele testului au fost următoarele:

Deci, dacă creați indicii corecți care interogează un miliard de documente, acesta este încă suficient de performant pentru majoritatea aplicațiilor de pe un singur server. Dacă este necesar, puteți crește performanța folosind împărțire.

Iată scripturile utilizate pentru a crea / interoga baza de date pentru acest test:

Și comenzile de rulare:

// Launch server./mongod --dbpath "C:Program FilesMongoDBServer3.4data" --port 27018// Insertion exemple for 10e7./mongo --port 27018 --eval "var arg1=10000000" create_collection.js// Requests./mongo --port 27018 --eval "" query_collection.js

Memorie

Da, MongoDB pare adesea că folosește toată memoria RAM disponibilă. De fapt, se bazează pe diferite motoare de stocare. WiredTiger este valoarea implicită care începe în MongoDB 3.2 și MMAPv1 este implicit pentru versiunile MongoDB înainte de 3.2. Cu toate acestea, funcționează destul de similar. Prin memoria cache a sistemului de fișiere, ei utilizați automat toată memoria gratuită care nu este utilizată de memoria cache a motorului sau de alte procese. Și acest lucru este coerent dacă doriți să aveți performanțe maxime.

Deci, monitoarele de resurse de sistem arată adesea că MongoDB folosește multă memorie, dar utilizarea sa este dinamică. Dacă un alt proces are nevoie brusc de jumătate din memoria RAM a serverului, MongoDB va ceda memorie cache pentru celălalt proces.

În consecință, parametrul unic pe care îl puteți regla pentru a optimiza utilizarea memoriei este dimensiunea cache a motorului. De exemplu, în mod implicit, motorul WiredTiger folosește 50% din RAM minus 1 GB, care poate fi destul de mare pe servere cu multă memorie. Acest lucru poate provoca chiar și unele probleme dacă utilizați containere cu memorie limitată, deci, pur și simplu, aflați echilibrul potrivit pentru cazul dvs. de utilizare.

Concluzie

Sper că știți că aveți o idee mai precisă a beneficiilor oferite de MongoDB dacă se potrivește nevoilor dumneavoastră. Recent, MongoDB a lansat o ofertă de bază de date ca serviciu numită Atlas MongoDB care ar putea fi util pentru tine de a testa.

Dacă ți-a plăcut acest articol, nu ezita să arunci o privire soluțiile noastre Open Source, Kalisio echipa!