14 gjëra që do doja të dija para se të filloja të punoja me MongoDB

Përkthimi i artikullit është përgatitur në prag të fillimit të kursit «Baza të dhënash jo-relacionale».

14 gjëra që do doja të dija para se të filloja të punoja me MongoDB

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 injeksionit).

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ë LDAP. 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

Lista e kontrollit pĂ«r sigurimin e 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 mapReduce, grup ose $where, duhet tĂ« çaktivizohet pĂ«rdorimi i kodit tĂ« rastĂ«sishĂ«m nĂ« JavaScript, duke shkruar nĂ« skedarin e konfigurimit javascriptEnabled:false. Duke qenĂ« se skedarĂ«t e tĂ« dhĂ«nave nĂ« MongoDB standarde nuk janĂ« tĂ« koduar, Ă«shtĂ« e arsyeshme tĂ« funksionojĂ« MongoDB me PĂ«rdorues tĂ« Dedikuar, 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ë tejet e vështirë.

Artikulli klasik "6 rregulla empirike për projektimin e skemave MongoDB" vlen për t'u lexuar, dhe funksione të tilla si Eksplorues i Skemës 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 renditje binarë. 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 sensin e shkronjave, të cilat i përkasin gjuhës dhe kulturës së përdoruesve të sistemit. 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 GridFS ë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 performancën.

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ë shkarkohet, që do të thotë se do të duhet të përditësohen dhe indekset. Gjatë rishtypjes së dokumentit me njësi të mëdha, indekset shpesh do të ri-shkruhen, pasi për çdo element ekziston një shënim, që ruan indeksin e tij. Kjo riindeksim ndodh gjithashtu kur dokumenti futet ose fshihet.

Në MongoDB ka atë që quhet «koeficient i mbushjes», 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Ă« tĂ« ngadalshme.

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 Studio 3T do ta thjeshtojnë ndërtimin e pyetjeve të agregimit në MongoDB. 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 kontrolluese, 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 commitIntervalMs.

Për të siguruar regjistrimet, sigurohuni që në skedarin e konfigurimit regjistrimi të jetë i aktivizuar (storage.journal.enabled), 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 indeksin. 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ë operacionin e klasifikimit, dhe nëse MongoDB arrin këtë kufi, atëherë ajo do të japë një gabim ose do të kthejë një grup regjistrimesh të zbrazët.

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ë të pipeline-it të agregimit.

Heqja e përdorimit të multi-aktualizimeve

Metoda db.collection.update() 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 update. Nuk është aq e qartë se ai nuk do të përpunojë të gjitha dokumentet në koleksion derisa të vendosni parametrin multiple 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 ka rëndësi, 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 standardeve zyrtare 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ë. Shmangni përdorimin e "undefined" në MongoDB.

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.

14 gjëra që do doja të dija para se të filloja të punoja me MongoDB

Lexoni më shumë:

Burimi: habr.com

Bli njĂ« hosting tĂ« besueshĂ«m pĂ«r faqet me mbrojtje DDoS, VPS VDS serverĂ« đŸ”„ Bli njĂ« hosting tĂ« besueshĂ«m pĂ«r faqet me mbrojtje DDoS, VPS VDS serverĂ« | ProHoster