🥇14 asja, mida ma soovin, et oleksin teadnud enne MongoDB-ga alustamist

Artikli tõlge on koostatud kursuse alguse eelõhtul „Mittelemata andmebaasid“.

Peamised punktid:

On äärmiselt oluline välja töötada skeem, kuigi MongoDBs see ei ole kohustuslik.
Sarnaselt peavad indeksid vastama teie skeemile ja juurdepääsude mallidele.
Vältige suurte objektide ja massiivide kasutamist.
Olge MongoDB seadistustega ettevaatlik, eriti kui tegemist on turvalisuse ja usaldusväärsusega.
MongoDBs ei ole päringute optimeerijat, seega peate olema ettevaatlik päringute tegemisel.

Olen juba pikka aega andmebaasidega töötanud, kuid avastasin MongoDB alles hiljuti. On mõned asjad, mida sooviksin teada enne selle kasutamise alustamist. Kui inimesel on teatud valdkonnas juba kogemus, siis on tal eelarvamused selle suhtes, mida andmebaasid on ja mida nad teevad. Loodan, et teiste jaoks arusaamise lihtsustamiseks esitan loetelu levinud vigadest.

MongoDB serveri loomine ilma autentimiseta

Kahjuks installitakse MongoDB vaikimisi ilma autentimiseta. Kohalikult juurdepääsuga tööjaama jaoks on see tava normaalne. Kuid kuna MongoDB on mitme kasutajaga süsteem, mis armastab kasutada suurt mälu, on parem paigaldada see serverisse, kus on teie tingimustes maksimaalselt võimalik mälumaht, isegi kui kavatsete seda kasutada ainult arendamiseks. Serverisse paigaldamine vaikimisi pordi kaudu võib olla probleemne, eriti kui päringutes on võimalik täita mis tahes JavaScripti kood (näiteks $where ideena süstimise).

On mitu autentimismeetodit, kuid lihtsaim on seadistada kasutaja ID/parool. Kasutage seda ideed, kuni mõtledate keerulisema autentimise peale, mis põhineb LDAP. Kui rääkida turvalisusest, siis MongoDB tuleks pidevalt uuendada ja logisid tuleks alati kontrollida volitamata juurdepääsu osas. Näiteks meeldib mulle valida mõni muu port kui vaikimisi port.

Ärge unustage siduda rünnakupinda MongoDBga

MongoDB turvalisuse kontrollnimekiri sisaldab häid näpunäiteid võrgu ja andmelekke riski vähendamiseks. On lihtne öelda, et arendussuvand ei vaja kõrget turvalisuse taset. Kuid asjad ei ole nii lihtsad ja see kehtib kõigi MongoDB serverite kohta. Eriti kui puudub kaalukas põhjus kasutada mapReduce, gruppe või $where, tuleks keelata JavaScripti kohandatud koodi kasutamine, kirjutades konfiguratsioonifaili javascriptEnabled:false. Kuna vaikimisi MongoDB andmefailid ei ole krüpteeritud, on mõistlik käivitada MongoDB koos pühendatud kasutajaga, kellel on täielik juurdepääs failidele, mille juurdepääs on piiratud ainult talle ja võimalusega kasutada oma opsüsteemi failide juurdepääsuvahendeid.

Schema loomise vigade

MongoDB ei kasuta skeemi. Kuid see ei tähenda, et skeem ei oleks vajalik. Kui soovite lihtsalt dokumente salvestada ilma ühtse skeemita, on nende salvestamine kiire ja lihtne, kuid hiljem välja toomine võib olla kuradima keeruline.

Klassikaline artikkel „6 empiirilist reeglit MongoDB skeemi kujundamiseks on seda väärt, et seda lugeda, ning selliseid funktsioone nagu Schema Explorer kolmandate osapoolte tööriistas Studio 3T tuleks kasutada regulaarseteks skeemi kontrollideks.

Ärge unustage sorteerimisjärjekorda

Sorteerimisjärjekorra unustamine võib kõige rohkem pettumust valmistada ja aega kaotada rohkem kui ükski vale konfigureerimine. Vaikimisi kasutab MongoDB binaarset sorteerimist. Kuid sellest pole kellelegi kasu. Suurte ja väikeste tähtede ning binaarsete sorteerimiste kasutamine on olnud kummalised anahronismid koos helmeste, kaftanide ja keerlevate vuntsidega juba 80ndatel. Nüüd on nende kasutamine andestamatu. Reaalses elus on "mootorratas" sama mis "Mootorratas". Ja "Britannia" ja "britannia" on sama koht. Väike täht on lihtsalt suure tähe vastavuskiri. Ja ärge sundige mind rääkima diakriitiliste märkide sorteerimisest. MongoDB andmebaasi loomisel kasutage sorteerimisparameetreid, mis arvestavad aktsentide ja registreid, mis vastavad süsteemi kasutajate keelele ja kultuurile. See lihtsustab stringiandmete otsimist oluliselt.

Suure dokumentide loomine kogud

MongoDB on rõõmuga paigutada suuri dokumente, mille suurus on kuni 16 MB kollektsioonidesse, kuid GridFS on mõeldud dokumentide jaoks, mille suurus ületab 16 MB. Kuid ainult seetõttu, et suuri dokumente saab sinna paigutada, ei ole nende seal hoidmine parim idee. MongoDB töötab kõige paremini, kui salvestate eraldi dokumente, mille suurus on paar kilobaiti, vaadates neid pigem kui ridu laias SQL-i tabelis. Suured dokumendid võivad põhjustada probleeme sooritusvõimega.

Dokumentide loomine, millel on suured massiivid

Dokumendid võivad sisaldada massiive. Parim oleks, kui massiivi elementide arv jääb kaugele kaugemale neljast numbrist. Kui elemente massiivile sageli lisatakse, kasvab see dokumenti sisaldavast massiivist üle ja tuleb liigutada, mis tähendab, et tuleb uuendada ka indeksid. Kui dokumendi sisu on suur massiiv, siis indeksid tihti uuendatakse, sest iga elemendi jaoks on olemas kanne, mis hoiab selle indeksit. Selline uuesti indekseerimine toimub ka siis, kui dokumente lisatakse või kustutatakse.

MongoDB-s on niiöelda «täituvuskoefitsient», mis annab dokumentide kasvamiseks ruumi, et vähendada seda probleemi miinimumini.
Võite arvata, et massiivide indekseerimisest võib loobuda. Kahjuks võivad indeksite puudumise tõttu tekkida teised probleemid. Kuna dokumente vaadatakse algusest lõpuni, võtab massiivi lõpus elementide otsimine rohkem aega, ja enamus seonduvaid toimingud sellise dokumendiga on aeglased.

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

Küsimusandmebaasis, millel on päringute optimeerija, on teie kirjutatud päringud seletused selle kohta, mida te soovite saada, mitte selle kohta, kuidas seda saada. See toimib sarnaselt restorani tellimisega: tavaliselt tellite lihtsalt roa, mitte ei anna kokale üksikasjalikke juhiseid.

MongoDB-s annate te kokkadele korraldusi. Näiteks peate veenduma, et andmed läbivad reduce nii vara kui võimalik toru kaudu, kasutades $match ja $project, ja sortimine toimub alles hiljem. reduce, ja otsimine toimub täpselt sellises järjestuses, nagu teil on vaja. Küsitavate optimeerija olemasolu, mis vabastab teid liigsetest töödest, korraldab etapid optimaalselt ja valib ühenduse tüübi, võib teid ära hellitada. MongoDB-s on teil rohkem kontrolli mugavuse hinna üle.

Sellised tööriistad nagu Studio 3T muudavad aggregeerimispäringute koostamise lihtsamaks MongoDB. Aggregation Editori funktsioon võimaldab teil rakendada toruoperaatoreid üksikute etappide kaupa, samuti kontrollida igas etapis sisendi ja väljundi andmeid, et debugeerimine oleks lihtsam.

Kiire kirje kasutamine

Ärge seadistage MongoDB-s kõrge kiiruseta kirje parameetreid, kuid madala usaldusväärsusega. See režiim «file-and-forget» tundub kiire, kuna käsk tagastatakse enne, kui kirje tehakse. Kui süsteem kokku kukub enne, kui andmed on kettale kirjutatud, kaovad need ja satuvad mittetäielikku olekusse. Õnneks on 64-bitises MongoDB-s logimine sisse lülitatud.

Salvestuse MMAPv1 ja WiredTiger mootorid kasutavad logimist, et seda vältida, kuigi WiredTiger võib taastuda viimase kooskõlastatud kontrollpunkti, kui logimine on välja lülitatud.

Logimine tagab, et andmebaas on taastumisel kooskõlastatud ja hoiab kõiki andmeid kuni logisse kirjutamiseni. Kirje sagedus seadistatakse parameetri kaudu commitIntervalMs.

Veenduge, et logimine oleks konfiguratsioonifailis lubatud (storage.journal.kasutatud), ja et kirje sagedus vastab sellele, kui palju teavet te võite endale lubada kaotada.

Sortimine ilma indeksita

Andmete otsimise ja aggregeerimise käigus tekib sageli vajadus andmete sortimise järele. Lootkem, et seda tehakse ühe viimase etapi käigus, pärast tulemuste filtreerimist, et vähendada sorteeritavate andmete hulka. Ja isegi sel juhul vajate sortimiseks indeksit. Saate kasutada üksik- või koostisindeksit.

Kui sobivat indeksit ei ole, saab MongoDB hakkama ka ilma selleta. Sortimise operatsiooni kogumahu jaoks on olemas 32 MB mälu piirang , ja kui MongoDB saavutab selle piiri, siis kas ta kuvab vigade arvu või tagastabtühja kirje kogumi Otsimine ilma indeksite toetamiseta.

Otsing ilma indeksitoega

Otsingupäringud täidavad sarnast funktsiooni nagu JOIN-operatsioon SQL-is. Parema toimimise jaoks vajavad nad indeksit välistava võtme väärtuse põhjal, mida kasutatakse välisvõtmena. See ei ole ilmselge, kuna kasutamine ei peegeldu explain(). Sellised indeksid on täienduseks indeksile, mis on salvestatud explain(), mida omakorda kasutavad toruoperaatorid $match ja $sort, kui need esinevad toru alguses. Indeksid võivad nüüd katta mistahes etappi aggregeerimistorustikus.

Mitme uuenduse kasutamisest loobumine

Meetod db.kogu.uuendus() kasutatakse olemasoleva dokumendi osa või kogu dokumendi muutmiseks, sõltuvalt teie määratud parameetrist, kuni täieliku asendamiseni update. Ei ole nii ilmne, et see ei töötle kõiki dokumente kollektsioonis, kui te ei määra parameetrit mitme kõikide dokumentide uuendamiseks, mis vastavad päringu kriteeriumitele.

Ärge unustage võtmete järjekorra tähtsust hajusates tabelites.

JSON-is koosneb objekt mittejärgnevast kollektsioonist, mille suurus on null või enam nimede/väärtuste paari, kus nimi on string ja väärtus on string, number, loogiline väärtus, null, objekt või massiiv.

Kahjuks omab BSON otsimise ajal järjekorra osas suurt tähtsust. MongoDB-s peab sisseehitatud objektide võtmete järjekord oma väärtuseks, st { firstname: "Phil", surname: "factor" } ei ole sama mis { { surname: "factor", firstname: "Phil" }. See tähendab, et peate dokumentides hoidma nimede/ väärtuste paaride järjekorra, kui soovite olla kindel, et leiate need.

Ärge segage kokku "null" ja "undefined"

Tähendus "undefined" ei ole kunagi olnud lubatud JSON-is, vastavalt ametlikule standardile JSON (ECMA-404, jaotis 5), hoolimata sellest, et seda kasutatakse JavaScriptis. Veelgi enam, BSON jaoks on see aegunud ja muundatakse $null, mis ei ole alati hea lahendus. Vältige kasutamist "undefined" MongoDB-s.

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

Väga tihti, kui arendate MongoDB-s, on kasulik lihtsalt näha tulemuse näidist, mis päringust või aggregeerimisest tagasi tuleb. Selle ülesande jaoks on teil kasu $limit(), kuid seda ei tohi kunagi olla lõppversioonis koodis, kui te ei kasuta seda enne $sort. See mekanism on vajalik, kuna muidu ei saa te garanteerida tulemuste järjekorda ja ei saa usaldusväärselt andmeid vaadata. Tulemuste ülaservas saate erinevaid kirjeid sõltuvalt sorteerimisest. Usaldusväärseks toimimiseks peavad päringud ja aggregeerimised olema deterministlikud, st andma iga täitmise korral samu tulemusi. Kood, milles on $limit(), kuid ei ole $sort, ei ole deterministlik ja võib hiljem põhjustada vigu, mida on raske jälgida.

Kokkuvõte

Ainus viis, kuidas MongoDBs üldse pettuda, on võrrelda seda otseselt teist tüüpi andmebaaside, näiteks SÜB, või kasutada seda teatud ootuste põhjal. See on sama, mis võrrelda apelsini kahvliga. Andmebaasisüsteemid jälgivad teatud eesmärke. Parim on lihtsalt mõista ja hinnata neid erinevusi. Oleks häbi suruda MongoDB arendajaid nende valikute pärast, mis on sundinud neid liikuma SÜB teed. Ma soovin näha uusi ja huvitavaid viise vanade probleemide, näiteks andmete terviklikkuse tagamise ja vigadele ning häkkerite rünnakutele vastupidavate andmesüsteemide loomise lahendamiseks.

MongoDB 4.0 versioonis ACID tehingute rakendamine on hea näide oluliste parenduste uuenduslikust rakendamisest. Multi-dokumendilised ja multi-tegevuslikud tehingud on nüüd atomaarset laadi. Samuti on saadaval võimalus reguleerida aega, mis on vajalik lukustuste saamiseks, ja lõpetada kinni jäänud tehingud ning muuta isoleerimise taset.