Përkthimi i artikullit u përgatit në prag të fillimit të kursit .
Pikat kryesore:
- Është jashtëzakonisht e rëndësishme të zhvillohet një skemë edhe pse është opsionale në MongoDB.
- Në mënyrë të ngjashme, indekset duhet të përputhen me skemën tuaj dhe modelet e aksesit.
- Shmangni përdorimin e objekteve të mëdha dhe grupeve të mëdha.
- Jini të kujdesshëm me cilësimet e MongoDB, veçanërisht kur bëhet fjalë për sigurinë dhe besueshmërinë.
- MongoDB nuk ka një optimizues të pyetjeve, kështu që duhet të jeni të kujdesshëm kur kryeni operacionet e pyetjeve.
Unë kam punuar me bazat e të dhënave për një kohë shumë të gjatë, por MongoDB e kam zbuluar vetëm së fundmi. Ka disa gjëra që do të doja t'i dija përpara se të filloja të punoja me të. Kur një person tashmë ka përvojë në një fushë të caktuar, ai ka ide të paracaktuara se çfarë janë bazat e të dhënave dhe çfarë bëjnë. Me shpresën për ta bërë më të lehtë për të tjerët të kuptojnë, unë paraqes një listë të gabimeve të zakonshme.
Krijimi i një serveri MongoDB pa vërtetim
Fatkeqësisht, MongoDB është instaluar pa vërtetim si parazgjedhje. Për një stacion pune të aksesuar në nivel lokal, kjo praktikë është normale. Por duke qenë se MongoDB është një sistem me shumë përdorues që i pëlqen të përdorë sasi të mëdha memorie, do të jetë më mirë nëse e vendosni në një server me sa më shumë RAM që të jetë e mundur, edhe nëse do ta përdorni vetëm për zhvillim. Instalimi në server nëpërmjet portit të paracaktuar mund të jetë problematik, veçanërisht nëse ndonjë kod javascript mund të ekzekutohet në kërkesë (për shembull, $where si një ide për ).
Ka disa metoda të vërtetimit, por më e thjeshta është të vendosni një ID/fjalëkalim të përdoruesit. Përdoreni këtë ide ndërsa mendoni për vërtetimin e zbukuruar bazuar në . Kur bëhet fjalë për sigurinë, MongoDB duhet të përditësohet vazhdimisht dhe regjistrat duhet të kontrollohen gjithmonë për akses të paautorizuar. Për shembull, më pëlqen të zgjedh një port tjetër si portin e paracaktuar.
Mos harroni të lidhni sipërfaqen tuaj të sulmit me MongoDB
përmban këshilla të mira për reduktimin e rrezikut të ndërhyrjes në rrjet dhe rrjedhjes së të dhënave. Është e lehtë ta heqësh atë dhe të thuash se një server zhvillimi nuk ka nevojë për një nivel të lartë sigurie. Sidoqoftë, nuk është aq e thjeshtë dhe kjo vlen për të gjithë serverët MongoDB. Në veçanti, nëse nuk ka arsye bindëse për t'u përdorur , ose , duhet të çaktivizoni përdorimin e kodit arbitrar në JavaScript duke shkruar në skedarin e konfigurimit . Meqenëse skedarët e të dhënave nuk janë të koduar në MongoDB standarde, ka kuptim të ekzekutoni MongoDB me , i cili ka akses të plotë në skedarë, me akses të kufizuar vetëm në të dhe aftësinë për të përdorur kontrollet e vetë sistemit operativ për aksesin e skedarëve.
Gabim gjatë zhvillimit të qarkut
MongoDB nuk përdor një skemë. Por kjo nuk do të thotë se skema nuk është e nevojshme. Nëse thjesht dëshironi të ruani dokumente pa ndonjë model të qëndrueshëm, ruajtja e tyre mund të jetë e shpejtë dhe e lehtë, por marrja e tyre më vonë mund të jetë e vështirë. .
Artikull klasik " Ia vlen të lexohet dhe veçori të tilla në mjetin e palës së tretë Studio 3T, ia vlen të përdoret për kontrolle të rregullta të qarqeve.
Mos harroni rendin e renditjes
Harrimi i renditjes së renditjes mund të shkaktojë më shumë zhgënjim dhe humbje më shumë kohë se çdo konfigurim tjetër i gabuar. Si parazgjedhje MongoBD përdor . Por nuk ka gjasa të jetë e dobishme për askënd. Llojet binare të ndjeshme ndaj shkronjave të vogla, të ndjeshme ndaj theksit u konsideruan si anakronizma kurioz së bashku me rruaza, kaftanë dhe mustaqe kaçurrela në vitet '80 të shekullit të kaluar. Tani përdorimi i tyre është i pafalshëm. Në jetën reale, "motoçikleta" është e njëjtë me "Motoçikletën". Dhe "Britania" dhe "Britania" janë i njëjti vend. Një shkronjë e vogël është thjesht ekuivalenti i madh i një shkronje të madhe. Dhe mos më bëni të filloj me renditjen e diakritikëve. Kur krijoni një bazë të dhënash në MongoDB, përdorni kombinime të pandjeshme ndaj theksit dhe , të cilat i përgjigjen gjuhës dhe . Kjo do ta bëjë shumë më të lehtë kërkimin përmes të dhënave të vargut.
Krijoni koleksione me dokumente të mëdha
MongoDB është i lumtur të presë dokumente të mëdha deri në 16 MB në koleksione, dhe Projektuar për dokumente të mëdha më të mëdha se 16 MB. Por vetëm për shkak se dokumentet e mëdha mund të vendosen atje, ruajtja e tyre atje nuk është një ide e mirë. MongoDB do të funksionojë më mirë nëse ruani dokumente individuale me madhësi disa kilobajt, duke i trajtuar ato më shumë si rreshta në një tabelë të gjerë SQL. Dokumentet e mëdha do të jenë burim problemesh .
Krijimi i dokumenteve me vargje të mëdha
Dokumentet mund të përmbajnë vargje. Është më mirë nëse numri i elementeve në grup është larg një numri katërshifror. Nëse elemente shtohen shpesh në një grup, ai do të tejkalojë dokumentin që e përmban dhe do të duhet të jetë , që do të thotë se do të jetë e nevojshme . Kur riindeksoni një dokument me një grup të madh, indekset shpesh do të mbishkruhen, pasi ekziston një , e cila ruan indeksin e saj. Ky riindeksim ndodh gjithashtu kur një dokument futet ose fshihet.
MongoDB ka diçka të quajtur , e cila ofron hapësirë për rritjen e dokumenteve për të minimizuar këtë problem.
Ju mund të mendoni se mund të bëni pa indeksimin e grupeve. Fatkeqësisht, mungesa e indekseve mund t'ju shkaktojë probleme të tjera. Meqenëse dokumentet skanohen nga fillimi në fund, kërkimi i elementeve në fund të grupit do të zgjasë më shumë dhe shumica e operacioneve që lidhen me një dokument të tillë do të jenë .
Mos harroni se renditja e fazave në një grumbullim ka rëndësi
Në një sistem bazë të dhënash me një optimizues të pyetjeve, pyetjet që shkruani janë shpjegime të asaj që dëshironi të merrni, jo si ta merrni atë. Ky mekanizëm funksionon në analogji me porosinë në një restorant: zakonisht ju thjesht porosisni një pjatë dhe nuk i jepni udhëzime të hollësishme kuzhinierit.
Në MongoDB, ju udhëzoni kuzhinierin. Për shembull, duhet të siguroheni që të dhënat të kalojnë reduce sa më shpejt që të jetë e mundur në tubacion duke përdorur $match и $project, dhe renditja ndodh vetëm pas reduce, dhe se kërkimi ndodh pikërisht sipas rendit që dëshironi. Pasja e një optimizuesi të pyetjeve që eliminon punën e panevojshme, rendit në mënyrë optimale hapat dhe zgjedh llojet e bashkimeve mund t'ju prishë. Me MongoDB, ju keni më shumë kontroll me koston e komoditetit.
Mjete si do të thjeshtojë ndërtimin e pyetjeve të grumbullimit në . Funksioni i Redaktuesit të Përmbledhjes ju lejon të aplikoni deklaratat e tubacionit një fazë në të njëjtën kohë dhe të inspektoni të dhënat hyrëse dhe dalëse në çdo fazë për të thjeshtuar korrigjimin.
Përdorimi i Regjistrimit të Shpejtë
Asnjëherë mos i vendosni opsionet e shkrimit MongoDB që të kenë shpejtësi të lartë, por besueshmëri të ulët. Kjo mënyrë "skedar-dhe-harro" duket e shpejtë sepse komanda kthehet përpara se të ndodhë shkrimi. Nëse sistemi prishet përpara se të dhënat të shkruhen në disk, ai do të humbasë dhe do të përfundojë në një gjendje jokonsistente. Për fat të mirë, MongoDB 64-bit ka aktivizuar regjistrimin.
Motorët e ruajtjes MMAPv1 dhe WiredTiger përdorin regjistrimin për ta parandaluar këtë, megjithëse WiredTiger mund të rikuperohet deri në konsistencën e fundit , nëse regjistrimi është i çaktivizuar.
Gazetari siguron që baza e të dhënave të jetë në një gjendje të qëndrueshme pas rikuperimit dhe ruan të gjitha të dhënat derisa të shkruhet në regjistër. Frekuenca e regjistrimeve konfigurohet duke përdorur parametrin .
Për të qenë të sigurt për hyrjet, sigurohuni që regjistrimi të jetë i aktivizuar në skedarin e konfigurimit ), dhe frekuenca e regjistrimeve korrespondon me sasinë e informacionit që mund të përballoni të humbni.
Renditja pa indeks
Kur kërkoni dhe grumbulloni, shpesh lind nevoja për të renditur të dhënat. Le të shpresojmë që kjo të bëhet në një nga fazat përfundimtare, pas filtrimit të rezultatit për të zvogëluar sasinë e të dhënave që renditen. Dhe edhe në këtë rast, për renditje do t'ju duhet . Ju mund të përdorni një indeks të vetëm ose të përbërë.
Nëse nuk ka indeks të përshtatshëm, MongoDB do të bëjë pa të. Ekziston një kufi memorie prej 32 MB në madhësinë totale të të gjithë dokumenteve në , dhe nëse MongoDB e arrin këtë kufi, atëherë ose do të hedhë një gabim ose do të kthehet .
Kërkoni pa mbështetjen e indeksit
Pyetjet e kërkimit kryejnë një funksion të ngjashëm me operacionin JOIN në SQL. Për të punuar më mirë, ata kanë nevojë për indeksin e vlerës së çelësit të përdorur si çelës i huaj. Kjo nuk është e qartë sepse përdorimi nuk reflektohet në explain(). Indekse të tillë janë përveç indeksit të shkruar në explain(), i cili nga ana tjetër përdoret nga operatorët e tubacioneve $match и $sort, kur takohen në fillim të tubacionit. Indekset tani mund të mbulojnë çdo fazë .
Tërheqja nga përdorimi i shumëpërditësimeve
Метод përdoret për të ndryshuar një pjesë të një dokumenti ekzistues ose të gjithë dokumentin, deri në një zëvendësim të plotë, në varësi të parametrit që specifikoni . Ajo që nuk është aq e dukshme është se nuk do të përpunojë të gjitha dokumentet në koleksion nëse nuk e vendosni opsionin për të përditësuar të gjitha dokumentet që plotësojnë kriteret e kërkesës.
Mos harroni rëndësinë e renditjes së çelësave në një tabelë hash
Në JSON, një objekt përbëhet nga një koleksion i parregulluar i çifteve me madhësi zero ose më shumë emër/vlerë, ku emri është një varg dhe vlera është një varg, numër, boolean, null, objekt ose grup.
Fatkeqësisht, BSON i kushton shumë theks renditjes kur kërkon. Në MongoDB, rendi i çelësave brenda objekteve të integruara , dmth { firstname: "Phil", surname: "factor" } - kjo nuk është njësoj si { { surname: "factor", firstname: "Phil" }. Kjo do të thotë, duhet të ruani rendin e çifteve të emrit/vlerës në dokumentet tuaja nëse dëshironi të jeni të sigurt për gjetjen e tyre.
Mos u ngatërroni "I pavlefshëm" и "e pacaktuar"
Vlerë "e pacaktuar" nuk ishte kurrë e vlefshme në JSON, sipas JSON (ECMA-404 Seksioni 5), edhe pse përdoret në JavaScript. Për më tepër, për BSON është i vjetëruar dhe është konvertuar në $null, e cila nuk është gjithmonë një zgjidhje e mirë. .
Përdorim $limit() pa $sort()
Shumë shpesh kur jeni duke u zhvilluar në MongoDB, është e dobishme të shihni vetëm një mostër të rezultatit që do të kthehet nga një pyetje ose grumbullim. Për këtë detyrë do t'ju duhet $limit(), por nuk duhet të jetë kurrë në kodin përfundimtar nëse nuk e përdorni më parë $sort. Ky mekanik është i nevojshëm sepse përndryshe nuk mund të garantoni renditjen e rezultatit dhe nuk do të jeni në gjendje t'i shikoni me besueshmëri të dhënat. Në krye të rezultatit do të merrni hyrje të ndryshme në varësi të renditjes. Për të punuar me besueshmëri, pyetjet dhe grumbullimet duhet të jenë përcaktuese, domethënë të prodhojnë të njëjtat rezultate sa herë që ekzekutohen. Kodi që përmban $limit(), por jo $sort, nuk do të jetë përcaktues dhe mund të shkaktojë më pas gabime që do të jenë të vështira për t'u gjetur.
Përfundim
Mënyra e vetme për t'u zhgënjyer me MongoDB është ta krahasoni atë drejtpërdrejt me një lloj tjetër të bazës së të dhënave, siç është një DBMS, ose të vini në përdorimin e tij bazuar në pritshmëri të caktuara. Është si të krahasosh një portokall me një pirun. Sistemet e bazave të të dhënave shërbejnë për qëllime specifike. Është më mirë që thjesht t'i kuptoni dhe vlerësoni këto dallime për veten tuaj. Do të ishte turp të bëni presion mbi zhvilluesit e MongoDB për një rrugë që i detyroi ata të zbrisnin në rrugën DBMS. Unë dua të shoh mënyra të reja dhe interesante për të zgjidhur problemet e vjetra, të tilla si sigurimi i integritetit të të dhënave dhe krijimi i sistemeve të të dhënave që janë elastike ndaj dështimeve dhe sulmeve me qëllim të keq.
Prezantimi i transaksioneve ACID nga MongoDB në versionin 4.0 është një shembull i mirë i prezantimit të përmirësimeve të rëndësishme në një mënyrë inovative. Transaksionet me shumë dokumente dhe me shumë deklarata tani janë atomike. Është gjithashtu e mundur të rregulloni kohën e nevojshme për të marrë bravë dhe për të përfunduar transaksionet e bllokuara, si dhe për të ndryshuar nivelin e izolimit.
Lexo më shumë:
Burimi: www.habr.com