Prijevod članka pripremljen je uoči početka tečaja .
Izdvajamo:
- Iznimno je važno razviti shemu iako je ona izborna u MongoDB-u.
- Isto tako, indeksi moraju odgovarati vašoj shemi i obrascima pristupa.
- Izbjegavajte korištenje velikih objekata i velikih nizova.
- Budite oprezni s postavkama MongoDB-a, posebno kada je riječ o sigurnosti i pouzdanosti.
- MongoDB nema optimizator upita, stoga morate biti oprezni pri izvođenju operacija upita.
Radim s bazama podataka jako dugo, ali tek sam nedavno otkrio MongoDB. Postoji nekoliko stvari koje bih volio znati prije nego što počnem raditi s njim. Kada osoba već ima iskustva u određenom području, ima unaprijed stvorene predodžbe o tome što su baze podataka i čemu služe. U nadi da ću drugima olakšati razumijevanje, predstavljam popis uobičajenih pogrešaka.
Stvaranje MongoDB poslužitelja bez autentifikacije
Nažalost, MongoDB je prema zadanim postavkama instaliran bez provjere autentičnosti. Za radnu stanicu kojoj se pristupa lokalno, ova praksa je normalna. No budući da je MongoDB višekorisnički sustav koji voli koristiti velike količine memorije, bit će bolje ako ga postavite na poslužitelj sa što više RAM-a, čak i ako ćete ga koristiti samo za razvoj. Instalacija na poslužitelj putem zadanog priključka može biti problematična, pogotovo ako se u zahtjevu može izvršiti bilo koji javascript kod (na primjer, $where kao ideja za ).
Postoji nekoliko metoda provjere autentičnosti, ali najlakša je postaviti korisnički ID/lozinku. Koristite ovu ideju dok razmišljate o otmjenoj autentifikaciji na temelju . Što se tiče sigurnosti, MongoDB treba stalno ažurirati, a zapise uvijek treba provjeravati radi neovlaštenog pristupa. Na primjer, volim odabrati drugi priključak kao zadani priključak.
Ne zaboravite povezati svoju napadnu površinu s MongoDB-om
sadrži dobre savjete za smanjenje rizika od upada u mrežu i curenja podataka. Lako je to odbaciti i reći da razvojni poslužitelj ne treba visoku razinu sigurnosti. Međutim, to nije tako jednostavno i to se odnosi na sve MongoDB poslužitelje. Osobito ako ne postoji uvjerljiv razlog za korištenje , ili , trebate onemogućiti korištenje proizvoljnog koda u JavaScriptu upisivanjem u konfiguracijsku datoteku . Budući da podatkovne datoteke nisu šifrirane u standardnom MongoDB-u, ima smisla pokrenuti MongoDB s njim , koji ima puni pristup datotekama, s ograničenim pristupom samo njima i mogućnošću korištenja vlastitih kontrola pristupa datotekama operativnog sustava.
Pogreška tijekom razvijanja kruga
MongoDB ne koristi shemu. Ali to ne znači da shema nije potrebna. Ako samo želite pohraniti dokumente bez ikakvog dosljednog uzorka, njihovo pohranjivanje može biti brzo i jednostavno, ali njihovo kasnije dohvaćanje može biti teško. .
Klasični članak " Vrijedno je pročitati, a značajke poput u alatu treće strane Studio 3T, vrijedi ga koristiti za redovite provjere krugova.
Ne zaboravite redoslijed sortiranja
Zaboravljanje redoslijeda sortiranja može uzrokovati više frustracija i gubitak vremena od bilo koje druge netočne konfiguracije. Prema zadanim postavkama MongoBD koristi . Ali malo je vjerojatno da će ikome biti od koristi. Binarne sorte osjetljive na velika i mala slova, naglaske smatrane su neobičnim anakronizmima zajedno s perlama, kaftanima i kovrčavim brkovima još 80-ih godina prošlog stoljeća. Sada je njihova upotreba neoprostiva. U stvarnom životu, "motocikl" je isto što i "motocikl". A "Britanija" i "Britanija" su isto mjesto. Malo slovo jednostavno je ekvivalent velikom slovu. I nemojte me tjerati da sortiram dijakritičke znakove. Kada stvarate bazu podataka u MongoDB-u, koristite uspoređivanje neosjetljivo na naglaske i , koji odgovaraju jeziku i . To će znatno olakšati pretraživanje podataka niza.
Stvorite zbirke s velikim dokumentima
MongoDB rado ugošćuje velike dokumente do 16 MB u zbirkama i Dizajniran za velike dokumente veće od 16 MB. Ali samo zato što se tamo mogu staviti veliki dokumenti, njihovo pohranjivanje tamo nije dobra ideja. MongoDB će najbolje raditi ako pohranjujete pojedinačne dokumente koji su veličine nekoliko kilobajta, tretirajući ih više kao retke u širokoj SQL tablici. Veliki dokumenti bit će izvor problema s .
Izrada dokumenata s velikim nizovima
Dokumenti mogu sadržavati nizove. Najbolje je ako je broj elemenata u nizu daleko od četveroznamenkastog broja. Ako se elementi često dodaju nizu, on će prerasti dokument koji ga sadrži i morat će biti , što znači da će biti potrebno . Prilikom ponovnog indeksiranja dokumenta s velikim nizom, indeksi će često biti prebrisani, jer postoji , koji pohranjuje svoj indeks. Ovo ponovno indeksiranje također se događa kada se dokument umetne ili izbriše.
MongoDB ima nešto što se zove , koji pruža prostor za rast dokumenata kako bi se ovaj problem sveo na minimum.
Možda mislite da možete bez indeksiranja polja. Nažalost, nedostatak indeksa može uzrokovati druge probleme. Budući da se dokumenti skeniraju od početka do kraja, traženje elemenata na kraju niza trajat će dulje, a većina operacija povezanih s takvim dokumentom bit će .
Ne zaboravite da je redoslijed faza u agregaciji bitan
U sustavu baze podataka s optimizatorom upita, upiti koje pišete su objašnjenja onoga što želite dobiti, a ne kako to dobiti. Ovaj mehanizam funkcionira po analogiji s naručivanjem u restoranu: obično jednostavno naručite jelo, a ne dajete detaljne upute kuharu.
U MongoDB-u dajete upute kuharu. Na primjer, morate biti sigurni da podaci prolaze reduce što je ranije moguće u cjevovodu koristeći $match и $project, a sortiranje se događa tek nakon reduce, i da se pretraga odvija točno onim redoslijedom kojim želite. Optimizator upita koji eliminira nepotreban rad, optimalno slijede korake i odabire vrste pridruživanja može vas razmaziti. Uz MongoDB imate veću kontrolu po cijenu pogodnosti.
Alati poput će pojednostaviti konstrukciju agregacijskih upita u . Značajka uređivača agregacije omogućuje vam primjenu izjava o cjevovodu jednu po jednu fazu i provjeru ulaznih i izlaznih podataka u svakoj fazi kako biste pojednostavili otklanjanje pogrešaka.
Korištenje brzog snimanja
Nikada nemojte postavljati MongoDB opcije pisanja tako da imaju veliku brzinu, ali nisku pouzdanost. Ovaj način rada "snimi-i-zaboravi" čini se brzim jer se naredba vraća prije pisanja. Ako se sustav sruši prije nego što se podaci zapišu na disk, oni će se izgubiti i završiti u nekonzistentnom stanju. Srećom, 64-bitni MongoDB ima omogućeno bilježenje.
Mehanizmi za pohranu MMAPv1 i WiredTiger koriste zapisivanje kako bi to spriječili, iako se WiredTiger može oporaviti do zadnje konzistentne , ako je zapisivanje onemogućeno.
Vođenje dnevnika osigurava da je baza podataka u dosljednom stanju nakon oporavka i zadržava sve podatke dok se ne upišu u dnevnik. Učestalost snimanja konfigurira se pomoću parametra .
Kako biste bili sigurni u unose, provjerite je li zapisivanje omogućeno u konfiguracijskoj datoteci ), a učestalost snimanja odgovara količini informacija koje si možete priuštiti izgubiti.
Sortiranje bez indeksa
Prilikom pretraživanja i združivanja često postoji potreba za sortiranjem podataka. Nadajmo se da je to učinjeno u jednoj od završnih faza, nakon filtriranja rezultata kako bi se smanjila količina podataka koji se sortiraju. Čak iu ovom slučaju, za sortiranje će vam trebati . Možete koristiti pojedinačni ili složeni indeks.
Ako nema odgovarajućeg indeksa, MongoDB će učiniti bez njega. Postoji ograničenje memorije od 32 MB na ukupnu veličinu svih dokumenata u , a ako MongoDB dosegne ovo ograničenje, onda će ili izbaciti pogrešku ili se vratiti .
Pretraživanje bez podrške indeksa
Upiti za pretraživanje izvode funkciju sličnu operaciji JOIN u SQL-u. Da bi najbolje funkcionirali, potreban im je indeks vrijednosti ključa koji se koristi kao strani ključ. To nije očito jer se uporaba ne odražava u explain(). Takvi indeksi dodaju se indeksu koji se upisuje explain(), koji zauzvrat koriste operateri cjevovoda $match и $sort, kada se sretnu na početku cjevovoda. Indeksi sada mogu pokriti bilo koju fazu .
Isključivanje korištenja višestrukih ažuriranja
način koristi se za promjenu dijela postojećeg dokumenta ili cijelog dokumenta, do potpune zamjene, ovisno o parametru koji navedete . Ono što nije tako očito jest da neće obraditi sve dokumente u zbirci osim ako ne postavite opciju za ažuriranje svih dokumenata koji zadovoljavaju kriterije zahtjeva.
Ne zaboravite važnost redoslijeda ključeva u hash tablici
U JSON-u objekt se sastoji od neuređene zbirke veličine nula ili više parova ime/vrijednost, gdje je ime niz, a vrijednost niz, broj, booleov, null, objekt ili niz.
Nažalost, BSON stavlja veliki naglasak na redoslijed pretraživanja. U MongoDB-u, redoslijed ključeva unutar ugrađenih objekata , tj { firstname: "Phil", surname: "factor" } - ovo nije isto što i { { surname: "factor", firstname: "Phil" }. To jest, morate pohraniti redoslijed parova ime/vrijednost u svojim dokumentima ako želite biti sigurni da ćete ih pronaći.
Nemojte se zbuniti "Null" и "nedefiniran"
Vrijednost "nedefiniran" nikada nije bio valjan u JSON-u, prema JSON (ECMA-404 odjeljak 5), iako se koristi u JavaScriptu. Štoviše, za BSON je zastario i pretvara se u $null, što nije uvijek dobro rješenje. .
Koristiti $limit() bez $sort()
Vrlo često kada razvijate u MongoDB-u, korisno je samo vidjeti uzorak rezultata koji će biti vraćen iz upita ili agregacije. Za ovaj zadatak trebat će vam $limit(), ali nikada ne bi trebao biti u konačnom kodu osim ako ga ne koristite prije $sort. Ova mehanika je neophodna jer inače ne možete jamčiti redoslijed rezultata i nećete moći pouzdano vidjeti podatke. Na vrhu rezultata dobit ćete različite unose ovisno o sortiranju. Da bi radili pouzdano, upiti i agregacije moraju biti deterministički, to jest proizvoditi iste rezultate svaki put kada se izvedu. Kod koji sadrži $limit(), ali ne $sort, neće biti deterministički i može kasnije uzrokovati pogreške kojima će biti teško ući u trag.
Zaključak
Jedini način da budete razočarani MongoDB-om je da ga izravno usporedite s drugom vrstom baze podataka, kao što je DBMS, ili da ga počnete koristiti na temelju određenih očekivanja. To je kao da naranču usporedite s vilicom. Sustavi baza podataka služe određenim svrhama. Najbolje je jednostavno sami razumjeti i cijeniti te razlike. Bila bi šteta vršiti pritisak na MongoDB programere zbog puta koji ih je natjerao na put DBMS-a. Želim vidjeti nove i zanimljive načine za rješavanje starih problema, kao što je osiguravanje integriteta podataka i stvaranje podatkovnih sustava koji su otporni na kvarove i zlonamjerne napade.
MongoDB-ovo uvođenje ACID transakcijske mogućnosti u verziji 4.0 dobar je primjer uvođenja važnih poboljšanja na inovativan način. Transakcije s više dokumenata i više navoda sada su atomske. Također je moguće prilagoditi vrijeme potrebno za dobivanje zaključavanja i prekid zaglavljenih transakcija, kao i promijeniti razinu izolacije.
Čitaj više:
Izvor: www.habr.com