Sådan beslutter du, om MongoDB passer til dig

I de sidste par år har jeg bygget webapplikationer omkring MongoDB. I denne korte artikel vil jeg gerne besvare nogle af de tilbagevendende spørgsmål eller misforståelse, som de fleste udviklere har, når de vurderer det:

  • Hvad er licensen?
  • Hvad betyder det MongoDB er en NoSQL-database?
  • Hvad med MongoDB forestillinger?

Licensering

Ja, MongoDB er licenseret under Free Software Foundation's GNU AGPL v3.0 . Praktisk set betyder det, at forbedringer, du foretager i MongoDB, skal frigives til samfundet. Kildekoden for ethvert afledt arbejde skal også distribueres.

Du spekulerer måske på, om din ansøgning er et afledt værk. Jeg må indrømme, at jeg aldrig har fundet en simpel definition af et sådant udtryk. Men i det specifikke tilfælde af MongoDB anerkender de simpelthen, at applikationer, der bruger deres database, er et separat arbejde. Derudover frigives deres understøttede drivere under Apache License v2.0. Dette er en tilladelig licens. Det kræver ikke, at du offentliggør din kildekode, og din applikation taler normalt kun med MongoDB ved hjælp af en driver.

Som en konsekvens behøver du ikke være bekymret for licensering af MongoDB til at opbygge din app omkring den. De sender endda underskrevne breve om løftet til juridiske afdelinger, hvis der er spørgsmål. De leverer også kommercielle licenser, hvis det underskrevne brev ikke er nok.

Bemærk: Selvom en stor erfaring får mig til at stole på denne analyse, er jeg ikke advokat. Det synspunkt, der præsenteres her, er min personlige forståelse og er ikke en officiel.

NoSQL

Ja, MongoDB er en NoSQL-database. Dette ord kan være ret forvirrende. Jeg vil forsøge at analysere de mest almindelige ideer med fokus på, hvordan dette gælder for MongoDB.

Dokumentorienteret

I traditionelle SQL-databaser arrangeres data i form af tabeller og rækker. Hver række har et fast antal kolonner, der kun kan gemme data af en bestemt type (f.eks. Heltal, tekst, datatid). Dette definerer skemaet for dine data.

I MongoDB lagres data i form af BSON-objekter organiseret i samlinger. Data ernormalt håndteres i form af JSON-objekter. Dette gør kortlægning af objekter i databasen til en simpel opgave, hvilket normalt fjerner noget, der ligner en objektrelationskortlægning .

Transaktionel

Forud for v4 leverede MongoDB kun transaktioner, der dækker hele dokumentet. Skrift blev aldrig delvist anvendt på et indsat eller opdateret dokument. Operationen var atomisk i den forstand, at den enten mislykkes eller lykkes. For dokumentet i sin helhed blev det sagt, at det var syre på dokumentniveau. Som en konsekvens var der ingen mulighed for atomændringer, der spænder over flere dokumenter. Du var nødt til at efterligne de påkrævede databasetransaktioner (f.eks. Ved hjælp af 2-fasetag).

Siden v4 understøtter MongoDB ACID-transaktioner med flere dokumenter, hvilket gør det til den eneste open source-database, der kombinerer dokumentmodellen med ACID-garantier.

Skemafri (virkelig?)

Dette betyder, at du ikke behøver at fortælle databasen strukturen på dine data og de primitive typer, der skal bruges, før du kan administrere den. Dette betyder også, at du kan blande dokumenter, der har forskellige strukturer i den samme dataindsamling.

En af de store fordele er, at skemamigreringer bliver lettere (de fleste justeringer i databasen er gennemsigtige og automatiske). Tilbagevenden vil sandsynligvis ikke forårsage problemer. En anden fordel er, at dynamisk udvidelse af eksisterende datamodeller med brugerdefinerede attributter ved kørsel er ligetil .

Menalt dette betyder ikke, at du slet ikke har noget skema. Hvis det ikke eksplicit erklæres, skinner det implicit fra din applikationslogik. Det kan blive erklæret på andre måder til at håndtere form / datavalidering. Under alle omstændigheder skal du stadig eksplicit fortælle databasen, hvordan du opretter indekser for at sikre god ydeevne.

Faktisk er skema design hjørnestenen i at skabe fantastiske databaser, hvad enten SQL eller ej. Hvis du ikke forstår dine data og begrænsningerne ved hardware og software, kan du ikke effektivt designe et skema.

Ikke-relationel (virkelig?)

Det betyder, at du ikke altid behøver at oprette en relation mellem to dokumenter for at håndtere aggregerede datastrukturer.

I relationelle databaser giver SQL JOIN-klausulen dig faktisk mulighed for at kombinere rækker fra to eller flere tabeller ved hjælp af et fælles felt mellem dem. Dokumentorienterede databaser som MongoDB er designet til at gemme denormaliserede data. Ideelt set bør der ikke være nogen sammenhæng mellem samlinger: hvis de samme data kræves i to eller flere dokumenter, skal de gentages. En af de store fordele er, at der kræves en enkelt læsning for at få alle data.

Men du kan stadig oprette relationer og henvise til et andet dokument, hvis du vil eller har behov for det:

  • efter ID, så kan du "udfylde" det manuelt med en anden forespørgsel eller ved hjælp af DBRefs
  • i ethvert andet felt, så kan du bruge $lookupoperatøren

Dette gør MongoDB virkelig fleksibel og giver dig mulighed for at vælge, hvordan du skal håndtere forholdet mellem dine objekter fra sag til sag .

Ydeevne

Læse skrive

Ja, MongoDB er som enhver anden "ægte" database lavet til at håndtere en enorm mængde data. I en nøddeskal er hundreder eller tusinder af objekter ikke noget for en database, så du behøver ikke bekymre dig, hvis du har sådanne tal. Du kan finde mange benchmarks rundt. Her er en enkel, der giver dig en grov størrelsesorden. De gemte dokumenter er virkelig enkle og repræsenterer typisk en tidsstemplet måling:

{ value: random(0,100), timestamp: date}

På grund af den måde, MongoDB uddelegerer hukommelsesadministration til operativsystemet, påvirker resultaterne ikke at have mere komplekse dokumenter (typisk indeholdende snesevis af attributter)

Begge attributter er indekseret. MongoDB tilføjer og indekserer automatisk dokumentets unikke id. Jeg testede tre anmodninger:

  • find samlingens maksimale værdi ved hjælp af aggregeringsrammen
  • find de 100 største værdier større end 99,9
  • få et enkelt dokument efter ID

Den "maksimale anmodning" drager ikke fordel af indekser på grund af sammenlægningen, mens anmodningerne "større end" og "efter ID" kan bruge den. Du vil se, hvordan dette er vigtigt for ydeevnen.

Testkonfigurationen var MongoDB 3.4.1 64 bit - OS Windows 7 Pro SP1 - CPU Core i7–4712HQ 2.3GHz - 16Go RAM — SSD HD, og ​​testresultaterne var følgende:

Så hvis du bygger de korrekte indekser, der forespørger en milliard dokumenter, er den stadig effektiv nok til de fleste applikationer på en enkelt server. Hvis det er nødvendigt, kan du øge ydeevnen ved hjælp af sharding.

Here are the scripts used to create/query the database for this test:

And the run commands:

// Launch server./mongod --dbpath "C:\Program Files\MongoDB\Server\3.4\data" --port 27018// Insertion exemple for 10e7./mongo --port 27018 --eval "var arg1=10000000" create_collection.js// Requests./mongo --port 27018 --eval "" query_collection.js

Memory

Yes, MongoDB often looks like it uses all available RAM. It actually relies on different storage engines. WiredTiger is the default starting in MongoDB 3.2, and MMAPv1 is the default for MongoDB versions before 3.2. However, they work pretty similarly. Via the file system cache, they automatically use all free memory that is not used by the engine cache or by other processes. And this is coherent if you’d like to have maximum performances.

So system resource monitors often show that MongoDB uses a lot of memory, but its usage is dynamic. If another process suddenly needs half the server’s RAM, MongoDB will yield cached memory to the other process.

Som en konsekvens er motorens cache størrelse den enkelte parameter, du kan indstille for at optimere hukommelsesforbruget. For eksempel bruger WiredTiger-motoren som standard 50% af RAM minus 1 GB, hvilket kan være ret stort på servere med meget hukommelse. Dette kan endda skabe nogle problemer, hvis du bruger containere med begrænset hukommelse, så find ud af den rette balance til din brugssag.

Konklusion

Jeg håber, du ved, har en mere præcis idé om fordelene ved MongoDB, hvis det passer til dine behov. For nylig har MongoDB startet en database som et servicetilbud kaldet MongoDB Atlas, der kan være nyttigt for dig at teste.

Hvis du kunne lide denne artikel, er du velkommen til at se på vores Open Source-løsninger, Kalisio-teamet!