Oversættelsen af artiklen blev udarbejdet på tærsklen til kursets start .
Højdepunkter:
- Det er ekstremt vigtigt at udvikle et skema, selvom det er valgfrit i MongoDB.
- Ligeledes skal indekser matche dit skema og adgangsmønstre.
- Undgå at bruge store genstande og store arrays.
- Vær forsigtig med MongoDB-indstillinger, især når det kommer til sikkerhed og pålidelighed.
- MongoDB har ikke en forespørgselsoptimering, så du skal være forsigtig, når du udfører forespørgselsoperationer.
Jeg har arbejdet med databaser i meget lang tid, men først for nylig opdaget MongoDB. Der er et par ting, jeg ville ønske, jeg vidste, før jeg begyndte at arbejde med det. Når en person allerede har erfaring inden for et bestemt felt, har de forudfattede forestillinger om, hvad databaser er, og hvad de gør. I håb om at gøre det lettere for andre at forstå, præsenterer jeg en liste over almindelige fejl.
Oprettelse af en MongoDB-server uden godkendelse
Desværre er MongoDB installeret uden godkendelse som standard. For en arbejdsstation, der tilgås lokalt, er denne praksis normal. Men da MongoDB er et multi-user system, der kan lide at bruge store mængder hukommelse, vil det være bedre, hvis du lægger det på en server med så meget RAM som muligt, selvom du kun skal bruge det til udvikling. Installation på serveren via standardporten kan være problematisk, især hvis enhver javascript-kode kan udføres i anmodningen (f.eks. $where som en idé til ).
Der er flere autentificeringsmetoder, men den nemmeste er at indstille et bruger-id/adgangskode. Brug denne idé, mens du tænker på fancy autentificering baseret på . Når det kommer til sikkerhed, bør MongoDB konstant opdateres, og logs bør altid tjekkes for uautoriseret adgang. For eksempel kan jeg godt lide at vælge en anden port som standardport.
Glem ikke at binde din angrebsflade til MongoDB
indeholder gode råd til at mindske risikoen for netværksindtrængen og datalækage. Det er nemt at børste det af og sige, at en udviklingsserver ikke har brug for et højt sikkerhedsniveau. Det er dog ikke så enkelt, og det gælder for alle MongoDB-servere. Især hvis der ikke er nogen tvingende grund til at bruge , eller , skal du deaktivere brugen af vilkårlig kode i JavaScript ved at skrive i konfigurationsfilen . Da datafiler ikke er krypteret i standard MongoDB, giver det mening at køre MongoDB med , som har fuld adgang til filer, med begrænset adgang kun til det og mulighed for at bruge operativsystemets egne filadgangskontroller.
Fejl under udvikling af kredsløbet
MongoDB bruger ikke et skema. Men det betyder ikke, at ordningen ikke er nødvendig. Hvis du bare vil gemme dokumenter uden et konsistent mønster, kan det være hurtigt og nemt at gemme dem, men det kan være svært at hente dem senere. .
Klassisk artikel " Det er værd at læse, og funktioner som i tredjepartsværktøjet Studio 3T er det værd at bruge til regelmæssig kontrol af kredsløb.
Glem ikke sorteringsrækkefølgen
At glemme sorteringsrækkefølgen kan forårsage mere frustration og spilde mere tid end nogen anden forkert konfiguration. Som standard bruger MongoBD . Men det er usandsynligt, at det er nyttigt for nogen. Store og små bogstaver, accentfølsomme, binære sorter blev betragtet som nysgerrige anakronismer sammen med perler, kaftaner og krøllede overskæg tilbage i 80'erne af forrige århundrede. Nu er deres brug utilgivelig. I det virkelige liv er "motorcykel" det samme som "motorcykel". Og "Storbritannien" og "Storbritannien" er det samme sted. Et lille bogstav er simpelthen det store bogstav, der svarer til et stort bogstav. Og lad mig ikke begynde med at sortere diakritiske tegn. Når du opretter en database i MongoDB, skal du bruge accentufølsom sortering og , som svarer til sproget og . Dette vil gøre det meget nemmere at søge gennem strengdata.
Opret samlinger med store dokumenter
MongoDB er glad for at være vært for store dokumenter op til 16 MB i samlinger, og Designet til store dokumenter større end 16 MB. Men bare fordi store dokumenter kan placeres der, er det ikke en god idé at opbevare dem der. MongoDB vil fungere bedst, hvis du gemmer individuelle dokumenter, der er et par kilobyte store, og behandler dem mere som rækker i en bred SQL-tabel. Store dokumenter vil være en kilde til problemer med .
Oprettelse af dokumenter med store arrays
Dokumenter kan indeholde arrays. Det er bedst, hvis antallet af elementer i arrayet er langt fra et firecifret tal. Hvis elementer føjes til et array ofte, vil det vokse ud af dokumentet, der indeholder det, og det skal , hvilket betyder, at det bliver nødvendigt . Når man genindekserer et dokument med et stort array, vil indekserne ofte blive overskrevet, da der er en , som gemmer sit indeks. Denne genindeksering sker også, når et dokument indsættes eller slettes.
MongoDB har noget der hedder , som giver plads til, at dokumenter kan vokse for at minimere dette problem.
Du tror måske, at du kan undvære array-indeksering. Desværre kan manglen på indekser forårsage, at du får andre problemer. Da dokumenter scannes fra start til slut, vil søgning efter elementer i slutningen af arrayet tage længere tid, og de fleste operationer forbundet med et sådant dokument vil blive .
Glem ikke, at rækkefølgen af stadierne i en sammenlægning har betydning
I et databasesystem med en forespørgselsoptimering er de forespørgsler, du skriver, forklaringer på, hvad du ønsker at få, ikke hvordan du får det. Denne mekanisme fungerer analogt med bestilling på en restaurant: normalt bestiller du bare en ret og giver ikke detaljerede instruktioner til kokken.
I MongoDB instruerer du kokken. For eksempel skal du sørge for, at dataene passerer igennem reduce så tidligt som muligt i rørledningen ved hjælp af $match и $project, og sortering sker først efter reduce, og at søgningen sker i præcis den rækkefølge, du ønsker. At have en forespørgselsoptimering, der eliminerer unødvendigt arbejde, sekvenserer trin optimalt og vælger jointyper, kan forkæle dig. Med MongoDB har du mere kontrol på bekostning af bekvemmelighed.
Værktøjer som vil forenkle konstruktionen af aggregeringsforespørgsler i . Aggregation Editor-funktionen giver dig mulighed for at anvende pipeline-sætninger et trin ad gangen og inspicere input- og outputdata på hvert trin for lettere fejlfinding.
Brug af hurtig optagelse
Indstil aldrig MongoDB skriveindstillinger til at have høj hastighed, men lav pålidelighed. Denne tilstand "fil-og-glem" virker hurtigt, fordi kommandoen returneres før skrivningen finder sted. Hvis systemet går ned, før dataene er skrevet til disken, vil de gå tabt og ende i en inkonsistent tilstand. Heldigvis har 64-bit MongoDB logning aktiveret.
MMAPv1- og WiredTiger-lagringsmotorerne bruger logning for at forhindre dette, selvom WiredTiger kan genoprette til den sidste konsistente , hvis logning er deaktiveret.
Journalføring sikrer, at databasen er i en konsistent tilstand efter gendannelse og beholder alle data, indtil de skrives til loggen. Hyppigheden af optagelser konfigureres ved hjælp af parameteren .
For at være sikker på indtastningerne skal du sørge for, at logning er aktiveret i konfigurationsfilen ), og frekvensen af optagelser svarer til mængden af information, som du har råd til at miste.
Sortering uden indeks
Ved søgning og aggregering er der ofte behov for at sortere data. Lad os håbe, at dette sker på et af de sidste stadier efter filtrering af resultatet for at reducere mængden af data, der sorteres. Og selv i dette tilfælde skal du bruge til sortering . Du kan bruge et enkelt eller sammensat indeks.
Hvis der ikke er et passende indeks, vil MongoDB undvære det. Der er en hukommelsesgrænse på 32 MB på den samlede størrelse af alle dokumenter i , og hvis MongoDB når denne grænse, vil den enten give en fejl eller returnere .
Søg uden indeksstøtte
Søgeforespørgsler udfører en funktion, der ligner JOIN-operationen i SQL. For at fungere bedst, har de brug for indekset for værdien af nøglen, der bruges som fremmednøgle. Dette er ikke indlysende, fordi brugen ikke afspejles i explain(). Sådanne indekser er et supplement til det indskrevne indeks explain(), som igen bruges af rørledningsoperatører $match и $sort, når de mødes i begyndelsen af pipelinen. Indekser kan nu dække alle stadier .
Fravælger brug af flere opdateringer
fremgangsmåde bruges til at ændre en del af et eksisterende dokument eller hele dokumentet, op til en komplet erstatning, afhængigt af den parameter du angiver . Hvad der ikke er så indlysende er, at det ikke vil behandle alle dokumenter i samlingen, medmindre du angiver muligheden at opdatere alle dokumenter, der opfylder anmodningskriterierne.
Glem ikke vigtigheden af rækkefølgen af nøglerne i en hash-tabel
I JSON består et objekt af en uordnet samling af størrelse nul eller flere navn/værdi-par, hvor navn er en streng og værdi er en streng, tal, boolean, null, objekt eller matrix.
Desværre lægger BSON meget vægt på orden ved søgning. I MongoDB, rækkefølgen af nøgler i indbyggede objekter , dvs. { firstname: "Phil", surname: "factor" } - det er ikke det samme som { { surname: "factor", firstname: "Phil" }. Det vil sige, at du skal gemme rækkefølgen af navne/værdipar i dine dokumenter, hvis du vil være sikker på at finde dem.
Bliv ikke forvirret "Nul" и "udefineret"
Value "udefineret" var aldrig gyldig i JSON, ifølge JSON (ECMA-404 Sektion 5), selvom det bruges i JavaScript. Desuden er den for BSON forældet og konverteres til $null, hvilket ikke altid er en god løsning. .
Brug $limit() без $sort()
Ganske ofte, når du udvikler i MongoDB, er det nyttigt blot at se et eksempel på resultatet, der vil blive returneret fra en forespørgsel eller aggregering. Til denne opgave skal du bruge $limit(), men det bør aldrig være i den endelige kode, medmindre du bruger det før $sort. Denne mekaniker er nødvendig, fordi du ellers ikke kan garantere rækkefølgen af resultatet, og du vil ikke være i stand til pålideligt at se dataene. Øverst i resultatet vil du få forskellige poster afhængig af sorteringen. For at fungere pålideligt skal forespørgsler og aggregeringer være deterministiske, det vil sige producere de samme resultater, hver gang de udføres. Kode der indeholder $limit(), men nej $sort, vil ikke være deterministisk og kan efterfølgende forårsage fejl, som vil være svære at spore.
Konklusion
Den eneste måde at blive skuffet over MongoDB er at sammenligne den direkte med en anden type database, såsom en DBMS, eller at komme til at bruge den baseret på visse forventninger. Det er som at sammenligne en appelsin med en gaffel. Databasesystemer tjener specifikke formål. Det er bedst blot at forstå og værdsætte disse forskelle selv. Det ville være en skam at presse MongoDB-udviklerne over en sti, der tvang dem ned ad DBMS-stien. Jeg vil se nye og interessante måder at løse gamle problemer på, såsom at sikre dataintegritet og skabe datasystemer, der er modstandsdygtige over for fejl og ondsindede angreb.
MongoDBs introduktion af ACID-transaktionalitet i version 4.0 er et godt eksempel på at indføre vigtige forbedringer på en innovativ måde. Transaktioner med flere dokumenter og flere erklæringer er nu atomare. Det er også muligt at justere den tid, det tager at erhverve låse og afslutte fastlåste transaktioner, samt ændre isolationsniveauet.
Læs mere:
Kilde: www.habr.com