Articolul este tradus în cadrul pregătirii pentru lansarea cursului .
Puncte cheie:
- Este extrem de important să dezvoltați un schema, chiar dacă în MongoDB aceasta nu este obligatorie.
- În mod similar, indicii trebuie să corespundă schemei dumneavoastră și modelelor de acces.
- Evitați utilizarea obiectelor mari și a unor matrice mari.
- Fiți atenți cu setările MongoDB, mai ales când este vorba de securitate și stabilitate.
- În MongoDB nu există un optimizator de interogări, așa că trebuie să fiți prudenți atunci când efectuați operațiuni de interogare.
Lucrez cu baze de date de foarte mult timp, dar abia recent am descoperit MongoDB. Sunt câteva aspecte pe care aș fi vrut să le știu înainte de a începe să lucrez cu ea. Atunci când o persoană are deja experiență într-un anumit domeniu, are preconcepeții despre ce sunt bazele de date și ce fac acestea. Sperând să ușurez înțelegerea pentru alții, prezint o listă de greșeli comune.
Crearea unui server MongoDB fără autentificare
Din păcate, MongoDB este instalată, implicit, fără autentificare. Pentru o stație de lucru la care se accesează local, această practică este normală. Însă, deoarece MongoDB este un sistem multi-utilizator care preferă să utilizeze resurse mari de memorie, ar fi mai bine să o instalezi pe un server cu cât mai multă memorie RAM disponibilă în condițiile tale, chiar dacă intenționezi să o folosești doar pentru dezvoltare. Instalarea pe server prin portul implicit poate fi problematică, mai ales dacă se poate executa orice cod în javascript în interogare (de exemplu, $where ca idee pentru ).
Există câteva metode de autentificare, dar cea mai simplă este să configurezi un ID/parolă pentru utilizator. Folosește această idee până când te gândești la o autentificare mai sofisticată bazată pe . Când vine vorba de securitate, MongoDB trebuie să fie actualizată constant, iar jurnalele trebuie să fie verificate întotdeauna pentru acces neautorizat. De exemplu, îmi place să aleg o altă portă în loc de portul implicit.
Nu uita să legi suprafața de atac de MongoDB
oferă sfaturi utile pentru reducerea riscului de acces neautorizat și scurgeri de date. Este ușor să ignori și să spui că un server pentru dezvoltare nu necesită un nivel înalt de securitate. Totuși, lucrurile nu sunt atât de simple și aceasta se aplică tuturor serverelor MongoDB. În special, dacă nu există un motiv întemeiat pentru a folosi , sau , trebuie dezactivată utilizarea codului JavaScript arbitrar, scriind în fișierul de configurare . Deoarece în MongoDB standard fișierele de date nu sunt criptate, este recomandat să porniți MongoDB cu , care are acces complet la fișiere, cu acces restricționat doar pentru acesta și capacitatea de a folosi propriile instrumente de gestionare a accesului la fișiere ale sistemului de operare.
Eroare în proiectarea schemei
MongoDB nu folosește o schemă. Dar asta nu înseamnă că schema nu este necesară. Dacă doriți doar să stocați documente fără o schemă coerentă, le puteți salva rapid și simplu, dar recuperarea lor poate fi .
Articolul clasic „ merită citit, iar funcții precum în instrumentul terț Studio 3T ar trebui utilizate pentru verificări regulate ale schemelor.
Nu uitați de ordinea de sortare
Ignorarea ordinii de sortare poate fi cea mai frustrantă și să consume mai mult timp decât utilizarea oricărei alte configurații greșite. În mod implicit, MongoDB utilizează . Dar este puțin probabil să fie de ajutor. Sortările sensibile la majuscule, diacritice, binare au fost considerate niște anacronisme, împreună cu mărgele, kaftane și mustăți răsucite, încă din anii '80. Acum utilizarea lor este inacceptabilă. În viața reală, „motoceclul” este același lucru cu „Motoceclul”. Iar „Britania” și „britania” sunt același loc. Litera mică este pur și simplu echivalentul mare al unei litere mari. Și nu mă faceți să discut despre sortarea diacriticelor. Când creați o bază de date în MongoDB, utilizați parametrii de sortare fără ținerea cont de diacritice și , care corespund limbii și . Astfel, veți simplifica semnificativ căutarea în datele de tip șir.
Crearea colecțiilor cu documente mari
MongoDB este încântat să stocheze documente mari de până la 16 MB în colecții, iar este destinat documentelor mari care depășesc 16 MB. Dar, doar pentru că documentele mari pot fi stocate acolo, nu este neapărat cea mai bună idee să le păstrezi acolo. Cel mai bine, MongoDB va funcționa dacă veți salva documente individuale de câțiva kilobiți, considerându-le mai degrabă ca pe niște rânduri într-un tabel SQL larg. Documentele mari vor fi surse de probleme cu .
Crearea documentelor cu array-uri mari
Documentele pot conține array-uri. Este ideal ca numărul de elemente din array să fie departe de un număr de patru cifre. Dacă elementele din array sunt adăugate frecvent, se va depăși documentul care le conține și va trebui să fie , ceea ce înseamnă că va trebui să . La reindexarea unui document cu un array mare, indexurile sunt adesea rescrise, deoarece pentru fiecare element există , care stochează indexul său. O astfel de reindexare are loc și atunci când un document este inserat sau șters.
În MongoDB există așa-numitul , care oferă spațiu pentru creșterea documentelor, pentru a minimiza această problemă.
Ar putea părea că te poți descurca fără indexarea array-urilor. Din păcate, din cauza lipsei indexurilor, pot apărea alte probleme. Deoarece documentele sunt vizualizate de la început până la sfârșit, căutarea elementelor la sfârșitul array-ului va dura mai mult, iar majoritatea operațiunilor legate de un astfel de document vor fi .
Nu uitați că ordinea etapelor în agregare contează
Într-un sistem de baze de date cu un optimizer de interogări, interogările pe care le scrieți sunt explicații ale a ceea ce doriți să obțineți, nu ale modului în care să obțineți. Acest mecanism funcționează pe un principiu similar cu comanda într-un restaurant: de obicei, comandați un fel de mâncare, nu dați instrucțiuni detaliate bucătarului.
În MongoDB, îi instruiți pe bucătari. De exemplu, trebuie să vă asigurați că datele trec prin reduce cât mai devreme în pipeline folosind $match și $project, iar sortarea se face doar după reduce, și că căutarea se desfășoară exact în ordinea în care ai nevoie. Oferirea unui optimizator de interogări, care elimină muncile inutile, ordonează optim etapele și selectează tipul de conexiune, te poate răsfăța. În MongoDB, ai mai mult control asupra costului confortului.
Instrumente precum simplifică construirea interogărilor de agregare în . Funcția Aggregation Editor îți va permite să aplici operatori de pipeline câte unul pe rând, precum și să verifici datele de intrare și ieșire la fiecare etapă pentru a simplifica debugging-ul.
Folosirea scrierii rapide
Nu seta niciodată în MongoDB parametrii de scriere cu viteză mare, dar cu fiabilitate scăzută. Acest mod "file-and-forget" pare rapid, deoarece comanda returnează înainte de a efectua scrierea. Dacă sistemul se prăbușește înainte ca datele să fie scrise pe disc, acestea se vor pierde și vor fi într-o stare nesincronizată. Din fericire, în MongoDB pe 64 de biți este activat logging-ul.
Motoarele de stocare MMAPv1 și WiredTiger folosesc logging-ul pentru a preveni acest lucru, deși WiredTiger se poate recupera până la ultimul , dacă logging-ul este dezactivat.
Logging-ul garantează că baza de date se află într-o stare sincronizată după recuperare și păstrează toate datele până la momentul înregistrării în jurnal. Frecvența înregistrărilor este reglată prin parametrul .
Pentru a te asigura de înregistrări, asigură-te că în fișierul de configurare logging-ul este activat ), iar frecvența înregistrărilor corespunde volumului de informații pe care îți poți permite să-l pierzi.
Sortare fără index
Atunci când cauți și agreghezi, apare adesea necesitatea de a sorta datele. Să sperăm că acest lucru se face pe una dintre etapele finale, după filtrarea rezultatelor pentru a reduce volumul de date sortate. Și chiar și în acest caz, pentru sortare vei avea nevoie de . Poți folosi un index singular sau compus.
Dacă nu există un index adecvat, MongoDB se va descurca fără el. Există o limită de memorie de 32 MB pentru dimensiunea totală a tuturor documentelor în , iar dacă MongoDB atinge această limită, aceasta va genera fie o eroare, fie va returna .
Căutare fără suport pentru indici
Interogările de căutare îndeplinesc o funcție similară cu operația JOIN în SQL. Pentru o performanță optimă, au nevoie de un index al valorii cheii utilizate ca cheie externă. Acest lucru nu este evident, deoarece utilizarea acestuia nu este reflectată în explain(). Aceste indecși sunt un supliment la indexul înregistrat în explain(), care la rândul său este utilizat de operatorii de pipeline $match și $sort, atunci când aceștia apar la începutul pipeline-ului. Indecșii pot acum să acopere orice etapă .
Renunțarea la utilizarea actualizărilor multiple
Metoda este utilizată pentru a modifica o parte dintr-un document existent sau un întreg document, până la o înlocuire completă în funcție de parametru specificat de tine . Nu este atât de evident că acesta nu va procesa toate documentele din colecție până nu setezi parametrul pentru a actualiza toate documentele care respectă criteriile cererii.
Nu uita de importanța ordinii cheilor în tabela hash
În JSON, un obiect constă dintr-o colecție neordonată de zero sau mai multe perechi nume/valoare, unde numele este un șir, iar valoarea este un șir, un număr, o valoare booleană, zero, un obiect sau un array.
Din păcate, BSON pune un accent deosebit pe ordine în timpul căutărilor. În MongoDB, ordinea cheilor din interiorul obiectelor încorporate , adică { firstname: "Phil", surname: "factor" } – nu este același lucru cu { { surname: "factor", firstname: "Phil" }. Asta înseamnă că trebuie să păstrezi în documente ordinea perechilor nume/valoare dacă vrei să te asiguri că le vei găsi.
Nu confunda "null" și "undefined"
Valoare "undefined" care nu a fost niciodată permis în JSON, conform JSON (ECMA-404, Secțiunea 5), deși este utilizat în JavaScript. Mai mult, pentru BSON este depășit și este transformat în $null, ceea ce nu este întotdeauna o soluție bună. .
Utilizare $limit() fără $sort()
Foarte des, atunci când dezvolți în MongoDB, este util să vezi doar un eșantion de rezultat care va fi returnat dintr-o cerere sau o agregare. Pentru această sarcină, îți va fi de folos $limit(), dar acesta nu ar trebui să existe niciodată în versiunea finală a codului, decât dacă înainte de el nu folosești $sort. Această mecanică este necesară deoarece, altfel, nu poți garanta ordinea rezultatelor și nu vei putea vizualiza datele în mod fiabil. În partea superioară a rezultatului, vei obține diferite înregistrări în funcție de sortare. Pentru a funcționa corect, interogările și agregările trebuie să fie determinate, adică să ofere aceleași rezultate la fiecare execuție. Codul care conține $limit(), dar nu conține $sort, nu va fi considerat determinat și poate cauza erori care vor fi greu de urmărit.
Concluzie
Singurul mod de a fi dezamăgit de MongoDB este să o compari direct cu alt tip de baze de date, cum ar fi SGBD-urile, sau să te apropii de utilizarea ei având anumite așteptări. E ca și cum ai compara o portocală cu o furculiță. Sistemele de baze de date urmăresc obiective specifice. E cel mai bine să înțelegi și să apreciezi aceste diferențe. Ar fi jenant să apesi pe dezvoltatorii MongoDB din cauza căii pe care au fost nevoiți să o urmeze în calitate de SGBD. Îmi doresc să văd modalități noi și interesante de a rezolva problemele vechi, cum ar fi asigurarea integrității datelor și crearea de sisteme de date rezistente la defecțiuni și atacuri cibernetice.
Implementarea tranzacționalității ACID în MongoDB în versiunea 4.0 este un bun exemplu de implementare a unor îmbunătățiri importante printr-o abordare inovatoare. Tranzacțiile multi-document și multi-operator sunt acum atomice. De asemenea, a apărut posibilitatea de a regla timpul necesar pentru obținerea blocajelor și de a încheia tranzacții blocate, precum și de a modifica nivelul de izolare.
Citește mai mult:
Sursa: habr.com
