La traduko de la artikolo estis preparita sojle de la komenco de la kurso .
Ĉefaĵoj:
- Estas ege grave evoluigi skemon kvankam ĝi estas laŭvola en MongoDB.
- Same, indeksoj devas kongrui kun via skemo kaj alirpadronoj.
- Evitu uzi grandajn objektojn kaj grandajn tabelojn.
- Atentu pri MongoDB-agordoj, precipe se temas pri sekureco kaj fidindeco.
- MongoDB ne havas konsult-optimumigon, do vi devas esti singarda kiam vi plenumas demandajn operaciojn.
Mi tre longe laboras kun datumbazoj, sed nur lastatempe malkovris MongoDB. Estas kelkaj aferoj, kiujn mi ŝatus scii antaŭ ol mi komencis labori kun ĝi. Kiam homo jam havas sperton en certa kampo, ili havas antaŭkonceptajn nociojn pri kio datumbazoj estas kaj kion ili faras. Esperante faciligi la komprenon de aliaj, mi prezentas liston de oftaj eraroj.
Kreante MongoDB-servilon sen aŭtentigo
Bedaŭrinde, MongoDB estas instalita sen aŭtentikigo defaŭlte. Por laborstacio alirita loke, ĉi tiu praktiko estas normala. Sed ĉar MongoDB estas pluruza sistemo, kiu ŝatas uzi grandajn kvantojn da memoro, estos pli bone se vi metos ĝin sur servilon kun tiom da RAM kiel eble, eĉ se vi nur uzos ĝin por disvolviĝo. Instalado sur la servilo per la defaŭlta haveno povas esti problema, precipe se iu javaskripto-kodo povas esti efektivigita en la peto (ekzemple, $where kiel ideo por ).
Estas pluraj aŭtentikigmetodoj, sed la plej facila estas agordi uzantidentigilon/pasvorton. Uzu ĉi tiun ideon dum vi pensas pri ŝika aŭtentigo bazita sur . Se temas pri sekureco, MongoDB devas esti konstante ĝisdatigita, kaj protokoloj ĉiam estu kontrolitaj por neaŭtorizita aliro. Ekzemple, mi ŝatas elekti malsaman havenon kiel la defaŭltan havenon.
Ne forgesu ligi vian ataksurfacon al MongoDB
enhavas bonajn konsiletojn por redukti la riskon de rettrudiĝo kaj datumfluado. Estas facile forigi ĝin kaj diri, ke evoluservilo ne bezonas altnivelan de sekureco. Tamen, ĝi ne estas tiel simpla kaj ĉi tio validas por ĉiuj MongoDB-serviloj. Precipe, se ne ekzistas deviga kialo por uzi , aŭ , vi devas malŝalti la uzon de arbitra kodo en JavaScript skribante en la agorda dosiero . Ĉar datumdosieroj ne estas ĉifritaj en norma MongoDB, estas senco ruli MongoDB per , kiu havas plenan aliron al dosieroj, kun limigita aliro nur al ĝi kaj la kapablo uzi la proprajn dosieralirkontrolojn de la operaciumo.
Eraro dum disvolvado de la cirkvito
MongoDB ne uzas skemon. Sed ĉi tio ne signifas, ke la skemo ne estas bezonata. Se vi nur volas konservi dokumentojn sen iu ajn konsekvenca ŝablono, stoki ilin povas esti rapida kaj facila, sed retrovi ilin poste povas esti malfacila. .
Klasika artikolo " Ĝi valoras legi, kaj funkcioj kiel en la triaparta ilo Studio 3T, ĝi valoras uzi por regulaj kontroloj de cirkvitoj.
Ne forgesu la ordigon
Forgesi ordigon povas kaŭzi pli da frustriĝo kaj malŝpari pli da tempo ol iu ajn alia malĝusta agordo. Defaŭlte MongoBD uzas . Sed verŝajne ĝi estos utila al iu ajn. Kazsentemaj, akcent-sentemaj, binaraj specoj estis konsiderataj kuriozaj anakronismoj kune kun bidoj, kaftanoj kaj buklaj lipharoj reen en la 80-aj jaroj de la lasta jarcento. Nun ilia uzo estas nepardonebla. En la reala vivo, "motorciklo" estas la sama kiel "Motorciklo". Kaj "Britio" kaj "Britio" estas la sama loko. Minuskla litero estas simple la majuskla ekvivalento de majuskla litero. Kaj ne komencu min pri ordigo de diakritaj signoj. Kiam vi kreas datumbazon en MongoDB, uzu akcent-malsenteman kompacion kaj , kiuj respondas al la lingvo kaj . Ĉi tio multe pli facilas la serĉadon tra kordaj datumoj.
Kreu kolektojn kun grandaj dokumentoj
MongoDB ĝojas gastigi grandajn dokumentojn ĝis 16MB en kolektoj, kaj Desegnita por grandaj dokumentoj pli grandaj ol 16 MB. Sed nur ĉar grandaj dokumentoj povas esti metitaj tie, konservi ilin tie ne estas bona ideo. MongoDB funkcios plej bone se vi stokas individuajn dokumentojn, kiuj havas kelkajn kilobajtojn en grandeco, traktante ilin pli kiel vicoj en larĝa SQL-tabelo. Grandaj dokumentoj estos fonto de problemoj kun .
Krei dokumentojn kun grandaj tabeloj
Dokumentoj povas enhavi tabelojn. Plej bone estas se la nombro da elementoj en la tabelo estas malproksime de kvarcifera nombro. Se elementoj estas aldonitaj al tabelo ofte, ĝi superkreskos la dokumenton enhavanta ĝin kaj devos esti , kio signifas, ke ĝi estos necesa . Dum reindeksado de dokumento kun granda tabelo, la indeksoj ofte estos anstataŭitaj, ĉar ekzistas , kiu konservas sian indekson. Ĉi tiu reindeksado okazas ankaŭ kiam dokumento estas enmetita aŭ forigita.
MongoDB havas ion nomitan , kiu donas lokon por ke dokumentoj kresku por minimumigi ĉi tiun problemon.
Vi povus pensi, ke vi povas fari sen tabelindeksado. Bedaŭrinde, la manko de indeksoj povas kaŭzi al vi aliajn problemojn. Ĉar dokumentoj estas skanitaj de komenco ĝis fino, serĉi elementojn ĉe la fino de la tabelo daŭros pli longe, kaj la plej multaj operacioj asociitaj kun tia dokumento estos .
Ne forgesu, ke gravas la ordo de la etapoj en agregacio
En datumbaza sistemo kun konsultoptimumilo, la demandoj, kiujn vi skribas, estas klarigoj pri tio, kion vi volas ricevi, ne kiel akiri ĝin. Ĉi tiu mekanismo funkcias analoge kun mendado en restoracio: kutime oni simple mendas pladon, kaj ne donas detalajn instrukciojn al la kuiristo.
En MongoDB, vi instruas la kuiriston. Ekzemple, vi devas certigi, ke la datumoj trapasas reduce kiel eble plej frue en la dukto uzante $match и $project, kaj ordigo okazas nur post reduce, kaj ke la serĉo okazas ĝuste en la ordo, kiun vi volas. Havi konsult-optimumiganton, kiu forigas nenecesan laboron, optimume sekvencas paŝojn kaj elektas kunigajn tipojn povas difekti vin. Kun MongoDB, vi havas pli da kontrolo koste de oportuno.
Iloj kiel simpligos la konstruadon de agregaciaj demandoj en . La funkcio de Aggregation Editor ebligas al vi apliki duktajn deklarojn unu stadion samtempe, kaj inspekti enigajn kaj eligajn datumojn en ĉiu stadio por pli facila senararigado.
Uzante Rapidan Registradon
Neniam agordu MongoDB-skribajn elektojn por havi altan rapidecon sed malaltan fidindecon. Ĉi tiu reĝimo "dosiero-kaj-forgesu" ŝajnas rapide ĉar la komando estas resendita antaŭ ol la skribo okazas. Se la sistemo kraŝas antaŭ ol la datumoj estas skribitaj al disko, ĝi estos perdita kaj finiĝos en malkonsekvenca stato. Feliĉe, 64-bita MongoDB ebligis protokolon.
La stokadmotoroj MMAPv1 kaj WiredTiger uzas registradon por malhelpi tion, kvankam WiredTiger povas renormaliĝi ĝis la lasta konsekvenca. , se ensalutu estas malŝaltita.
Ĵurnalo certigas, ke la datumbazo estas en konsekvenca stato post reakiro kaj konservas ĉiujn datumojn ĝis ĝi estas skribita al la protokolo. La ofteco de registradoj estas agordita per la parametro .
Por esti certa pri la enskriboj, certigu, ke ensaluti estas ebligita en la agorda dosiero ), kaj la ofteco de registradoj respondas al la kvanto da informoj, kiujn vi povas permesi perdi.
Ordigo sen indekso
Dum serĉado kaj agregado, ofte necesas ordigi datumojn. Ni esperu, ke ĉi tio estas farita en unu el la finaj stadioj, post filtri la rezulton por redukti la kvanton da ordigo de datumoj. Kaj eĉ en ĉi tiu kazo, por ordigo vi bezonos . Vi povas uzi unuopan aŭ kunmetitan indekson.
Se ne ekzistas taŭga indekso, MongoDB faros sen ĝi. Estas memorlimo de 32 MB sur la totala grandeco de ĉiuj dokumentoj en , kaj se MongoDB atingas ĉi tiun limon, tiam ĝi aŭ ĵetos eraron aŭ revenos .
Serĉu sen indeksa subteno
Serĉdemandoj plenumas funkcion similan al la operacio JOIN en SQL. Por funkcii plej bone, ili bezonas la indekson de la valoro de la ŝlosilo uzata kiel fremda ŝlosilo. Ĉi tio ne estas evidenta ĉar la uzo ne estas reflektita en explain(). Tiaj indeksoj estas aldone al la indekso skribita enen explain(), kiu siavice estas uzata de duktofunkciigistoj $match и $sort, kiam ili renkontas komence de la dukto. Indeksoj nun povas kovri ajnan stadion .
Dezirante uzi plur-ĝisdatigojn
Metodo uzata por ŝanĝi parton de ekzistanta dokumento aŭ la tutan dokumenton, ĝis kompleta anstataŭaĵo, depende de la parametro, kiun vi specifas. . Kio ne estas tiel evidenta estas, ke ĝi ne prilaboros ĉiujn dokumentojn en la kolekto krom se vi agordas la opcion ĝisdatigi ĉiujn dokumentojn, kiuj plenumas la petajn kriteriojn.
Ne forgesu la gravecon de la ordo de la ŝlosiloj en hashtabelo
En JSON, objekto konsistas el neordigita kolekto de grandeco nul aŭ pli da nomo/valoraj paroj, kie nomo estas ĉeno kaj valoro estas ĉeno, nombro, buleo, nulo, objekto aŭ tabelo.
Bedaŭrinde, BSON multe emfazas ordon dum serĉado. En MongoDB, la ordo de ŝlosiloj ene de enkonstruitaj objektoj , t.e. { firstname: "Phil", surname: "factor" } — ĉi tio ne estas la sama kiel { { surname: "factor", firstname: "Phil" }. Tio estas, vi devas konservi la ordon de nom-/valoraj paroj en viaj dokumentoj se vi volas esti certa trovi ilin.
Ne estu konfuzita "Nula" и "nedifinita"
valoro "nedifinita" neniam validis en JSON, laŭ JSON (ECMA-404 Section 5), kvankam ĝi estas uzata en JavaScript. Krome, por BSON ĝi estas malnoviĝinta kaj estas konvertita al $null, kio ne ĉiam estas bona solvo. .
Uzo $limit() sen $sort()
Tre ofte kiam vi disvolvas en MongoDB, estas utile nur vidi specimenon de la rezulto, kiu estos resendita de demando aŭ agregado. Por ĉi tiu tasko vi bezonos $limit(), sed ĝi neniam estu en la fina kodo krom se vi antaŭe uzas ĝin $sort. Ĉi tiu mekaniko estas necesa ĉar alie vi ne povas garantii la ordon de la rezulto, kaj vi ne povos fidinde vidi la datumojn. Ĉe la supro de la rezulto vi ricevos malsamajn enskribojn depende de la ordigo. Por labori fidinde, demandoj kaj agregaĵoj devas esti determinismaj, tio estas, produkti la samajn rezultojn ĉiufoje kiam ili estas ekzekutitaj. Kodo kiu enhavas $limit(), sed ne $sort, ne estos determinisma kaj povas poste kaŭzi erarojn, kiuj estos malfacile spureblaj.
konkludo
La sola maniero seniluziiĝi pri MongoDB estas kompari ĝin rekte kun alia speco de datumbazo, kiel DBMS, aŭ veni uzi ĝin surbaze de certaj atendoj. Estas kiel kompari oranĝon kun forko. Datumbazsistemoj servas specifajn celojn. Plej bone estas simple kompreni kaj aprezi ĉi tiujn diferencojn por vi mem. Estus domaĝe premadi la programistojn de MongoDB super vojo, kiu devigis ilin malsupren la vojon de DBMS. Mi volas vidi novajn kaj interesajn manierojn solvi malnovajn problemojn, kiel certigi datumintegrecon kaj krei datumsistemojn, kiuj estas rezistemaj al fiasko kaj malicaj atakoj.
La enkonduko de ACID-transakcio de MongoDB en versio 4.0 estas bona ekzemplo de enkondukado de gravaj plibonigoj en noviga maniero. Multdokumentaj kaj multdeklaraj transakcioj nun estas atomaj. Ankaŭ eblas ĝustigi la tempon necesan por akiri serurojn kaj ĉesigi blokitajn transakciojn, kaj ankaŭ ŝanĝi la izolitecan nivelon.
Legu pli:
fonto: www.habr.com