14 gjëra që do doja të dija para fillimit të punës me MongoDB

Përkthimi i artikullit është përgatitur para fillimit të kursit «Baza të dhënash jo-releracionale».

14 gjëra që do doja të dija para fillimit të punës me MongoDB

Pikat kryesore:

  • ËshtĂ« jashtĂ«zakonisht e rĂ«ndĂ«sishme tĂ« zhvillohet njĂ« skemĂ«, megjithatĂ« nĂ« MongoDB ajo Ă«shtĂ« e optional.
  • Po ashtu, indekset duhet tĂ« korrespondojnĂ« me skemĂ«n tuaj dhe me shabllonet e aksesit.
  • Shmangni pĂ«rdorimin e objekteve tĂ« mĂ«dha dhe tĂ« grupeve tĂ« mĂ«dha.
  • BĂ«ni kujdes me cilĂ«simet e MongoDB, veçanĂ«risht kur bĂ«het fjalĂ« pĂ«r sigurinĂ« dhe besueshmĂ«rinĂ«.
  • NĂ« MongoDB nuk ka optimizues tĂ« pyetjeve, kĂ«shtu qĂ« duhet tĂ« jeni tĂ« kujdesshĂ«m gjatĂ« ekzekutimit tĂ« operacioneve tĂ« pyetjes.

Unë kam punuar me baza të dhënash për një kohë të gjatë, por vetëm së fundmi e kam zbuluar MongoDB. Ka disa gjëra që do të doja të dija para fillimit të punës me të. Kur një person ka përvojë në një fushë të caktuar, ai ka përfytyrime të paracaktuar mbi atë se çfarë janë bazat e të dhënave dhe çfarë bëjnë ato. Në shpresë për të lehtësuar kuptimin e individëve të tjerë, unë paraqes një listë të gabimeve të zakonshme.

Krijimi i një serveri MongoDB pa autentifikim

Fatkeqësisht, MongoDB inastohet pa autentifikim nga parazgjedhja. Për një stacion pune, aksesin e të cilit e sigurojmë lokal, kjo praktikë është e pranueshme. Por, përsa kohë që MongoDB është një sistem shumëpërdorues, që pëlqen të përdorë sasi të mëdha RAM-i, do të ishte më mirë ta vendosni atë në një server me sa më shumë RAM të mundshëm, edhe nëse do ta përdorni vetëm për zhvillim. Instalim në server përmes portit të parazgjedhur mund të jetë problematik, veçanërisht nëse në kërkesë mund të ekzekutohet çfarëdo kodi në javascript (p.sh. $where si një ide për injektimin).

Ekzistojnë disa metoda autentikimi, por më e lehta është të vendosni për përdoruesin ID/password. Përfitoni nga kjo ide, derisa të mendoni për një autentifikim më të çuditshëm të bazuar në LDAP. Nëse flasim për sigurinë, MongoDB duhet të azhurnohet vazhdimisht dhe log-et duhet gjithmonë të kontrollohen për qasje të paautorizuar. Për shembull, mua më pëlqen të zgjedh një port tjetër si portin e parazgjedhur.

Mos harroni të lidhni sipërfaqen e sulmit me MongoDB

Lista e kontrollit pĂ«r sigurimin e MongoDB pĂ«rdor kĂ«shilla tĂ« mira pĂ«r tĂ« ulur rrezikun e depĂ«rtimit nĂ« rrjet dhe tĂ« rrjedhjes sĂ« tĂ« dhĂ«nave. ËshtĂ« e lehtĂ« tĂ« heqĂ«sh dorĂ« dhe tĂ« thuash qĂ« serveri pĂ«r zhvillim nuk ka nevojĂ« pĂ«r njĂ« nivel tĂ« lartĂ« sigurie. MegjithatĂ«, gjĂ«rat nuk janĂ« kaq tĂ« thjeshta dhe kjo i pĂ«rket tĂ« gjithĂ« serverĂ«ve MongoDB. Sidomos, nĂ«se nuk ka arsye tĂ« forta pĂ«r tĂ« pĂ«rdorur mapReduce, grup ose $where, duhet tĂ« çaktivizoni pĂ«rdorimin e kodit tĂ« rastĂ«sishĂ«m nĂ« JavaScript duke shkruar nĂ« skedarin e konfigurimit javascriptEnabled:falsĂ«. Duke pasur parasysh se nĂ« MongoDB standard, skedarĂ«t e tĂ« dhĂ«nave nuk janĂ« tĂ« enkriptuar, Ă«shtĂ« e arsyeshme tĂ« drejtoni 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 tĂ« menaxhimit tĂ« aksesit nĂ« skedarĂ« tĂ« sistemit operativ.

Gabim në krijimin e skemës

MongoDB nuk përdor skemë. Por kjo nuk do të thotë që skema nuk është e nevojshme. Nëse dëshironi thjesht të ruani dokumente pa ndonjë skemë të qëndruar, është e mundur të ruani ato shpejt dhe lehtë, por t'i nxjerrni më pas mund të jetë maqedonisht e vështirë.

Artikulli klasik "6 rregulla empirike për projektimin e skemave MongoDB" ja vlen për t'u lexuar, dhe funksione të tilla si Schema Explorer në mjetin e jashtëm Studio 3T, është e vlefshme të përdoret për kontrollin e rregullt të skemave.

Mos harroni renditjen

Duke harruar renditjen, mund të zhgënjeheni më shumë se cilësdo konfigurim tjetër të gabuar. Nga përkufizimi, MongoDB përdor renditjen binar. Por është e vështirë të jetë e dobishme për dikë. Renditjet e ndjeshme ndaj rastit, akcentimit, ishin konsideruar kuriozitete anahronizmi së bashku me perla, kaftane dhe mjekra deri në vitet '80 të shekullit të kaluar. Tani përdorimi i tyre është i pafalshëm. Në të vërtetë, "motor" është e njëjta gjë si "Motor". Dhe "Britania" dhe "britania" janë e njëjta vend. Një shkronjë e vogël është thjesht ekuivalenti me shkronjën e madhe. Dhe mos më bëni të flas për renditjen e diakritikëve. Kur krijoni një bazë të të dhënave në MongoDB, përdorni parametrat e renditjes pa marrë parasysh akcentin dhe rastin, që i përkasin gjuhës dhe kulturës së përdoruesve të sistemit. Kështu do t'ju lehtësojë ndjeshëm kërkimin për të dhënat e vargjeve.

Krijimi i koleksioneve me dokumente të mëdha

MongoDB është e lumtur të vendosë dokumente të mëdha deri në 16 MB në koleksione, dhe GridFS është e dizajnuar për dokumente të mëdha më të mëdha se 16 MB. Por vetëm sepse dokumentet e mëdha mund të vendosen atje, ruajtja e tyre atje nuk është idea më e mirë. MongoDB do të funksionojë më mirë nëse ruani dokumente të veçanta me madhësi disa kilobajtësh, duke i konsideruar ato më shumë si rreshta në një tabelë të gjerë SQL. Dokumentet e mëdha do të jenë burim problemesh me performancën.

Krijimi i dokumenteve me masa të mëdha

Dokumentet mund të përmbajnë masa. Më mirë do të ishte nëse numri i elementeve në masë është larg nga numri katërshifror. Nëse elementet shtohen shpesh në masë, ajo do të kalojë dokumentin që e përmban, dhe do të duhet ta shkallëzoni, do të thotë se do të duhet të aktualizoni dhe indekset. Në rindeksimin e dokumentit me një masë të madhe, indekset shpesh do të rishkruhen, pasi për çdo element ekziston një shënim, që ruan indeksin e tij. Kjo rindeksim gjithashtu ndodh kur dokumenti injektohet ose fshihet.

Në MongoDB ka të ashtuquajturin «koeficient i mbushjes», që ofron hapësirë për rritjen e dokumenteve, për të minimizuar këtë problem.
Mund të mendoni se mund të kaloni pa indeksimin e masave. Fatkeqësisht, për shkak të mungesës së indekseve mund të keni probleme të tjera. Në masat, dokumentet shqyrtohen nga fillimi deri në fund, kërkimi i elementeve në fund të masës do të marrë më shumë kohë, dhe shumica e operacioneve të lidhura me një dokument të tillë do të jenë të ngadalta.

Mos harroni se rendi i fazave në agregimin ka rëndësi

Në një sistem të bazës së të dhënave me optimizues të pyetjeve, pyetjet që shkruani janë shpjegime se çfarë dëshironi të merrni, jo se si ta merrni atë. Ky mekanizëm funksionon në mënyrë të ngjashme me porosinë në një restorant: zakonisht porosisni vetëm një pjatë, jo t'i jepni kuzhinierit udhëzime të detajuara.

Në MongoDB ju udhëzoni kuzhinierin. Për shembull, duhet të siguroheni se të dhënat kalojnë përmes reduce sa më shpejt në pipeline me $match dhe $project, dhe renditja ndodh vetëm pas reduce, dhe se kërkimi ndodh saktësisht në rendin që ju nevojitet. Prania e një optimizuesi të pyetjeve, i cili eliminon punën e panevojshme, rendit optimalisht fazat dhe zgjedh llojin e lidhjes, mund t'ju bëjë të mërziteni. Në MongoDB keni më shumë kontroll mbi çmimin e komoditetit.

Mjetet si Studio 3T thjeshtojnë ndërtimin e pyetjeve të agregimit në MongoDB. Funkcioni Aggregation Editor ju lejon të aplikoni operatorë të pipeline-it një fazë në një kohë, si dhe të kontrolloni të dhënat hyrëse dhe dalëse në çdo fazë për të thjeshtuar debugging-un.

Përdorimi i shkruajtes së shpejtë

Kurrë mos vendosni në MongoDB parametrat e shkrimit me shpejtësi të lartë, por me besueshmëri të ulët. Ky mod "file-and-forget" duket i shpejtë, pasi ekipi kthehet para se të kryhet shkrimi. Nëse sistemi bie para se të dhënat të shkruhen në disk, ato do të humbasin dhe do të përfundojnë në një gjendje të papajtueshme. Fatmirësisht, në MongoDB 64-bit është e aktivizuar regjistrimi.

Motorët e ruajtjes MMAPv1 dhe WiredTiger përdorin regjistrimin për të parandaluar këtë, megjithatë WiredTiger mund të rikuperohet deri në pikën më të fundit të pajtueshmërisë kontrolli i pikës, nëse regjistrimi është i çaktivizuar.

Regjistrimi garanton që baza e të dhënave është në një gjendje të pajtueshme pas rikuperimit dhe ruan të gjitha të dhënat deri në momentin e regjistrimit në jurnal. Periodiciteti i regjistrimeve rregullohet me parametrin intervalliIangazhitMs.

Për t'u siguruar për regjistrimet, sigurohuni që regjistrimi të jetë i aktivizuar në skedarin e konfigurimit (storage.journal.enabled), dhe periodiciteti i regjistrimeve të jetë në përputhje me atë sasi informacioni që mund të përballoni të humbni.

Klasifikimi pa indeks

Në kërkim dhe agregim 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ë zvogëluar sasinë e të dhënave të klasifikuara. Edhe në atë rast, për klasifikimin do t'ju nevojitet indeksin. Mund të përdorni një indeks të vetëm ose të përbërë.

NĂ«se s’ka njĂ« indeks tĂ« pĂ«rshtatshĂ«m, MongoDB do ta kalojĂ« pa tĂ«. Ka njĂ« kufi memorjeje prej 32 MB nĂ« masĂ«n totale tĂ« tĂ« gjithĂ« dokumenteve nĂ« operacionin e klasifikimit, dhe nĂ«se MongoDB arrin kĂ«tĂ« kufi, ose do tĂ« japĂ« njĂ« gabim, ose do tĂ« kthejĂ« njĂ« grup tĂ« zbrazĂ«t regjistrimesh.

Kërkimi pa mbështetje indeksesh

Kërkesat e kërkimit kryejnë një funksion të ngjashëm me operacionin JOIN në SQL. Për të punuar më mirë, atyre u nevojitet indeksi i vlerës së çelësit, që përdoret si çelës i jashtëm. Kjo nuk është e qartë, pasi përdorimi nuk reflektohet në explain(). Këta indekse janë një plotësim i indeksit të regjistruar në explain(), i cili, nga ana e tij, përdoret nga operatorët e pipeline $match dhe $sort, kur ata shfaqen në fillim të pipeline. Indekset tani mund të përfshijnë çdo fazë të pipeline-it të grumbullimit.

Heqja dorë nga përdorimi i shumë-ndryshimeve

Sanitizer.replaceElementWithChildren() db.collection.update() përdoret për të ndryshuar një pjesë të dokumentit ekzistues ose të gjithë dokumentin, deri në një zëvendësim të plotë në varësi të parametrave që keni vendosur përditësim. Nuk është aq e qartë që ai nuk do të përpunojë të gjitha dokumentet në koleksion derisa të vendosni parametrin multi për të përditësuar të gjitha dokumentet që përmbushin kritereve të kërkesës.

Mos harroni rëndësinë e rendit të çelësave në tabelën hash

Në JSON, një objekt përbëhet nga një koleksion i pa renditur me zero ose më shumë çiftë emër/vlerë, ku emri është një varg, dhe vlera është një varg, numër, vlerë logjike, zero, objekt ose array.

Fatkeqësisht, BSON i jep rëndësi të madhe rendit gjatë kërkimeve. Në MongoDB, rendi i çelësave brenda objekteve të përfshira ka rëndësi, dmth. { firstname: "Phil", surname: "factor" } nuk është e njëjtë me { { surname: "factor", firstname: "Phil" }. Kështu që ju duhet të ruani rendin e çiftëve emër/vlerë në dokumente nëse dëshironi të jeni të sigurt që do t'i gjeni ato.

Mos e ngatërroni "null" dhe "undefined"

Vlera "undefined" nuk ka qenë kurrë e lejuar në JSON, sipas standardit zyrtar JSON (ECMA-404, Seksioni 5), megjithëse përdoret në JavaScript. Më tepër, për BSON, ajo është e përjetshme dhe konvertohet në $null, që nuk është gjithmonë një zgjidhje e mirë. Shmangni përdorimin e "undefined" në MongoDB.

Përdorimi $limit() pa $sort()

Shpesh, kur zhvilloni në MongoDB, është e dobishme të shihni një shembull rezultati që do të kthehet nga kërkesa ose grumbullimi. Për këtë detyrë do t'ju nevojitet $limit(), por ajo nuk duhet të jetë kurrë në versionin përfundimtar të kodit, nëse para saj nuk përdorni $sortKjo mekanikë është e nevojshme, pasi ndryshe nuk mund të garantoni rendin e rezultatëve dhe nuk do të jeni në gjendje të shihni të dhënat me besueshmëri. Në pjesën e sipërme të rezultateve do të merrni regjistrime të ndryshme në varësi të rendit. Për të punuar në mënyrë të besueshme, kërkesat dhe agregimet duhet të jenë deterministe, domethënë duhet të japin rezultate të njëjta me çdo ekzekutim. Kodi, në të cilin ka $limit(), por nuk ka $sort, nuk do të jetë deterministik dhe më vonë mund të shkaktojë gabime që do të jenë të vështira për t'u ndjekur.

Përfundim

MĂ«nyra e vetme pĂ«r tĂ« qenĂ« i zhgĂ«njyer nga MongoDB Ă«shtĂ« ta krahasosh atĂ« drejtpĂ«rdrejt me njĂ« lloj tjetĂ«r bazash tĂ« dhĂ«nash, si DBMS, ose tĂ« fillosh ta pĂ«rdorĂ«sh atĂ« duke u bazuar nĂ« disa pritshmĂ«ri tĂ« caktuara. ËshtĂ« si tĂ« krahasosh njĂ« portokall me njĂ« pirun. Sistemet e tĂ« dhĂ«nave ndjekin qĂ«llime tĂ« caktuara. MĂ« mirĂ« Ă«shtĂ« thjesht tĂ« kuptosh dhe vlerĂ«sosh pĂ«r vete kĂ«to dallime. Do tĂ« ishte turp tĂ« ushtrohej presion mbi zhvilluesit e MongoDB pĂ«r shkak tĂ« rrugĂ«s qĂ« i detyroi tĂ« ndjekin rrugĂ«n e DBMS. Do tĂ« doja tĂ« shihja mĂ«nyra tĂ« reja dhe interesante pĂ«r tĂ« zgjidhur problemet e vjetra, si sigurimi i integritetit tĂ« tĂ« dhĂ«nave dhe krijimi i sistemeve tĂ« tĂ« dhĂ«nave qĂ« janĂ« tĂ« qĂ«ndrueshme ndaj defekteve dhe sulmeve tĂ« keqbĂ«rĂ«sve.

Zgjedhja e ACID dhe tranzaksionet në MongoDB në versionin 4.0 janë një shembull i mirë i integrimit të përmirësimeve të rëndësishme në një mënyrë inovative. Transaksionet shumë dokumentale dhe shumë operatorike tani janë atomike. Gjithashtu, është bërë e mundur të rregullohet koha e nevojshme për të marrë bllokime dhe për të përfunduar transaksionet e varura, si dhe të ndryshohet niveli i izolimit.

14 gjëra që do doja të dija para fillimit të punës me MongoDB

Lexoni më shumë:

Burimi: habr.com

Blini hosting tĂ« besueshĂ«m pĂ«r faqe interneti me mbrojtje nga DDoS, serverĂ« VPS VDS đŸ”„ Blini hosting tĂ« besueshĂ«m pĂ«r faqe interneti me mbrojtje nga DDoS, serverĂ« VPS VDS | ProHoster