Përkthimi i artikullit është përgatitur në prag të fillimit të kursit .
Pikat kryesore:
- Është jashtëzakonisht e rëndësishme të zhvilloni një skemë, ndonëse në MongoDB ajo nuk është e detyrueshme.
- Po ashtu, indekset duhet të përputhen me skemën tuaj dhe modelet e aksesit.
- Kujdesuni për përdorimin e objekteve të mëdha dhe array-eve të mëdha.
- Jini të kujdesshëm me konfigurimet e MongoDB, veçanërisht kur bëhet fjalë për sigurinë dhe besueshmërinë.
- Në MongoDB nuk ka optimizues kërkimesh, prandaj duhet të jeni të kujdesshëm gjatë ekzekutimit të operacioneve të kërkimit.
Kam punuar me baza të dhënash për shumë kohë, por vetëm së fundmi zbulova MongoDB. Ka disa gjëra që do doja të dija para se të filloja të punoja me të. Kur një person ka përvojë në një fushë të caktuar, ai krijon një ide paraprake për atë që janë bazat e të dhënave dhe çfarë bëjnë ato. Në shpresë për të lehtësuar kuptimin për të tjerët, po paraqes një listë të gabimeve të zakonshme.
Krijimi i një serveri MongoDB pa autentifikim
Fatkeq, MongoDB në mënyrë default instalohet pa autentifikim. Për një punonjës që aksesin e tij e krijon lokal, kjo praktikë është e pranueshme. Por, duke qenë se MongoDB është një sistem me shumë përdorues që kërkon shumë memorie, do të ishte më mirë ta instaloni atë në një server me sa më shumë memorie RAM në kushtet tuaja, edhe nëse e keni vetëm për zhvillim. Instalimi në server përmes portit default mund të jetë problematik, veçanërisht nëse kërkesa mund të ekzekutojë ndonjë kod në javascript (p.sh., $where si një ide për ).
Ka disa metoda autentifikimi, por mënyra më e lehtë është të vendosni ID/në password për përdoruesin. Përdorni këtë ide derisa të mendoni për autentifikimin më të sofistikuar të bazuar në . Kur flasim për sigurinë, MongoDB duhet të përditësohet vazhdimisht dhe log-et duhet të kontrollohen gjithmonë për akses të paautorizuar. Për shembull, më pëlqen të zgjedh një port tjetër si portin default.
Mos harroni të lidhni sipërfaqen e sulmit me MongoDB
përmban këshilla të mira për të zvogëluar rrezikun e depërtimit në rrjet dhe rrjedhjes së të dhënave. Është e lehtë të thuash se një server për zhvillim nuk ka nevojë për një nivel të lartë sigurie. Megjithatë, situata është më e komplikuar dhe kjo i përket të gjithë serverëve MongoDB. Në veçanti, nëse nuk ka një arsyetim të fortë për të përdorur , ose , duhet të çaktivizohet përdorimi i kodit të rastësishëm në JavaScript, duke shkruar në skedarin e konfigurimit . Duke qenë se skedarët e të dhënave në MongoDB standarde nuk janë të koduar, është e arsyeshme të funksionojë MongoDB me , i cili ka qasje të plotë në skedarë, me qasje të kufizuar vetëm për të dhe mundësinë për të përdorur mjetet e tij për menaxhimin e qasjes në skedarët e sistemit operativ.
Gabim në projektimin e skemës
MongoDB nuk përdor skemë. Por kjo nuk do të thotë se skema nuk është e nevojshme. Nëse dëshiron të ruash dokumentet thjesht pa një skemë të koherente, mund t'i ruash ato shpejt dhe lehtë, por të nxjerrësh ato më vonë mund të jetë .
Artikulli klasik " vlen për t'u lexuar, dhe funksione të tilla si në mjetin e jashtëm Studio 3T, është e rekomandueshme për kontrolle të rregullta të skemave.
Mos harroni rendin e renditjes
Duke harruar rendin e renditjes mund të zhgënjeheni më së shumti dhe të humbni më shumë kohë sesa me përdorimin e çdo konfigurimi tjetër të gabuar. Për default MongoDB përdor . Por shumë pak do të jetë e dobishme për dikë. Renditjet e ndjeshme ndaj shkronjave të mëdha, theksit, renditjet binarë u konsideruan si kuriozitete anahronike krahas me perlat, kafanot dhe mustakët që përkulet ende në vitet '80 të shekullit të kaluar. Tani përdorimi i tyre është i pajustifikueshëm. Në jetën reale, "motor" është e njëjta gjë me "Motor". Ndërsa "Britania" dhe "britania" janë të njëjtat vende. Shkronja e vogël është thjesht ekvivalenti i shkronjës së madhe. Dhe mos më detyroni të flas për renditjen e shenjave diakritike. Kur krijoni një bazë të dhënash në MongoDB, përdorni parametra renditjeje që nuk marrin parasysh theksin dhe , të cilat i përkasin gjuhës dhe . Kështu do ta thjeshtoni ndjeshëm kërkimin në të dhënat string.
Krijimi i koleksioneve me dokumente të mëdha
MongoDB është e lumtur të prijë dokumente të mëdha deri në 16 MB në koleksione, ndërsa është e dizajnuar për dokumente të mëdha që janë më të mëdha se 16 MB. Por vetëm sepse dokumente të mëdha mund të ruhen atje, ruajtja e tyre atje nuk është ideja më e mirë. MongoDB do të funksionojë më mirë nëse ruani dokumente të veçanta me përmasat disa kilobajtë, duke i konsideruar ato më shumë si rreshta në një tabelë të gjerë SQL. Dokumentet e mëdha do të shkaktojnë probleme me .
Krijimi i dokumenteve me njësi të mëdha
Dokumentet mund të përmbajnë njësi. Më mirë është që numri i elementeve në njësi të jetë larg një numri katërshifror. Nëse elementet shtohen shpesh në njësi, ajo do të tejkalojë dokumentin përmbajtës dhe do të duhet të , që do të thotë se do të duhet të . Gjatë rishtypjes së dokumentit me njësi të mëdha, indekset shpesh do të ri-shkruhen, pasi për çdo element ekziston një , që ruan indeksin e tij. Kjo riindeksim ndodh gjithashtu kur dokumenti futet ose fshihet.
Në MongoDB ka atë që quhet , i cili ofron hapësirë për rritjen e dokumenteve, në mënyrë që të minimizoni këtë problem.
Mund të mendoni se mund të përballoni pa indekset e vargjeve. Fatkeqësisht, për shkak të mungesës së indekseve, mund të shfaqen probleme të tjera. Çdokush nga dokumentet shqyrtohet nga fillimi në fund, kështu që kërkimi i elementeve në fund të vargut do të zgjasë më shumë kohë, dhe shumica e operacioneve të lidhura me këtë dokument do të jenë .
Mos harroni se rendi i fazave në agregim ka rëndësi
Në një sistem baze të dhënash me optimizues pyetjesh, pyetjet që shkruani janë shpjegime për atë që dëshironi të merrni, jo për mënyrën se si ta merrni. Ky mekanizëm funksionon si një porosi në një restorant: zakonisht porosisni një pikë, jo jepni udhëzime të detajuara për kuzhinierin.
Në MongoDB ju jepni udhëzime kuzhinierit. Për shembull, duhet të siguroheni që të dhënat kalojnë përmes reduce sa më shpejt të jetë e mundur në pipeline me $match dhe $project, dhe renditja ndodh vetëm pas reduce, dhe që kërkimi ndodh në rendin e saktë që ju nevojitet. Prania e një optimizuesi të pyetjeve, i cili eliminon punët e panevojshme, organizon në mënyrë optimale fazat dhe zgjedh lidhjen, mund t'ju bëjë të keni komoditet. Në MongoDB, ju fitoni më shumë kontroll mbi çmimin e lehtësisë.
Mjetet si do ta thjeshtojnë ndërtimin e pyetjeve të agregimit në . Funksioni Aggregation Editor do t'ju lejojë të aplikoni operatorët e tërheqjes fazë pas faze, përveç se të kontrolloni të dhënat hyrëse dhe dalëse në çdo fazë për të lehtësuar debugin.
Përdorimi i regjistrimit të shpejtë
Mos e vendosni kurrë në MongoDB parametër regjistrimi me shpejtësi të lartë, por besueshmëri të ulët. Ky modalitet "file-and-forget" duket i shpejtë, pasi ekipi kthehet para se të regjistrohet. Nëse sistemi bie para se të dhënat të regjistrohen në disk, ato do të humbasin dhe do të përfundojnë në një gjendje të papërshtatshme. Shtë e fatshme që në MongoDB me 64-bit është përfshirë regjistrimi.
Motoret për ruajtje MMAPv1 dhe WiredTiger përdorin regjistrimin për të parandaluar këtë, ndonëse WiredTiger mund të rimarrë deri në pikën e fundit tërësore , nëse regjistrimi është çaktivizuar.
Regjistrimi garanton që baza e të dhënave është në një gjendje të harmonizuar pas rivendosjes dhe ruan të gjitha të dhënat deri në momentin e regjistrimit. Periudha e regjistrimeve rregullohet me parametër .
Për të siguruar regjistrimet, sigurohuni që në skedarin e konfigurimit regjistrimi të jetë i aktivizuar ), dhe periudha e regjistrimeve korrespondon me sasinë e informacionit që mund të përballoni të humbni.
Klasifikimi pa indeks
Gjatë kërkimit dhe agregimit shpesh lind nevoja për klasifikimin e të dhënave. Shpresojmë se kjo bëhet në një nga fazat përfundimtare, pas filtrimit të rezultatit për të reduktuar sasinë e të dhënave që do të klasifikohen. Edhe në këtë rast ju nevojitet . Mund të përdorni një indeks të vetme ose të përbërë.
Nëse nuk ka një indeks të përshtatshëm, MongoDB do të kalojë pa të. Ekziston një kufi memorie prej 32 MB për madhësinë totale të të gjitha dokumenteve në , dhe nëse MongoDB arrin këtë kufi, atëherë ajo do të japë një gabim ose do të kthejë .
Kërkimi pa mbështetje për indeksi
Kërkesat e kërkimit kryejnë një funksion të ngjashëm me operacionin JOIN në SQL. Për një funksionim më të mirë, ata kanë nevojë për një indeks të vlerës së çelësit, i përdorur si çelës jashtë. Kjo nuk është e qartë, pasi përdorimi nuk pasqyrohet në explain(). Këto indekse janë një shtesë ndaj indeksit të shkruar në explain(), i cili, nga ana e tij, përdoret nga operatorët e pipeline-it $match dhe $sort, kur ata shfaqen në fillim të pipeline-it. Indekset tani mund të mbulojnë çdo fazë .
Heqja e përdorimit të multi-aktualizimeve
Metoda përdoret për të ndryshuar një pjesë të dokumentit ekzistues ose të tërë dokumentin, deri në zëvendësimin e plotë në varësi të parametrave që keni caktuar . Nuk është aq e qartë se ai nuk do të përpunojë të gjitha dokumentet në koleksion derisa të vendosni parametrin për të përditësuar të gjitha dokumentet që përmbushin kriteret e kërkesës.
Mos harroni rëndësinë e rendit të çelësave në tabelën hash.
Në JSON, objekti përbëhet nga një koleksion i çiftave emër/vlerë të pa renditur, me zero ose më shumë elemente, ku emri është një varg dhe vlera është një varg, numër, vlerë logjike, zero, objekt ose array.
Fatkeq, BSON i përgjigjet shumë rëndësisë së rendit në kërkesa. Në MongoDB, rendi i çelësave brenda objekteve të integruara , pra, { firstname: "Phil", surname: "factor" } nuk është e njëjtë me { { surname: "factor", firstname: "Phil" }. Kjo do të thotë se duhet të ruani rendin e çifteve emër/vlerë në dokumente, nëse dëshironi të siguroni që do t'i gjeni ato.
Mos ngatërroni "null" dhe "undefined"
Vlera "undefined" nuk ka qenë kurrë e vlefshme në JSON, sipas JSON (ECMA-404, Seksioni 5), pavarësisht se është përdorur në JavaScript. Për më tepër, për BSON është i vjetruar dhe shndërrohet në $null, që nuk është gjithmonë një zgjidhje e mirë. .
Përdorimi $limit() pa $sort()
Shumë shpesh, kur zhvilloni në MongoDB, është e dobishme të shihni thjesht një shembull të rezultatit që do të kthehet nga kërkesa ose agregimi. Për këtë detyrë do t'ju nevojitet $limit(), por nuk duhet të jetë kurrë në versionin përfundimtar të kodit, përveç nëse e përdorni para tij $sort. Kjo mekanizëm është e nevojshme, sepse ndryshe nuk mund të garantoni renditjen e rezultatit, dhe nuk do të jeni në gjendje të shqyrtoni të dhënat në mënyrë të besueshme. Në krye të rezultatit, do të merrni regjistrime të ndryshme në varësi të renditjes. Për funksionim të besueshëm, kërkesa dhe agregimet duhet të jenë të përcaktuara, që do të thotë se duhet të japin rezultate të njëjta në çdo ekzekutim. Kodi që ka $limit(), por nuk ka $sort, nuk do të jetë i përcaktuar dhe më vonë mund të shkaktojë gabime, të cilat do të jenë të vështira për t'u ndjekur.
Përfundimi
Një nga mënyrat për të humbur besimin te MongoDB është ta krahasosh atë drejtpërdrejt me një lloj tjetër databaze, siç është një SGBD, ose të fillosh ta përdorësh duke pasur ndonjë pritet të caktuar. Është sikur të krahasosh një portokall me një pirun. Sistemet e databazës kanë qëllime të caktuara. Më mirë është thjesht të kuptosh dhe të vlerësosh këto dallime për veten. Do të ishte turp t'i kërkosh zhvilluesve të MongoDB të ndjekin rrugën që i detyron të ndjekin SGBD-të. Dua të shoh mënyra të reja dhe interesante për të zgjidhur probleme të vjetra, si sigurimi i integritetit të të dhënave dhe krijimi i sistemeve të dhënash që janë të qëndrueshme ndaj dështimeve dhe sulmeve të keqbërësve.
Implementimi i ACID transactionalitetit në MongoDB në versionin 4.0 është një shembull i mirë i implementimit të përmirësimeve të rëndësishme në mënyrë inovative. Transaksionet shumë-dokumentale dhe shumë-operatorësh tani janë atomare. Po ashtu është bërë e mundur të rregullohet koha e nevojshme për të marrë bllokime dhe për të përfunduar transaksionet që kanë ngecur, si dhe për të ndryshuar nivelin e izolimit.
Lexoni më shumë:
Burimi: habr.com
