Þýðing á greininni var unnin í aðdraganda námskeiðsins .
Helstu atriði:
- Það er afar mikilvægt að þróa skema þó það sé valfrjálst í MongoDB.
- Sömuleiðis verða vísitölur að passa við stefið þitt og aðgangsmynstur.
- Forðastu að nota stóra hluti og stóra fylki.
- Vertu varkár með MongoDB stillingar, sérstaklega þegar kemur að öryggi og áreiðanleika.
- MongoDB er ekki með fyrirspurnarfínstillingu, svo þú verður að vera varkár þegar þú framkvæmir fyrirspurnaraðgerðir.
Ég hef unnið með gagnagrunna í mjög langan tíma, en uppgötvaði MongoDB nýlega. Það eru nokkrir hlutir sem ég vildi að ég vissi áður en ég byrjaði að vinna með það. Þegar einstaklingur hefur þegar reynslu á ákveðnu sviði hefur hann fyrirframgefnar hugmyndir um hvað gagnagrunnar eru og hvað þeir gera. Í von um að auðvelda öðrum að skilja, set ég fram lista yfir algeng mistök.
Að búa til MongoDB netþjón án auðkenningar
Því miður er MongoDB sjálfgefið uppsett án auðkenningar. Fyrir vinnustöð sem aðgangur er að á staðnum er þessi venja eðlileg. En þar sem MongoDB er fjölnotendakerfi sem hefur gaman af því að nota mikið magn af minni, þá verður betra ef þú setur það á netþjón með eins miklu vinnsluminni og mögulegt er, jafnvel þótt þú ætlir bara að nota það til þróunar. Uppsetning á þjóninum í gegnum sjálfgefna tengið getur verið erfið, sérstaklega ef hægt er að keyra Javascript kóða í beiðninni (td, $where sem hugmynd að ).
Það eru nokkrar auðkenningaraðferðir, en auðveldast er að stilla notandakenni/lykilorð. Notaðu þessa hugmynd á meðan þú hugsar um fína auðkenningu byggða á . Þegar það kemur að öryggi ætti MongoDB að vera stöðugt uppfærð og alltaf ætti að athuga annála fyrir óviðkomandi aðgang. Til dæmis finnst mér gaman að velja aðra höfn sem sjálfgefna höfn.
Ekki gleyma að binda árásarflötinn við MongoDB
inniheldur góð ráð til að draga úr hættu á innbrotum á netkerfi og gagnaleka. Það er auðvelt að bursta það og segja að þróunarþjónn þurfi ekki mikið öryggisstig. Hins vegar er það ekki svo einfalt og þetta á við um alla MongoDB netþjóna. Sérstaklega ef það er engin rík ástæða til að nota , eða , þú þarft að slökkva á notkun á handahófskenndum kóða í JavaScript með því að skrifa í stillingarskrána . Þar sem gagnaskrár eru ekki dulkóðaðar í venjulegu MongoDB er skynsamlegt að keyra MongoDB með , sem hefur fullan aðgang að skrám, með takmarkaðan aðgang eingöngu að þeim og getu til að nota eigin skráaaðgangsstýringu stýrikerfisins.
Villa við að þróa hringrásina
MongoDB notar ekki skema. En þetta þýðir ekki að ekki sé þörf á kerfinu. Ef þú vilt bara geyma skjöl án nokkurs samkvæms mynsturs getur geymsla þeirra verið fljótleg og auðveld, en að sækja þau síðar getur verið erfitt. .
Klassísk grein " Það er þess virði að lesa, og eiginleikar eins og í þriðja aðila tólinu Studio 3T er það þess virði að nota það til að athuga reglulega hringrásir.
Ekki gleyma flokkunarröðinni
Að gleyma flokkunarröðinni getur valdið meiri gremju og sóun á meiri tíma en nokkur önnur röng uppsetning. Sjálfgefið er að MongoBD notar . En það er ólíklegt að það gagnist neinum. Hástafa-, hreim-næmur, tvöfaldur tegundir voru álitnar forvitnilegar anachronisms ásamt perlum, kaftans og hrokkið yfirvaraskegg aftur á níunda áratug síðustu aldar. Nú er notkun þeirra ófyrirgefanleg. Í raunveruleikanum er "mótorhjól" það sama og "mótorhjól". Og „Bretland“ og „Bretland“ eru sami staðurinn. Lítill stafur er einfaldlega hástafur sem jafngildir stórum staf. Og ekki láta mig byrja á því að raða niður orðum. Þegar þú býrð til gagnagrunn í MongoDB skaltu nota hreim-ónæma samsetningu og , sem samsvara tungumálinu og . Þetta mun gera leit í gegnum strengjagögn mun auðveldari.
Búðu til söfn með stórum skjölum
MongoDB er fús til að hýsa stór skjöl allt að 16MB í söfnum, og Hannað fyrir stór skjöl stærri en 16 MB. En bara vegna þess að hægt er að setja stór skjöl þar er ekki góð hugmynd að geyma þau þar. MongoDB mun virka best ef þú geymir einstök skjöl sem eru nokkur kílóbæt að stærð og meðhöndlar þau meira eins og raðir í breiðri SQL töflu. Stór skjöl verða uppspretta vandamála með .
Að búa til skjöl með stórum fylkjum
Skjöl geta innihaldið fylki. Best er ef fjöldi þátta í fylkinu er langt frá því að vera fjögurra stafa tala. Ef þáttum er bætt oft við fylki mun það vaxa úr skjalinu sem inniheldur það og verður að vera , sem þýðir að það verður nauðsynlegt . Þegar skjal er endurtryggt með stóru fylki verður vísitölunum oft skrifað yfir, þar sem það er , sem geymir vísitölu sína. Þessi endurskráning á sér einnig stað þegar skjal er sett inn eða eytt.
MongoDB hefur eitthvað sem heitir , sem gefur svigrúm fyrir skjöl til að stækka til að lágmarka þetta vandamál.
Þú gætir haldið að þú getir verið án fylkisskráningar. Því miður getur skortur á vísitölum valdið því að þú átt í öðrum vandamálum. Þar sem skjöl eru skönnuð frá upphafi til enda mun leit að þáttum í lok fylkisins taka lengri tíma og flestar aðgerðir sem tengjast slíku skjali verða .
Ekki gleyma því að röð stiga í samsöfnun skiptir máli
Í gagnagrunnskerfi með fyrirspurnarfínstillingu eru fyrirspurnirnar sem þú skrifar útskýringar á því sem þú vilt fá, ekki hvernig á að fá það. Þetta fyrirkomulag virkar á hliðstæðan hátt við að panta á veitingastað: venjulega pantar þú einfaldlega rétt og gefur ekki nákvæmar leiðbeiningar til matreiðslumannsins.
Í MongoDB kennir þú matreiðslumanninum. Til dæmis þarf að ganga úr skugga um að gögnin fari í gegnum reduce eins snemma og mögulegt er í leiðslunni með því að nota $match и $project, og flokkun á sér stað aðeins eftir reduce, og að leitin gerist í nákvæmlega þeirri röð sem þú vilt. Að hafa fyrirspurnarfínstillingu sem útilokar óþarfa vinnu, raðar skrefum á bestan hátt og velur sameinategundir getur skemmt þér. Með MongoDB hefurðu meiri stjórn á kostnað þæginda.
Verkfæri eins og mun einfalda smíði söfnunarfyrirspurna í . Aggregation Editor eiginleiki gerir þér kleift að beita leiðsluyfirlýsingum einu stigi í einu og skoða inntaks- og úttaksgögn á hverju stigi til að einfalda villuleit.
Notkun Quick Recording
Aldrei stilltu MongoDB skrifvalkosti til að hafa mikinn hraða en lítinn áreiðanleika. Þessi háttur "skrá-og-gleyma" virðist hratt vegna þess að skipuninni er skilað áður en ritunin á sér stað. Ef kerfið hrynur áður en gögnin eru skrifuð á disk tapast þau og endar í ósamræmi. Sem betur fer er 64-bita MongoDB virkjað á skráningu.
MMAPv1 og WiredTiger geymsluvélarnar nota skógarhögg til að koma í veg fyrir þetta, þó að WiredTiger geti endurheimt sig til síðasta stöðuga , ef slökkt er á skráningu.
Dagbókun tryggir að gagnagrunnurinn sé í stöðugu ástandi eftir endurheimt og geymir öll gögn þar til þau eru skrifuð í dagbókina. Tíðni upptöku er stillt með færibreytunni .
Til að vera viss um færslurnar skaltu ganga úr skugga um að skráning sé virkjuð í stillingarskránni ), og tíðni upptöku samsvarar því magni upplýsinga sem þú hefur efni á að missa.
Flokkun án vísitölu
Þegar leitað er og safnað saman þarf oft að flokka gögn. Við skulum vona að þetta sé gert á einu af lokastigunum, eftir að niðurstaðan hefur verið síuð til að minnka magn gagna sem verið er að flokka. Og jafnvel í þessu tilfelli, fyrir flokkun sem þú þarft . Þú getur notað eina eða samsetta vísitölu.
Ef það er engin hentug vísitala mun MongoDB vera án hennar. Það er 32 MB minnistakmörk á heildarstærð allra skjala í , og ef MongoDB nær þessum mörkum, þá mun það annað hvort kasta villu eða skila .
Leitaðu án vísitölustuðnings
Leitarfyrirspurnir framkvæma svipaða aðgerð og JOIN aðgerðin í SQL. Til að virka best þurfa þeir vísitöluna á gildi lykilsins sem er notaður sem erlendur lykill. Þetta er ekki augljóst vegna þess að notkunin endurspeglast ekki í explain(). Slíkar vísitölur eru til viðbótar vísitölunni sem skráð er inn explain(), sem aftur er notað af leiðslum $match и $sort, þegar þeir hittast í upphafi leiðslunnar. Vísitölur geta nú náð yfir hvaða stig sem er .
Afþakka að nota margar uppfærslur
Aðferð notað til að breyta hluta af skjali sem fyrir er eða öllu skjalinu, upp í algjöra endurnýjun, allt eftir færibreytunni sem þú tilgreinir . Það sem er ekki svo augljóst er að það mun ekki vinna úr öllum skjölum í safninu nema þú stillir valmöguleikann að uppfæra öll skjöl sem uppfylla beiðniskilyrðin.
Ekki gleyma mikilvægi röð lykla í kjötkássatöflu
Í JSON samanstendur hlutur af óröðuðu safni af stærð núll eða fleiri nafn/gildi pörum, þar sem nafn er strengur og gildi er strengur, tala, boolean, núll, hlutur eða fylki.
Því miður leggur BSON mikla áherslu á röð þegar leitað er. Í MongoDB, röð lykla innan innbyggðra hluta þ.e. { firstname: "Phil", surname: "factor" } - þetta er ekki það sama og { { surname: "factor", firstname: "Phil" }. Það er, þú verður að geyma röð nafna/gilda para í skjölunum þínum ef þú vilt vera viss um að finna þau.
Ekki vera ruglaður "Núll" и "óskilgreint"
Gildi "óskilgreint" gilti aldrei í JSON, skv JSON (ECMA-404 Hluti 5), jafnvel þó að það sé notað í JavaScript. Þar að auki, fyrir BSON er það úrelt og er breytt í $null, sem er ekki alltaf góð lausn. .
Nota $limit() без $sort()
Oft þegar þú ert að þróa í MongoDB er gagnlegt að sjá bara sýnishorn af niðurstöðunni sem verður skilað frá fyrirspurn eða samansafn. Fyrir þetta verkefni sem þú þarft $limit(), en það ætti aldrei að vera í lokakóðann nema þú notir það áður $sort. Þessi vélvirki er nauðsynlegur vegna þess að annars geturðu ekki ábyrgst röð niðurstöðunnar og þú munt ekki geta skoðað gögnin á áreiðanlegan hátt. Efst á niðurstöðunni færðu mismunandi færslur eftir flokkun. Til að virka áreiðanlega verða fyrirspurnir og samsöfnun að vera ákveðin, það er að gefa sömu niðurstöður í hvert sinn sem þær eru keyrðar. Kóði sem inniheldur $limit(), en nei $sort, verður ekki ákvarðandi og getur í kjölfarið valdið villum sem erfitt verður að elta uppi.
Ályktun
Eina leiðin til að verða fyrir vonbrigðum með MongoDB er að bera hann beint saman við aðra tegund gagnagrunns, svo sem DBMS, eða nota hann út frá ákveðnum væntingum. Þetta er eins og að bera saman appelsínu við gaffal. Gagnagrunnskerfi þjóna sérstökum tilgangi. Það er best að einfaldlega skilja og meta þennan mun sjálfur. Það væri synd að þrýsta á MongoDB forritara um leið sem neyddi þá niður DBMS leiðina. Ég vil sjá nýjar og áhugaverðar leiðir til að leysa gömul vandamál, eins og að tryggja gagnaheilleika og búa til gagnakerfi sem eru þola bilanir og illgjarnar árásir.
Kynning MongoDB á ACID viðskiptavirkni í útgáfu 4.0 er gott dæmi um að kynna mikilvægar endurbætur á nýstárlegan hátt. Fjölskjala- og fjölyfirlýsingaviðskipti eru nú atóm. Einnig er hægt að stilla þann tíma sem þarf til að eignast læsingar og slíta föstum viðskiptum, sem og breyta einangrunarstigi.
Lestu meira:
Heimild: www.habr.com