Prevod članka je bil pripravljen na predvečer začetka tečaja .
Poudarki:
- Zelo pomembno je razviti shemo, čeprav je v MongoDB neobvezna.
- Podobno se morajo indeksi ujemati z vašo shemo in vzorci dostopa.
- Izogibajte se uporabi velikih predmetov in velikih nizov.
- Bodite previdni pri nastavitvah MongoDB, zlasti ko gre za varnost in zanesljivost.
- MongoDB nima optimizatorja poizvedb, zato morate biti pri izvajanju poizvedovalnih operacij previdni.
Z bazami podatkov delam že zelo dolgo, vendar sem šele pred kratkim odkril MongoDB. Nekaj stvari bi si želel vedeti, preden bi začel delati s tem. Ko ima oseba že izkušnje na določenem področju, ima vnaprej oblikovane predstave o tem, kaj so baze podatkov in kaj počnejo. V upanju, da ga bodo drugi lažje razumeli, predstavljam seznam pogostih napak.
Ustvarjanje strežnika MongoDB brez preverjanja pristnosti
Na žalost je MongoDB privzeto nameščen brez preverjanja pristnosti. Za delovno postajo, do katere dostopate lokalno, je ta praksa normalna. Ker pa je MongoDB večuporabniški sistem, ki rad uporablja velike količine pomnilnika, bo bolje, če ga postavite na strežnik s čim več RAM-a, tudi če ga boste uporabljali le za razvoj. Namestitev na strežnik prek privzetih vrat je lahko problematična, še posebej, če je v zahtevi mogoče izvesti katero koli kodo javascript (npr. $where kot ideja za ).
Obstaja več načinov preverjanja pristnosti, vendar je najlažji nastavitev uporabniškega ID-ja/gesla. Uporabite to idejo, medtem ko razmišljate o modni avtentikaciji, ki temelji na . Kar zadeva varnost, je treba MongoDB nenehno posodabljati, dnevnike pa vedno preverjati glede nepooblaščenega dostopa. Na primer, rad izberem druga vrata kot privzeta vrata.
Ne pozabite povezati napadalne površine z MongoDB
vsebuje dobre nasvete za zmanjšanje tveganja vdora v omrežje in uhajanja podatkov. Zlahka se je otresti in reči, da razvojni strežnik ne potrebuje visoke stopnje varnosti. Vendar ni tako preprosto in to velja za vse strežnike MongoDB. Še posebej, če ni tehtnega razloga za uporabo , ali , morate onemogočiti uporabo poljubne kode v JavaScriptu tako, da zapišete v konfiguracijsko datoteko . Ker podatkovne datoteke niso šifrirane v standardnem MongoDB, je smiselno zagnati MongoDB z , ki ima popoln dostop do datotek, z omejenim dostopom samo do nje in možnostjo uporabe lastnih kontrol dostopa do datotek operacijskega sistema.
Napaka med razvijanjem vezja
MongoDB ne uporablja sheme. Vendar to ne pomeni, da shema ni potrebna. Če želite samo shraniti dokumente brez kakršnega koli doslednega vzorca, je njihovo shranjevanje lahko hitro in enostavno, vendar pa je njihovo poznejše pridobivanje lahko težavno. .
Klasičen članek " Vredno ga je prebrati in podobne funkcije v orodju tretje osebe Studio 3T je vredno uporabiti za redne preglede vezij.
Ne pozabite na vrstni red
Če pozabite na vrstni red razvrščanja, lahko povzročite več frustracij in izgubite več časa kot katera koli druga nepravilna konfiguracija. MongoBD privzeto uporablja . Vendar je malo verjetno, da bi bilo koristno za koga. Dvojinske vrste, ki razlikujejo med velikimi in malimi črkami, naglasom, so v 80. letih prejšnjega stoletja skupaj s perlami, kaftani in kodrastimi brki veljale za radovedne anahronizme. Zdaj je njihova uporaba neodpustljiva. V resničnem življenju je "motorno kolo" isto kot "motorno kolo". In "Britanija" in "Britanija" sta isto mesto. Mala začetnica je preprosto enakovredna veliki črki. In naj ne začnem z razvrščanjem diakritičnih znakov. Ko ustvarjate bazo podatkov v MongoDB, uporabite primerjanje, ki ni občutljivo na naglas in , ki ustrezajo jeziku in . To bo olajšalo iskanje po podatkih nizov.
Ustvarite zbirke z velikimi dokumenti
MongoDB z veseljem gosti velike dokumente do 16 MB v zbirkah in Zasnovan za velike dokumente, večje od 16 MB. Toda samo zato, ker je tam mogoče postaviti velike dokumente, njihovo shranjevanje tam ni dobra ideja. MongoDB bo najbolje deloval, če shranjujete posamezne dokumente, ki so veliki nekaj kilobajtov, in jih obravnavate bolj kot vrstice v široki tabeli SQL. Veliki dokumenti bodo vir težav .
Ustvarjanje dokumentov z velikimi nizi
Dokumenti lahko vsebujejo polja. Najbolje je, če je število elementov v nizu daleč od štirimestnega števila. Če se elementi pogosto dodajajo v matriko, bo prerasla dokument, ki jo vsebuje, in bo morala biti , kar pomeni, da bo treba . Pri ponovnem indeksiranju dokumenta z velikim poljem bodo indeksi pogosto prepisani, saj obstaja , ki hrani svoj indeks. To ponovno indeksiranje se zgodi tudi, ko je dokument vstavljen ali izbrisan.
MongoDB ima nekaj, kar se imenuje , ki zagotavlja prostor za rast dokumentov, da se zmanjša ta težava.
Morda mislite, da lahko storite brez indeksiranja matrike. Na žalost lahko pomanjkanje indeksov povzroči druge težave. Ker se dokumenti skenirajo od začetka do konca, bo iskanje elementov na koncu polja trajalo dlje, večina operacij, povezanih s takim dokumentom, pa bo .
Ne pozabite, da je vrstni red stopenj v združevanju pomemben
V sistemu baze podatkov z optimizatorjem poizvedb so poizvedbe, ki jih napišete, razlage, kaj želite dobiti, in ne, kako to pridobiti. Ta mehanizem deluje po analogiji z naročanjem v restavraciji: običajno preprosto naročite jed in kuharju ne daste podrobnih navodil.
V MongoDB dajete navodila kuharju. Na primer, zagotoviti morate, da podatki prehajajo reduce čim prej v pripravi $match и $project, razvrščanje pa se izvede šele po reducein da se iskanje izvaja v točno tistem vrstnem redu, kot ga potrebujete. Če imate optimizator poizvedb, ki odpravi nepotrebno delo, optimalno zaporedje korakov in izbiro vrst povezav, vas lahko razvaja. Z MongoDB imate več nadzora za ceno priročnosti.
Orodja kot bo poenostavil gradnjo agregacijskih poizvedb v . Funkcija urejevalnika združevanja vam omogoča, da izjave o cevovodu uporabite eno stopnjo naenkrat ter pregledate vhodne in izhodne podatke na vsaki stopnji, da poenostavite odpravljanje napak.
Uporaba hitrega snemanja
Možnosti pisanja MongoDB nikoli ne nastavite tako, da imajo visoko hitrost, a nizko zanesljivost. Ta način "vnesi in pozabi" se zdi hitro, ker je ukaz vrnjen, preden pride do pisanja. Če se sistem zruši, preden se podatki zapišejo na disk, se izgubijo in končajo v nedoslednem stanju. Na srečo ima 64-bitni MongoDB omogočeno beleženje.
Mehanizem za shranjevanje MMAPv1 in WiredTiger uporabljata beleženje, da to preprečita, čeprav lahko WiredTiger obnovi do zadnje skladne , če je beleženje onemogočeno.
Dnevnik zagotavlja, da je baza podatkov po obnovitvi v konsistentnem stanju in hrani vse podatke, dokler niso zapisani v dnevnik. Pogostost snemanja se konfigurira s parametrom .
Če želite biti prepričani o vnosih, se prepričajte, da je v konfiguracijski datoteki omogočeno beleženje ), pogostost posnetkov pa ustreza količini informacij, ki si jih lahko privoščite izgubiti.
Razvrščanje brez indeksa
Pri iskanju in združevanju je pogosto treba razvrstiti podatke. Upajmo, da bo to storjeno na eni od zadnjih stopenj, po filtriranju rezultatov, da se zmanjša količina podatkov, ki jih je treba razvrstiti. In tudi v tem primeru boste potrebovali za razvrščanje . Uporabite lahko enojni ali sestavljeni indeks.
Če ni ustreznega indeksa, bo MongoDB opravil brez njega. Skupna velikost vseh dokumentov v pomnilniku je omejena na 32 MB , in če MongoDB doseže to mejo, bo izdal napako ali se vrnil .
Iskanje brez podpore za indeks
Iskalne poizvedbe izvajajo podobno funkcijo kot operacija JOIN v SQL. Za najboljše delovanje potrebujejo indeks vrednosti ključa, uporabljenega kot tuji ključ. To ni očitno, ker se uporaba ne odraža v explain(). Takšni indeksi so poleg indeksa, zapisanega v explain(), ki ga uporabljajo operaterji cevovodov $match и $sort, ko se srečata na začetku plinovoda. Indeksi lahko zdaj pokrivajo katero koli stopnjo .
Izključitev uporabe večkratnih posodobitev
Metoda uporablja se za spremembo dela obstoječega dokumenta ali celotnega dokumenta, do popolne zamenjave, odvisno od parametra, ki ga določite . Kar ni tako očitno, je, da ne bo obdelal vseh dokumentov v zbirki, razen če nastavite možnost za posodobitev vseh dokumentov, ki ustrezajo kriterijem zahteve.
Ne pozabite na pomen vrstnega reda ključev v zgoščevalni tabeli
V JSON je objekt sestavljen iz neurejene zbirke velikosti nič ali več parov ime/vrednost, kjer je ime niz, vrednost pa niz, število, logična vrednost, nič, predmet ali matrika.
BSON na žalost daje velik poudarek vrstnemu redu pri iskanju. V MongoDB vrstni red ključev znotraj vgrajenih objektov , tj. { firstname: "Phil", surname: "factor" } - to ni isto kot { { surname: "factor", firstname: "Phil" }. To pomeni, da morate shraniti vrstni red parov ime/vrednost v svojih dokumentih, če želite biti prepričani, da jih boste našli.
Naj vas ne zmede "Nič" и "nedoločeno"
Vrednost "nedoločeno" glede na to ni bil nikoli veljaven v JSON JSON (ECMA-404 Razdelek 5), čeprav se uporablja v JavaScriptu. Poleg tega je za BSON zastarel in se pretvori v $null, kar ni vedno dobra rešitev. .
Uporaba $limit() brez $sort()
Precej pogosto, ko razvijate v MongoDB, je koristno videti samo vzorec rezultata, ki bo vrnjen iz poizvedbe ali združevanja. Za to nalogo boste potrebovali $limit(), vendar nikoli ne sme biti v končni kodi, razen če ga prej uporabite $sort. Ta mehanika je potrebna, ker drugače ne morete zagotoviti vrstnega reda rezultata in ne boste mogli zanesljivo videti podatkov. Na vrhu rezultata boste glede na razvrščanje dobili različne vnose. Za zanesljivo delovanje morajo biti poizvedbe in združevanja deterministični, kar pomeni, da dajejo enake rezultate vsakič, ko se izvedejo. Koda, ki vsebuje $limit(), vendar ne $sort, ne bo determinističen in lahko posledično povzroči napake, ki jih bo težko izslediti.
Zaključek
Edini način, da ste razočarani nad MongoDB, je, da ga neposredno primerjate z drugo vrsto baze podatkov, kot je DBMS, ali da ga začnete uporabljati na podlagi določenih pričakovanj. To je tako, kot če bi pomarančo primerjali z vilicami. Sistemi baz podatkov služijo posebnim namenom. Najbolje je, da sami razumete in cenite te razlike. Škoda bi bilo pritiskati na razvijalce MongoDB zaradi poti, ki jih je prisilila na pot DBMS. Želim videti nove in zanimive načine za reševanje starih problemov, kot je zagotavljanje celovitosti podatkov in ustvarjanje podatkovnih sistemov, ki so odporni na napake in zlonamerne napade.
MongoDB-ova uvedba transakcijske transakcije ACID v različici 4.0 je dober primer uvajanja pomembnih izboljšav na inovativen način. Transakcije z več dokumenti in več izjavami so zdaj atomske. Prav tako je mogoče prilagoditi čas, potreben za pridobitev ključavnic in prekinitev zastalih transakcij, ter spremeniti stopnjo izolacije.
Preberi več:
Vir: www.habr.com