🥇14 asja, mida ma oleksin soovinud teada enne MongoDB-ga alustamist

Artikli tõlge on ettevalmistatud kursuse alguseks «Mittepoleerimata andmebaasid».

Peamised punktid:

On äärmiselt oluline disainida skeem, kuigi MongoDB-s see ei ole kohustuslik.
Samuti peavad indeksid vastama teie skeemile ja ligipääsukorraldustele.
Vältige suurte objektide ja massiivide kasutamist.
Olge ettevaatlik MongoDB seadistuste puhul, eriti kui tegemist on turvalisuse ja usaldusväärsusega.
MongoDB-s pole päringu optimeerijat, seega peate olema ettevaatlik päringute sooritamisel.

Olen väga kaua töötanud andmebaasidega, kuid hiljuti avastasin MongoDB. On mõned asjad, mida ma tahaksin teada enne, kui hakkan sellega töötama. Kui inimesel on juba kogemus teatud valdkonnas, siis on tal eelarvamused selle kohta, mis on andmebaasid ja mida nad teevad. Lootes teiste inimeste mõistmist kergendada, esitan levinud vigade nimekirja.

MongoDB serveri loomine ilma autentimiseta

Kahjuks installitakse MongoDB vaikimisi ilma autentimiseta. Kohalikuks pääsuks on see tava normaalne. Kuid kuna MongoDB on mitme kasutajaga süsteem, mis eelistab kasutada suurtes kogustes mälu, on parem paigaldada see serverisse, kus on võimalikult palju operatiivmälu, isegi kui plaanite seda kasutada ainult arenduseks. Serverisse installimine vaikimisi pordi kaudu võib olla probleemne, eriti kui päringus saab käivitada mis tahes JavaScripti koodi (näiteks, $where ideena süstimise).

On olemas mitmeid autentimismeetodeid, kuid lihtsaim on luua kasutaja ID/parool. Kasutage seda ideed, kuni mõtledate nutika autentimise peale, mis põhineb LDAP. Kui rääkida turvalisusest, peaks MongoDB olema pidevalt ajakohane ja logisid tuleks alati kontrollida volitamata pääsu osas. Mulle näiteks meeldib valida vaikimisi pordiks teise pordi.

Ärge unustage siduda ründepinda MongoDB-ga

MongoDB turvachek-list sisaldab häid näpunäiteid võrgu sissetungimise ja andmelekkete riski vähendamiseks. On lihtne öelda, et arendusserver ei vaja kõrget turvataset. Kuid asi pole nii lihtne ja see kehtib kõigi MongoDB serverite kohta. Eelkõige, kui pole mõjuvat põhjust kasutada mapReduce, grupp või $where, tuleks JavaScripti suvalise koodi kasutamine keelata, kirjutades konfigureerimisfaili javascriptEnabled:false. Kuna standardsetes MongoDB andmefailides pole krüpteerimist, on mõistlik käivitada MongoDB koos Pühendatud kasutaja, kellel on täielik juurdepääs failidele, piiratud juurdepääs ainult tema jaoks ja võimalus kasutada oma süsteemi failide juurdepääsu haldamise vahendeid.

Schéma arengus esinev viga

MongoDB ei kasuta skeemi. Kuid see ei tähenda, et skeem pole vajalik. Kui soovite lihtsalt säilitada dokumente ilma mingisuguse ühtse skeemita, on nende säilitamine kiire ja lihtne, kuid nende hilisem väljavõtmine võib olla päris keeruline.

Klassikaline artikkel „6 kogemusnõuannet MongoDB skeemide kujundamiseks“ on kindlasti lugemist väärt, samuti sellised funktsioonid nagu Schema Explorer kolmanda osapoole tööriistas, nagu Studio 3T, tasub kasutada regulaarsete skeemide kontrollimiseks.

Ärge unustage sortimisjärjestust

Sortimisjärjestuse unustamine võib osutuda kõige suuremaks pettumuseks ja võtma rohkem aega kui vale konfiguratsiooni kasutamine. Vaikimisi kasutab MongoBD binaarset sortimist. Kuid see ei pruugi kellelegi kasulik olla. Suhted nii suur- kui väikealgustel, samuti binaarsed sortimised peeti juba 1980. aastatel huvitavateks anahroonismideks koos helmeste, kaftanide ja lokkidega vuntsidega. Nüüd on nende kasutamine peaaegu lubamatu. Otseses elus on 'moto' sama mis 'Moto'. Ja 'Britannia' ja 'britannia' on sama koht. Väike täht on lihtsalt suure tähe vastav kirjutis. Ja ärge sundige mind rääkima diakriitiliste märkide sortimisest. MongoDB andmebaasi loomisel kasutage sortimisvalikuid, mis ignoreerivad rõhutust ja tähe suurust, mis vastavad süsteemi kasutajate keelele ja kultuurile. Nii lihtsustate oluliselt stringiandmete otsimist.

Kogud suurete dokumentidega loomine

MongoDB on õnnelik, et saab salvestada suuri dokumente, mille suurus on kuni 16 MB kollektsioonides, ja GridFS on mõeldud dokumentidele, mis on suuremad kui 16 MB. Kuid see, et suuri dokumente saab seal salvestada, ei tähenda, et nende hoidmine seal oleks parim lahendus. MongoDB töötab paremini, kui salvestate eraldi dokumente, mille suurus on paar kilobaiti, käsitledes neid pigem nagu veerge laias SQL-tabelis. Suured dokumendid võivad tekitada probleeme tõhususe.

Suurte massiividega dokumentide loomine

Dokumendid võivad sisaldada massiive. Parim on, kui massiivi elementide arv on kaugel neljakohalisest numbrist. Kui massiivile lisatakse elemente sageli, suureneb see üle selle dokumenti, milles see asub, ja tuleb liikuda, mis tähendab, et tuleb uuendada ka indekseid. Suure massiiviga dokumendi uuesti indekseerimise ajal kirjutatakse indeksid sageli üle, kuna iga elemendi jaoks on olemas kanne, mis salvestab selle indeksi. See uuesti indekseerimine toimub ka siis, kui dokumenti lisatakse või eemaldatakse.

MongoDB-s on nii kutsutud „täituvusmäär“, mis on dokumentide kasvuks ruumi võimaldav, et seda probleemi võimalikult väikseks vähendada.
Võib-olla arvatakse, et ilma massiivide indekseerimiseta on võimalik hakkama saada. Kahjuks võivad indekseerimise puudumise tõttu tekkida teised probleemid. Kuna dokumendid vaadatakse läbi algusest lõpuni, siis elementide leidmine massiivi lõpus võtab rohkem aega ja enamik operatsioone, mis on seotud sellise dokumendiga, on aeglased.

Ärge unustage, et aggregeerimise etappide järjekord on oluline

Andmebaasisüsteemis, kus on päringute optimeerija, on teie kirjutatud päringud seletused selle kohta, mida soovite saada, mitte kuidas seda saada. See töötab sarnaselt restoranis tellimisega: tavaliselt tellite lihtsalt roa, mitte ei anna kokale üksikasjalikke juhiseid.

MongoDB-s annate te kokale juhiseid. Näiteks tuleb veenduda, et andmed läbivad reduce nii varakult kui võimalik torustikus, kasutades $match ja $project, ja sorteerimine toimub alles pärast reduce, ja otsing toimub täpselt sellises järjestuses, nagu vaja. Küsimuste optimeerija olemasolu, mis vabastab teid liigsetest ülesannetest, järjestab etapid optimaalselt ja valib ühendustüübi, võib teid ära hellitada. MongoDB-s on teil rohkem kontrolli mugavuse hinnaga.

Sellised tööriistad nagu Studio 3T lihtsustavad agregatsiooni päringute koostamist MongoDB. Aggregation Editori funktsioon võimaldab teil rakendada torujuhtme operaatorite etappe ükshaaval ning kontrollida iga etapi sisendeid ja väljundeid, et lihtsustada tõrkeotsingut.

Kiire kirjutamise kasutamine

Ärge kunagi seadke MongoDB-s kõrge kiiruseta salvestamise seadeid, kuid madala usaldusväärsusega. See režiim «file-and-forget» tundub kiire, kuna käsk naaseb enne, kui salvestus toimub. Kui süsteem kokku kukub enne, kui andmed on kettale salvestatud, kaovad need ja jäävad kokkusobimatuks. Õnneks on 64-bitises MongoDB-s kaasas logimise funktsioon.

MMAPv1 ja WiredTiger salvestusmasinad kasutavad selle vältimiseks logimist, kuigi WiredTiger suudab taastuda viimase üheseisundi kontrollpunkti., kui logimine on väljas.

Logimine tagab, et andmebaas jääb taastamise ajal järjepidevusse ning säilitab kõik andmed enne logimist. Kirjete sagedus seadistatakse parameetri kaudu commitIntervalMs.

Veenduge, et logimine oleks konfiguratsioonifailis sisse lülitatud, et olla kindel kirjete olemasolus. (storage.journal.enabled), ja et kirjete sagedus vastaks sellele teabe mahule, mille kaotamist te endale lubada saate.

Sorteerimine ilma indeksita

Andmete otsimisel ja kogumisel on sageli vajalik andmete sorteering. Loodame, et seda tehakse pärast tulemuste filtreerimist, et vähendada sorteeritavate andmete mahtu. I isegi sel juhul vajate te sorteerimiseks indeksi. Saate kasutada kas ühtikut või koosnevat indeksit.

Kui sobivat indeksit ei ole, siis MongoDB saab ilma selleta hakkama. Sortimise operatsioonide puhul on üldine dokumentide suuruse piir 32 MB операции сортировки, ja kui MongoDB saavutab selle piiri, siis kas annab ta veateate või tagastab ta tühja andmete kogumi.

Otsing ilma indeksite toeta

Otsingupäringud täidavad sarnast funktsiooni nagu JOIN operatsioon SQL-is. Parema töö saavutamiseks on neil vajalik võtme väärtuse indeks, mida kasutatakse väliseks võtmemiseks. See ei ole ilmne, kuna kasutamine ei ole peegeldatud explain(). Sellised indeksid on lisand, millele on lisatud indeks explain(), mille omakorda kasutavad töötlusoperatsioonid $match ja $sort, kui need esinevad toru alguses. Indeksid võivad nüüd hõlmata mis tahes etappi aggregeerimise torustikus.

Mitme uuendamise loobumine

Meetod db.collection.update() kasutatakse olemasoleva dokumendi osa või terviku muutmiseks, täieliku asendamise kuni teie poolt määratud parameetrini update. Ei ole nii ilmne, et see ei töötle kõik dokumendid kogus, kuni määrate parameetri multi kõikide dokumentide uuendamiseks, mis vastavad päringu kriteeriumidele.

Ärge unustage võtmete järjekorra tähtsust hash-tabelis

JSON-is koosneb objekt järjekorrastamata kogumist, mis sisaldab null või rohkem nime/väärtuse paare, kus nimi on string ja väärtus võib olla string, number, loogiline väärtus, null, objekt või massiiv.

Kahjuks on BSON-i puhul otsingus järjekord äärmiselt oluline. MongoDB-s on sisseehitatud objektide võtmete järjekord tähtis. väärtus, st. { firstname: "Phil", surname: "factor" } – see ei ole sama, mis { { surname: "factor", firstname: "Phil" }. See tähendab, et peate dokumentides säilitama paaride nime/väärtuse järjekorra, kui soovite olla kindel, et leiate need.

Ärge segage kokku „null“ ja „undefined“

Väärtus „undefined“ ei ole kunagi olnud JSON-is lubatud, vastavalt ametlikule standardile JSON (ECMA-404, jaotis 5), vaatamata sellele, et seda kasutatakse JavaScriptis. Veelgi enam, BSON-i puhul on see aegunud ja muudetakse $null, mis ei ole alati hea lahendus. Vältige kasutamist „undefined“ MongoDB-s.

Kasutamine `$limit()` ilma `$sort()`

Sageli on MongoDB arendamisel kasulik lihtsalt näha, milline näidis tulemus tuleb päringust või agregatsioonist. Selle ülesande jaoks on teil vaja $limit(), kuid seda ei tohiks kunagi olla lõppversioonis, välja arvatud siis, kui eelnevalt kasutate $sort. See mehhanika on vajalik, sest vastasel juhul ei saa te tulemuse järjekorda tagada ning ei saa andmeid usaldusväärselt vaadata. Tulemuse ülaosas saate erinevaid kirjeid sõltuvalt sorteerimisest. Usaldusväärse toimimise tagamiseks peavad päringud ja aggregeerimised olema deterministlikud, s.t. need peavad iga täitmise korra jooksul andma samu tulemusi. Kood, milles on $limit(), aga ei ole $sort, ei ole deterministlik ja võib hiljem põhjustada vigu, mida on raske jälgida.

Kokkuvõte

Ainus viis MongoDB's pettuda on võrrelda seda otse mõne teise andmebaasitüübiga, näiteks RDBMS-iga, või tulla selle kasutamise juurde mingite kindlate ootustega. See on nagu võrrelda apelsine kahvliga. Andmebaasisüsteemid järgivad kindlaid eesmärke. Parim on lihtsalt mõista ja hinnata neid erinevusi. Oleks häbi avaldada MongoDB arendajatele survet tee osas, mille nad RDBMS-i poole minnes ette võtsid. Soovin näha uusi ja huvitavaid viise vanade probleemide lahendamiseks, nagu andmete terviklikkuse tagamine ja rikke- ja rünnakukindlate andmesüsteemide loomine.

MongoDB-sse versioonis 4.0 sisseehitatud ACID tehingute toimimine on hea näide oluliste uuenduste rakendamisest innovatiivsel viisil. Mitme dokumendi ja mitme operaatoriga tehingud on nüüd atomaarse iseloomuga. Samuti on võimalik reguleerida aega, mis on vajalik lukustuste saamiseks, lõpetada kinni jäänud tehingud ning muuta isoleerimise taset.