Oversættelsen af artiklen er udarbejdet forud for begyndelsen af kurset .
Hovedpunkter:
- Det er yderst vigtigt at udvikle et skema, selvom det ikke er obligatorisk i MongoDB.
- På samme måde skal indekserne svare til dit skema og adgangsmønstre.
- Undgå at bruge store objekter og store arrays.
- Vær opmærksom på indstillingerne for MongoDB, især når det gælder sikkerhed og pålidelighed.
- Der er ingen forespørgselsoptimerer i MongoDB, så du skal være forsigtig, når du udfører forespørgselsoperationer.
Jeg har arbejdet med databaser i lang tid, men først for nylig opdagede jeg MongoDB. Der er flere ting, jeg gerne ville have vidst, før jeg begyndte at arbejde med det. Når en person allerede har erfaring inden for et bestemt område, har de forudindtagede forestillinger om, hvad databaser er, og hvad de gør. For at lette forståelsen for andre præsenterer jeg en liste over almindelige fejltagelser.
At oprette en MongoDB-server uden godkendelse
Desværre bliver MongoDB som standard installeret uden godkendelse. For en arbejdstation, der tilgås lokalt, er denne praksis acceptabel. Men da MongoDB er et multibruger-system, der elsker at bruge store mængder hukommelse, vil det være bedre at installere det på en server med den maksimale mulige mængde RAM i dine forhold, selvom du kun har tænkt dig at bruge den til udvikling. En installation på server via standardporten kan være problematisk, især hvis der kan udføres godkendt javascript-kode i forespørgslen (f.eks. $where som en idé til ).
Der er flere godkendelsesmetoder, men det nemmeste er at sætte et ID/password for brugeren. Brug denne idé, mens du overvejer en mere kreativ godkendelse baseret på . Når det kommer til sikkerhed, skal MongoDB konstant opdateres, og logfilerne skal altid kontrolleres for uautoriseret adgang. Jeg kan f.eks. godt lide at vælge en anden port som standardport.
Glem ikke at binde angrebsoverfladen til MongoDB
indeholder gode råd til at mindske risikoen for netværksindtrængen og datalæk. Det er let at affeje og sige, at en udviklingsserver ikke har brug for et højt sikkerhedsniveau. Men det er ikke så enkelt, og dette gælder for alle MongoDB-servere. Især hvis der ikke er en god grund til at bruge , eller , skal du deaktivere brugen af vilkårlig kode i JavaScript ved at skrive i konfigurationsfilen . Da standard MongoDB-databaser ikke er krypteret, er det fornuftigt at køre MongoDB med , som har fuld adgang til filerne, med begrænset adgang kun for ham og muligheden for at bruge egne midler til filadgangskontrol fra operativsystemet.
Fejl ved skemadesign
MongoDB bruger ikke et schema. Men det betyder ikke, at et schema ikke er nødvendigt. Hvis du blot vil opbevare dokumenter uden et sammenhængende schema, kan du hurtigt og nemt gemme dem, men det kan være .
Den klassiske artikel “ er værd at læse, og funktioner som i det tredjeparts værktøj Studio 3T, bør bruges til regelmæssige skemaeftersyn.
Glem ikke sorteringsrækkefølgen
At glemme sorteringsrækkefølgen kan føre til den største skuffelse og tage mere tid end at bruge enhver anden forkert konfiguration. Som standard bruger MongoDB . Men det er næppe nyttigt for nogen. Case-sensitive, aksentuerede, binære sorteringer blev anset for nysgerrige anachronismer sammen med perler, kaftaner og krøllede overskæg tilbage i 80’erne. Nu er deres brug uacceptabel. I den virkelige verden er “motorcykel” det samme som “Motorcykel”. Og “Britannien” og “britannia” er det samme sted. Små bogstaver er blot den lille bogstavers ækvivalent af store bogstaver. Og lad mig ikke starte på sortering af diakritiske tegn. Når du opretter en database i MongoDB, skal du bruge sorteringsparametre uden hensyn til aksenter og , som svarer til sproget og . Dette vil betydeligt lette søgning af strenge data.
Oprettelse af samlinger med store dokumenter
MongoDB er glad for at kunne opbevare store dokumenter på op til 16 MB i samlinger, og er designet til store dokumenter, der overstiger 16 MB. Men blot fordi store dokumenter kan opbevares der, er det ikke den bedste idé at gemme dem der. Det fungerer bedst, hvis du opbevarer separate dokumenter på flere kilobyte, og betragter dem mere som rækker i en bred SQL-tabel. Store dokumenter vil skabe problemer med .
Oprettelse af dokumenter med store arrays
Dokumenter kan indeholde arrays. Det er bedst, hvis antallet af elementer i arrayet er langt fra fire cifre. Hvis der ofte tilføjes elementer til arrayet, vil det vokse ud over det dokument, der indeholder det, og det bliver nødvendigt at , så det bliver nødvendigt at . Når dokumentet med et stort array genindekseres, vil indekser ofte blive overskrevet, da der findes , der gemmer dets indeks. En sådan genindeksering finder også sted, når et dokument indsættes eller slettes.
I MongoDB findes der såkaldt , som giver plads til, at dokumenter kan vokse, for at minimere dette problem.
Du kan tænke, at du kan undvære indeksering af arrays. Desværre kan fraværet af indekser føre til andre problemer. Da dokumenter gennemgås fra start til slut, vil søgning efter elementer i slutningen af arrayet tage længere tid, og de fleste operationer relateret til et sådant dokument vil være .
Husk, at rækkefølgen af faser i aggregeringen betyder noget
I et databasesystem med en forespørgselsoptimerer er de forespørgsler, du skriver, forklaringer på, hvad du ønsker at modtage, og ikke hvordan man opnår det. Denne mekanisme fungerer på samme måde som at bestille i en restaurant: normalt bestiller du blot en ret, i stedet for at give detaljerede instruktioner til kokken.
I MongoDB instruerer du kokken. For eksempel skal du sørge for, at dataene passerer gennem reduce så tidligt som muligt i pipeline med hjælp fra $match og $project, og sorteringen sker kun bagefter reduce, og at søgningen sker præcis i den rækkefølge, du har brug for. Tilstedeværelsen af en forespørgselsoptimerer, der fjerner unødvendigt arbejde, optimalt sorterer faserne og vælger forbindelsestypen, kan forkæle dig. I MongoDB får du mere kontrol for prisen på bekvemmelighed.
Værktøjer som vil forenkle opbygningen af aggregeringsforespørgsler i . Aggregation Editor-funktionen giver dig mulighed for at anvende pipeline-operatorer et skridt ad gangen og samtidig kontrollere ind- og uddata på hvert skridt for at lette fejlfinding.
Brug af hurtig skrivning
Sæt aldrig højhastighedsskriveindstillinger med lav pålidelighed i MongoDB. Denne tilstand "file-and-forget" kan virke hurtig, da kommandoen returneres, før skrivningen finder sted. Hvis systemet går ned, før dataene er skrevet til disken, vil de gå tabt og være i en inkonsistent tilstand. Heldigvis er logging inkluderet i 64-bit MongoDB.
Lagringsmotorerne MMAPv1 og WiredTiger bruger logging for at forhindre dette, selvom WiredTiger kan gendanne sig til det seneste konsistente , hvis logging er deaktiveret.
Logging sikrer, at databasen forbliver i en konsistent tilstand efter en gendannelse og gemmer alle data indtil skrivningen til loggen. Hyppigheden af skrivninger kan justeres ved hjælp af parameteren .
For at være sikker på skrivningerne, skal du sørge for, at logging er aktiveret i konfigurationsfilen ), og at skrivningshyppigheden svarer til det volumen af information, du har råd til at miste.
Sortering uden indeks
Når der søges og aggregeres, opstår der ofte behov for at sortere data. Lad os håbe, at dette sker i en af de afsluttende faser, efter at resultaterne er filtreret for at reducere mængden af data, der skal sorteres. Og selv i så fald har du brug for en . Du kan bruge et enkelt eller sammensat indeks.
Hvis der ikke findes et passende indeks, klarer MongoDB sig uden det. Der er en hukommelsesgrænse på 32 MB for den samlede størrelse af alle dokumenter i , og hvis MongoDB når denne grænse, vil den enten returnere en fejl, eller returnere .
Søgning uden indeksunderstøttelse
Søgeforespørgsler udfører en funktion svarende til operationen JOIN i SQL. For at fungere optimalt har de brug for en nøgleværdiindeks, som anvendes som en fremmed nøgle. Det er ikke åbenlyst, da brugen ikke er reflekteret i explain(). Sådanne indekser er et supplement til indekset, der er registreret i explain(), som igen bruges af pipeline-operators $match og $sort, når de forekommer i starten af pipelinen. Indekser kan nu dække enhver fase .
Afvisning af at bruge multi-opdateringer
Metoden bruges til at ændre en del af et eksisterende dokument eller et helt dokument, op til fuld erstatning afhængigt af den parameter, du angiver . Det er ikke så indlysende, at det ikke vil behandle alle dokumenter i samlingen, medmindre du angiver parameteren for at opdatere alle dokumenter, der opfylder forespørgselskriterierne.
Glem ikke vigtigheden af nøglerækkefølge i en hash-tabel
I JSON er et objekt en usorteret samling af nul eller flere navn/værdi-par, hvor navnet er en streng, og værdien kan være en streng, et tal, en boolesk værdi, nul, et objekt eller et array.
Desværre tillægger BSON stor betydning for rækkefølgen under søgning. I MongoDB har rækkefølgen af nøgler inden for indlejrede objekter , dvs. { firstname: "Phil", surname: "factor" } er ikke det samme som { { surname: "factor", firstname: "Phil" }. Det vil sige, at du skal bevare rækkefølgen af navn/værdi-par i dokumenterne, hvis du vil være sikker på at finde dem.
Forveksle ikke "null" og "undefined"
Værdi "undefined" har aldrig været gyldig i JSON, ifølge JSON (ECMA-404, Afsnit 5), på trods af at det bruges i JavaScript. Derudover er det for BSON forældet og bliver konverteret til $null, hvilket ikke altid er en god løsning. .
Brugen af $limit() uden $sort()
Meget ofte, når du udvikler i MongoDB, er det nyttigt bare at se et eksempel på det resultat, der vil komme fra forespørgslen eller aggregatorer. Til denne opgave vil du finde $limit(), men det bør aldrig være i den endelige version af koden, medmindre du bruger det foran $sort. Denne mekanisme er nødvendig, da du ellers ikke kan garantere rækkefølgen af resultatet, og du ikke vil kunne gennemse dataene pålideligt. I toppen af resultatet vil du få forskellige poster afhængigt af sorteringen. For at sikre pålidelig drift skal forespørgsler og aggregationer være deterministiske, hvilket betyder, at de skal give de samme resultater ved hver udførelse. Kode, der har $limit(), men ikke $sort, vil ikke være deterministisk og kan senere forårsage fejl, som vil være svære at opspore.
Konklusion
Den eneste måde at blive skuffet over MongoDB på er at sammenligne det direkte med en anden type databasesystem, såsom en relationsdatabase, eller at komme til at bruge det baseret på nogle bestemte forventninger. Det er som at sammenligne en appelsin med en gaffel. Databasesystemer forfølger bestemte mål. Det er bedst bare at forstå og værdsætte disse forskelle for sig selv. Det ville være en skam at presse udviklerne af MongoDB på grund af den vej, de har været nødt til at gå for at blive et databasesystem. Jeg vil gerne se nye og interessante måder at løse gamle problemer på, såsom at sikre dataintegritet og skabe datassystemer, der er robuste over for nedbrud og angreb fra skurke.
Implementeringen af ACID-transaktionalitet i MongoDB-version 4.0 er et godt eksempel på implementeringen af vigtige forbedringer på en innovativ måde. Multi-dokument og multi-operator transaktioner er nu atomare. Derudover er der kommet mulighed for at regulere den tid, der er nødvendig for at opnå låse, og afslutte hængende transaktioner, samtidig med at niveauet for isolation kan ændres.
Læs mere:
Kilde: habr.com
