Artikkelin käännös valmistettiin kurssin alkamisen aattona .
Poimintoja:
- On erittäin tärkeää kehittää skeema, vaikka se on valinnainen MongoDB:ssä.
- Samoin indeksien on vastattava malliasi ja käyttömallejasi.
- Vältä käyttämästä suuria esineitä ja suuria ryhmiä.
- Ole varovainen MongoDB-asetusten kanssa, varsinkin kun kyse on turvallisuudesta ja luotettavuudesta.
- MongoDB:ssä ei ole kyselyn optimoijaa, joten sinun on oltava varovainen suorittaessasi kyselytoimintoja.
Olen työskennellyt tietokantojen kanssa hyvin pitkään, mutta löysin vasta äskettäin MongoDB:n. Haluaisin tietää muutaman asian ennen kuin aloin työskennellä sen parissa. Kun henkilöllä on jo kokemusta tietystä alasta, hänellä on ennakkokäsityksiä siitä, mitä tietokannat ovat ja mitä he tekevät. Haluan helpottaa muiden ymmärtämistä esitän luettelon yleisistä virheistä.
MongoDB-palvelimen luominen ilman todennusta
Valitettavasti MongoDB on oletusarvoisesti asennettu ilman todennusta. Tämä käytäntö on normaalia paikallisesti käytettävälle työasemalle. Mutta koska MongoDB on monen käyttäjän järjestelmä, joka haluaa käyttää suuria määriä muistia, on parempi, jos laitat sen palvelimelle, jossa on mahdollisimman paljon RAM-muistia, vaikka aiot käyttää sitä vain kehittämiseen. Asennus palvelimelle oletusportin kautta voi olla ongelmallista, varsinkin jos pyynnössä voidaan suorittaa mikä tahansa javascript-koodi (esim. $where ideana varten ).
Todennusmenetelmiä on useita, mutta helpoin on asettaa käyttäjätunnus/salasana. Käytä tätä ideaa, kun ajattelet hienoa autentikointia . Mitä tulee tietoturvaan, MongoDB:tä tulee päivittää jatkuvasti, ja lokit tulee aina tarkistaa luvattoman käytön varalta. Haluan esimerkiksi valita toisen portin oletusportiksi.
Älä unohda sitoa hyökkäyspintasi MongoDB:hen
sisältää hyviä vinkkejä verkkoon tunkeutumisen ja tietovuotojen riskin vähentämiseen. Se on helppo harjata pois ja sanoa, että kehityspalvelin ei tarvitse korkeaa suojaustasoa. Se ei kuitenkaan ole niin yksinkertaista, ja tämä koskee kaikkia MongoDB-palvelimia. Varsinkin, jos käyttöön ei ole pakottavaa syytä , tai , sinun on poistettava mielivaltaisen koodin käyttö JavaScriptissä kirjoittamalla määritystiedostoon . Koska datatiedostoja ei ole salattu tavallisessa MongoDB:ssä, on järkevää käyttää MongoDB:tä , jolla on täysi pääsy tiedostoihin, rajoitettu pääsy vain siihen ja mahdollisuus käyttää käyttöjärjestelmän omia tiedostojen käyttöoikeuksia.
Virhe kehitettäessä piiriä
MongoDB ei käytä skeemaa. Mutta tämä ei tarkoita, että järjestelmää ei tarvita. Jos haluat vain tallentaa asiakirjoja ilman yhtenäistä kuviota, niiden tallentaminen voi olla nopeaa ja helppoa, mutta niiden hakeminen myöhemmin voi olla vaikeaa. .
Klassinen artikkeli" Se kannattaa lukea ja sisältää mm kolmannen osapuolen työkalussa Studio 3T kannattaa käyttää piirien säännöllisiin tarkastuksiin.
Älä unohda lajittelujärjestystä
Lajittelujärjestyksen unohtaminen voi aiheuttaa enemmän turhautumista ja tuhlata enemmän aikaa kuin mikään muu virheellinen kokoonpano. Oletuksena MongoBD käyttää . Mutta tuskin siitä on kenellekään hyötyä. Kirjainkoolla, korostukselle herkällä ja binäärilajilla pidettiin omituisia anakronismeja helmien, kaftaanien ja kiharan viiksien ohella viime vuosisadan 80-luvulla. Nyt niiden käyttö on anteeksiantamatonta. Tosielämässä "moottoripyörä" on sama kuin "moottoripyörä". Ja "Britannia" ja "Britannia" ovat sama paikka. Pieni kirjain on yksinkertaisesti ison kirjaimen vastine. Äläkä aloita minua lajittelemaan diakriittisiä merkkejä. Kun luot tietokantaa MongoDB:ssä, käytä aksentittelematonta lajittelua ja , jotka vastaavat kieltä ja . Tämä tekee merkkijonotietojen etsimisestä paljon helpompaa.
Luo kokoelmia suurilla asiakirjoilla
MongoDB isännöi mielellään suuria, jopa 16 megatavun kokoisia asiakirjoja Suunniteltu suurille yli 16 megatavun asiakirjoille. Mutta vain siksi, että sinne voidaan sijoittaa suuria asiakirjoja, niiden säilyttäminen siellä ei ole hyvä idea. MongoDB toimii parhaiten, jos tallennat yksittäisiä asiakirjoja, jotka ovat kooltaan muutaman kilotavun, ja käsittelet niitä enemmän riveinä laajassa SQL-taulukossa. Suuret asiakirjat aiheuttavat ongelmia .
Asiakirjojen luominen suurilla matriiseilla
Asiakirjat voivat sisältää taulukoita. On parasta, jos taulukon elementtien lukumäärä on kaukana nelinumeroisesta luvusta. Jos elementtejä lisätään taulukkoon usein, se kasvaa ulos sen sisältävästä asiakirjasta ja sen täytyy olla , mikä tarkoittaa, että se on tarpeen . Kun asiakirjaa indeksoidaan uudelleen suurella taulukolla, indeksit usein korvataan, koska siellä on , joka tallentaa hakemistonsa. Tämä uudelleenindeksointi tapahtuu myös, kun asiakirja lisätään tai poistetaan.
MongoDB:llä on jotain nimeltään , joka tarjoaa tilaa asiakirjoille kasvaa tämän ongelman minimoimiseksi.
Saatat ajatella, että voit tehdä ilman taulukon indeksointia. Valitettavasti indeksien puute voi aiheuttaa muita ongelmia. Koska asiakirjat skannataan alusta loppuun, taulukon lopusta olevien elementtien etsiminen kestää kauemmin ja useimmat tällaiseen asiakirjaan liittyvät toiminnot .
Älä unohda, että yhdistämisen vaiheiden järjestyksellä on merkitystä
Tietokantajärjestelmässä, jossa on kyselyn optimoija, kirjoittamasi kyselyt ovat selityksiä siitä, mitä haluat saada, eivät miten saada se. Tämä mekanismi toimii analogisesti ravintolassa tilaamisen kanssa: yleensä tilaat vain annoksen, etkä anna kokille yksityiskohtaisia ohjeita.
MongoDB:ssä ohjaat kokkia. Sinun on esimerkiksi varmistettava, että tiedot kulkevat läpi reduce mahdollisimman aikaisessa vaiheessa käyttöä $match и $project, ja lajittelu tapahtuu vasta sen jälkeen reduce, ja että haku tapahtuu juuri haluamassasi järjestyksessä. Kyselyn optimoija, joka eliminoi tarpeettoman työn, järjestää vaiheet optimaalisesti ja valitsee liitostyypit, voi pilata sinua. MongoDB:n avulla sinulla on enemmän hallintaa mukavuuden kustannuksella.
Työkalut kuten yksinkertaistaa koontikyselyjen rakentamista . Aggregation Editor -ominaisuuden avulla voit käyttää liukuhihnalauseita yksi vaihe kerrallaan ja tarkastaa tulo- ja lähtötiedot kussakin vaiheessa virheenkorjauksen yksinkertaistamiseksi.
Pikanauhoituksen käyttäminen
Älä koskaan aseta MongoDB:n kirjoitusasetuksiin nopeaa mutta alhaista luotettavuutta. Tämä tila "tiedosto ja unohda" näyttää nopealta, koska komento palautetaan ennen kirjoitusta. Jos järjestelmä kaatuu ennen kuin tiedot on kirjoitettu levylle, se katoaa ja päätyy epäjohdonmukaiseen tilaan. Onneksi 64-bittisessä MongoDB:ssä on kirjaus käytössä.
MMAPv1- ja WiredTiger-tallennusmoottorit käyttävät lokia estääkseen tämän, vaikka WiredTiger voi palautua viimeiseen yhdenmukaiseen , jos kirjaus on poistettu käytöstä.
Päiväkirjaus varmistaa, että tietokanta on johdonmukaisessa tilassa palautuksen jälkeen ja säilyttää kaikki tiedot, kunnes ne kirjoitetaan päiväkirjaan. Tallenteiden taajuus määritetään parametrilla .
Varmistaaksesi merkinnät, varmista, että lokikirjaus on otettu käyttöön asetustiedostossa ), ja tallennustiheys vastaa tiedon määrää, jonka sinulla on varaa menettää.
Lajittelu ilman indeksiä
Haettaessa ja aggregoitaessa on usein tarve lajitella tietoja. Toivotaan, että tämä tehdään jossain viimeisessä vaiheessa, tuloksen suodattamisen jälkeen lajiteltavan tiedon määrän vähentämiseksi. Ja jopa tässä tapauksessa tarvitset lajittelua varten . Voit käyttää yksittäisindeksiä tai yhdistelmäindeksiä.
Jos sopivaa indeksiä ei ole, MongoDB pärjää ilman sitä. Muistirajoitus on 32 megatavua kaikkien sisään olevien asiakirjojen kokonaiskoon , ja jos MongoDB saavuttaa tämän rajan, se joko antaa virheilmoituksen tai palauttaa sen .
Hae ilman hakemistotukea
Hakukyselyt suorittavat samanlaisen toiminnon kuin JOIN-toiminto SQL:ssä. Toimiakseen parhaiten he tarvitsevat vieraana avaimena käytetyn avaimen arvon indeksin. Tämä ei ole ilmeistä, koska käyttö ei heijastu explain(). Tällaiset indeksit ovat kirjoitetun indeksin lisäksi explain(), jota vuorostaan käyttävät putkioperaattorit $match и $sort, kun ne kohtaavat putkilinjan alussa. Indeksit voivat nyt kattaa minkä tahansa vaiheen .
Monen päivityksen käytöstä poistaminen
menetelmä käytetään muuttamaan osaa olemassa olevasta asiakirjasta tai koko asiakirjasta, jopa täydelliseen korvaamiseen, riippuen määrittämästäsi parametrista . Ei ole niin ilmeistä, että se ei käsittele kaikkia kokoelman asiakirjoja, ellet aseta asetusta päivittää kaikki asiakirjat, jotka täyttävät pyyntöehdot.
Älä unohda avainten järjestyksen merkitystä hash-taulukossa
JSONissa objekti koostuu järjestämättömästä kokoelmasta, jonka koko on nolla tai useampi nimi/arvo-pari, jossa nimi on merkkijono ja arvo on merkkijono, numero, looginen arvo, nolla, objekti tai taulukko.
Valitettavasti BSON painottaa paljon järjestystä etsiessään. MongoDB:ssä avainten järjestys sisäänrakennetuissa objekteissa , ts. { firstname: "Phil", surname: "factor" } - tämä ei ole sama kuin { { surname: "factor", firstname: "Phil" }. Toisin sanoen sinun on tallennettava asiakirjoihin nimi/arvo-parien järjestys, jos haluat olla varma niiden löytämisestä.
Älä sekoita "Tyhjä" и "määrittämätön"
Arvo "määrittämätön" ei ollut koskaan voimassa JSONissa, mukaan JSON (ECMA-404 Section 5), vaikka sitä käytetään JavaScriptissä. Lisäksi BSONille se on vanhentunut ja muunnetaan muotoon $null, mikä ei aina ole hyvä ratkaisu. .
Käyttää $limit() без $sort()
Kun kehität MongoDB:ssä, on usein hyödyllistä nähdä vain näyte tuloksesta, joka palautetaan kyselystä tai aggregaatiosta. Tätä tehtävää varten tarvitset $limit(), mutta sen ei pitäisi koskaan olla lopullisessa koodissa, ellet käytä sitä aiemmin $sort. Tämä mekaniikka on välttämätön, koska muuten et voi taata tuloksen järjestystä, etkä pysty tarkastelemaan tietoja luotettavasti. Tuloksen yläreunassa on erilaisia merkintöjä lajittelusta riippuen. Toimiakseen luotettavasti kyselyjen ja aggregaatioiden on oltava deterministisiä, eli niiden on tuotettava samat tulokset joka kerta, kun ne suoritetaan. Koodi, joka sisältää $limit(), mutta ei $sort, ei ole deterministinen ja voi myöhemmin aiheuttaa virheitä, joita on vaikea jäljittää.
Johtopäätös
Ainoa tapa olla pettynyt MongoDB:hen on verrata sitä suoraan toisen tyyppiseen tietokantaan, kuten DBMS:ään, tai ryhtyä käyttämään sitä tiettyjen odotusten perusteella. Se on kuin vertaisi appelsiinia haarukkaan. Tietokantajärjestelmät palvelevat tiettyjä tarkoituksia. On parasta yksinkertaisesti ymmärtää ja arvostaa nämä erot itse. Olisi sääli painostaa MongoDB-kehittäjiä tielle, joka pakotti heidät DBMS-polulle. Haluan nähdä uusia ja mielenkiintoisia tapoja ratkaista vanhoja ongelmia, kuten varmistaa tietojen eheys ja luoda tietojärjestelmiä, jotka kestävät epäonnistumisia ja haitallisia hyökkäyksiä.
MongoDB:n ACID-transaktioiden käyttöönotto versiossa 4.0 on hyvä esimerkki tärkeiden parannusten käyttöönotosta innovatiivisella tavalla. Usean asiakirjan ja usean lausunnon tapahtumat ovat nyt ydinliikettä. On myös mahdollista säätää lukkojen hankkimiseen ja jumiutuneiden tapahtumien lopettamiseen tarvittavaa aikaa sekä muuttaa eristystasoa.
Lue lisää:
Lähde: will.com