Oversettelsen av artikkelen ble utarbeidet like før kursstart .
Høydepunkter:
- Det er ekstremt viktig å utvikle et skjema selv om det er valgfritt i MongoDB.
- På samme måte må indekser samsvare med skjemaet og tilgangsmønstrene dine.
- Unngå å bruke store gjenstander og store matriser.
- Vær forsiktig med MongoDB-innstillinger, spesielt når det kommer til sikkerhet og pålitelighet.
- MongoDB har ikke en spørringsoptimerer, så du må være forsiktig når du utfører spørringsoperasjoner.
Jeg har jobbet med databaser i veldig lang tid, men oppdaget nylig MongoDB. Det er et par ting jeg skulle ønske jeg visste før jeg begynte å jobbe med det. Når en person allerede har erfaring innen et bestemt felt, har de forutinntatte forestillinger om hva databaser er og hva de gjør. I håp om å gjøre det lettere for andre å forstå, presenterer jeg en liste over vanlige feil.
Opprette en MongoDB-server uten autentisering
Dessverre er MongoDB installert uten autentisering som standard. For en arbeidsstasjon som er tilgjengelig lokalt, er denne praksisen normal. Men siden MongoDB er et flerbrukersystem som liker å bruke store mengder minne, vil det være bedre om du legger det på en server med så mye RAM som mulig, selv om du kun skal bruke det til utvikling. Installering på serveren via standardporten kan være problematisk, spesielt hvis en hvilken som helst javascript-kode kan kjøres i forespørselen (f.eks. $where som en idé for ).
Det finnes flere autentiseringsmetoder, men det enkleste er å angi bruker-ID/passord. Bruk denne ideen mens du tenker på fancy autentisering basert på . Når det gjelder sikkerhet, bør MongoDB kontinuerlig oppdateres, og logger bør alltid sjekkes for uautorisert tilgang. For eksempel liker jeg å velge en annen port som standardport.
Ikke glem å binde angrepsflaten til MongoDB
inneholder gode tips for å redusere risikoen for nettverksinntrenging og datalekkasje. Det er lett å børste det av og si at en utviklingsserver ikke trenger et høyt sikkerhetsnivå. Det er imidlertid ikke så enkelt, og dette gjelder alle MongoDB-servere. Spesielt hvis det ikke er noen tvingende grunn til å bruke , eller , må du deaktivere bruken av vilkårlig kode i JavaScript ved å skrive inn konfigurasjonsfilen . Siden datafiler ikke er kryptert i standard MongoDB, er det fornuftig å kjøre MongoDB med , som har full tilgang til filer, med begrenset tilgang kun til den og muligheten til å bruke operativsystemets egne filtilgangskontroller.
Feil under utvikling av kretsen
MongoDB bruker ikke et skjema. Men dette betyr ikke at ordningen ikke er nødvendig. Hvis du bare vil lagre dokumenter uten noe konsistent mønster, kan det være raskt og enkelt å lagre dem, men det kan være vanskelig å hente dem senere. .
Klassisk artikkel " Det er verdt å lese, og funksjoner som i tredjepartsverktøyet Studio 3T er det verdt å bruke for regelmessige kontroller av kretser.
Ikke glem sorteringsrekkefølgen
Å glemme sorteringsrekkefølge kan forårsake mer frustrasjon og kaste bort mer tid enn noen annen feil konfigurasjon. Som standard bruker MongoBD . Men det er neppe nyttig for noen. Store og små bokstaver, aksentsensitive, binære typer ble ansett som nysgjerrige anakronismer sammen med perler, kaftaner og krøllete barter tilbake på 80-tallet av forrige århundre. Nå er bruken deres utilgivelig. I det virkelige liv er "motorsykkel" det samme som "motorsykkel". Og "Storbritannia" og "Storbritannia" er samme sted. En liten bokstav er ganske enkelt den store ekvivalenten til en stor bokstav. Og ikke få meg i gang med å sortere diakritikk. Når du oppretter en database i MongoDB, bruk aksentufølsom sortering og , som tilsvarer språket og . Dette vil gjøre det mye enklere å søke gjennom strengdata.
Lag samlinger med store dokumenter
MongoDB er glad for å være vert for store dokumenter på opptil 16 MB i samlinger, og Designet for store dokumenter større enn 16 MB. Men bare fordi store dokumenter kan plasseres der, er det ingen god idé å lagre dem der. MongoDB vil fungere best hvis du lagrer individuelle dokumenter som er noen få kilobyte store, og behandler dem mer som rader i en bred SQL-tabell. Store dokumenter vil være en kilde til problemer med .
Opprette dokumenter med store arrays
Dokumenter kan inneholde matriser. Det er best hvis antallet elementer i matrisen er langt fra et firesifret tall. Hvis elementer legges til i en matrise ofte, vil den vokse ut av dokumentet som inneholder den og må , som betyr at det vil være nødvendig . Når du indekserer et dokument på nytt med et stort utvalg, vil indeksene ofte bli overskrevet, siden det er en , som lagrer indeksen. Denne reindekseringen skjer også når et dokument settes inn eller slettes.
MongoDB har noe som heter , som gir rom for dokumenter å vokse for å minimere dette problemet.
Du tror kanskje at du kan klare deg uten array-indeksering. Dessverre kan mangelen på indekser føre til at du får andre problemer. Siden dokumenter skannes fra start til slutt, vil det ta lengre tid å søke etter elementer på slutten av matrisen, og de fleste operasjoner knyttet til et slikt dokument vil bli .
Ikke glem at rekkefølgen på stadiene i en aggregering betyr noe
I et databasesystem med en query optimizer er spørringene du skriver forklaringer på hva du ønsker å få, ikke hvordan du får det. Denne mekanismen fungerer i analogi med bestilling på en restaurant: vanligvis bestiller du bare en rett, og gir ikke detaljerte instruksjoner til kokken.
I MongoDB instruerer du kokken. Du må for eksempel sørge for at dataene går igjennom reduce så tidlig som mulig i rørledningen ved hjelp av $match и $project, og sortering skjer først etter reduce, og at søket skjer i akkurat den rekkefølgen du ønsker. Å ha en spørringsoptimerer som eliminerer unødvendig arbeid, optimaliserer trinnene og velger sammenføyningstyper, kan skjemme deg bort. Med MongoDB har du mer kontroll på bekostning av bekvemmelighet.
Verktøy som vil forenkle konstruksjonen av aggregeringsspørringer i . Aggregation Editor-funksjonen lar deg bruke pipeline-setninger ett trinn om gangen, og inspisere inn- og utdata på hvert trinn for å forenkle feilsøkingen.
Bruke hurtigopptak
Sett aldri MongoDB skrivealternativer til å ha høy hastighet, men lav pålitelighet. Denne modusen "fil-og-glem" virker rask fordi kommandoen returneres før skrivingen skjer. Hvis systemet krasjer før dataene er skrevet til disk, vil de gå tapt og ende opp i en inkonsekvent tilstand. Heldigvis har 64-bit MongoDB logging aktivert.
MMAPv1- og WiredTiger-lagringsmotorene bruker logging for å forhindre dette, selv om WiredTiger kan gjenopprette til siste konsistente , hvis logging er deaktivert.
Journalføring sikrer at databasen er i en konsistent tilstand etter gjenoppretting og beholder alle data til de skrives til journalen. Frekvensen av opptak konfigureres ved hjelp av parameteren .
For å være sikker på oppføringene, sørg for at logging er aktivert i konfigurasjonsfilen ), og frekvensen av opptak tilsvarer mengden informasjon du har råd til å miste.
Sortering uten indeks
Ved søk og aggregering er det ofte behov for å sortere data. La oss håpe at dette gjøres på et av de siste stadiene, etter filtrering av resultatet for å redusere mengden data som sorteres. Og selv i dette tilfellet trenger du for sortering . Du kan bruke en enkelt eller sammensatt indeks.
Hvis det ikke er en passende indeks, vil MongoDB klare seg uten den. Det er en minnegrense på 32 MB på den totale størrelsen på alle dokumenter i , og hvis MongoDB når denne grensen, vil den enten gi en feil eller returnere .
Søk uten indeksstøtte
Søkespørringer utfører en funksjon som ligner JOIN-operasjonen i SQL. For å fungere best, trenger de indeksen til verdien av nøkkelen som brukes som fremmednøkkel. Dette er ikke åpenbart fordi bruken ikke gjenspeiles i explain(). Slike indekser kommer i tillegg til indeksen skrevet inn explain(), som igjen brukes av rørledningsoperatører $match и $sort, når de møtes i begynnelsen av rørledningen. Indekser kan nå dekke alle stadier .
Velge bort bruk av flere oppdateringer
metode brukes til å endre deler av et eksisterende dokument eller hele dokumentet, opp til en fullstendig erstatning, avhengig av parameteren du angir . Det som ikke er så åpenbart er at det ikke vil behandle alle dokumenter i samlingen med mindre du angir alternativet å oppdatere alle dokumenter som oppfyller forespørselskriteriene.
Ikke glem viktigheten av rekkefølgen på nøklene i en hash-tabell
I JSON består et objekt av en uordnet samling av størrelse null eller flere navn/verdi-par, der navn er en streng og verdi er en streng, tall, boolsk, null, objekt eller matrise.
Dessverre legger BSON stor vekt på orden ved søk. I MongoDB, rekkefølgen av nøkler i innebygde objekter , dvs. { firstname: "Phil", surname: "factor" } - dette er ikke det samme som { { surname: "factor", firstname: "Phil" }. Det vil si at du må lagre rekkefølgen på navn/verdipar i dokumentene dine hvis du vil være sikker på å finne dem.
Ikke bli forvirret "Null" и "udefinert"
Verdi "udefinert" var aldri gyldig i JSON, ifølge JSON (ECMA-404 Seksjon 5), selv om den brukes i JavaScript. Dessuten er den for BSON foreldet og konverteres til $null, som ikke alltid er en god løsning. .
Bruk $limit() без $sort()
Ganske ofte når du utvikler i MongoDB, er det nyttig å bare se et utvalg av resultatet som vil bli returnert fra en spørring eller aggregering. For denne oppgaven trenger du $limit(), men den skal aldri være i den endelige koden med mindre du bruker den før $sort. Denne mekanikeren er nødvendig fordi ellers kan du ikke garantere rekkefølgen på resultatet, og du vil ikke kunne se dataene pålitelig. Øverst i resultatet vil du få ulike poster avhengig av sorteringen. For å fungere pålitelig må spørringer og aggregeringer være deterministiske, det vil si gi de samme resultatene hver gang de utføres. Kode som inneholder $limit(), men nei $sort, vil ikke være deterministisk og kan i ettertid forårsake feil som vil være vanskelig å spore opp.
Konklusjon
Den eneste måten å bli skuffet over MongoDB er å sammenligne den direkte med en annen type database, for eksempel en DBMS, eller å bruke den basert på visse forventninger. Det er som å sammenligne en appelsin med en gaffel. Databasesystemer tjener spesifikke formål. Det er best å bare forstå og sette pris på disse forskjellene selv. Det ville være en skam å presse MongoDB-utviklerne over en bane som tvang dem ned DBMS-banen. Jeg ønsker å se nye og interessante måter å løse gamle problemer på, som å sikre dataintegritet og lage datasystemer som er motstandsdyktige mot feil og ondsinnede angrep.
MongoDBs introduksjon av ACID-transaksjonalitet i versjon 4.0 er et godt eksempel på å introdusere viktige forbedringer på en innovativ måte. Transaksjoner med flere dokumenter og flere erklæringer er nå atomære. Det er også mulig å justere tiden det tar å skaffe låser og avslutte fastlåste transaksjoner, samt endre isolasjonsnivået.
Les mer:
Kilde: www.habr.com