Kako odlučiti je li MongoDB pravi za vas

Posljednjih nekoliko godina gradio sam web aplikacije oko MongoDB-a. U ovom kratkom članku želio bih odgovoriti na neka ponavljajuća pitanja ili nesporazume koje većina programera ima pri procjeni:

  • Što je licenciranje?
  • Što znači MongoDB je NoSQL baza podataka?
  • Što je s izvedbama MongoDB-a?

Licenciranje

Da, MongoDB je licenciran pod GNU AGPL v3.0 zaklade Free Software Foundation . Praktično, to znači da poboljšanja koja napravite na MongoDB-u moraju biti objavljena u zajednici. Izvorni kod bilo kojeg izvedenog djela također se mora distribuirati.

Možda se pitate je li vaša aplikacija izvedeno djelo. Moram priznati da nikada nisam pronašao jednostavnu definiciju takvog pojma. Međutim, u konkretnom slučaju MongoDB-a oni jednostavno prepoznaju da su aplikacije koje koriste njihovu bazu podataka zasebno djelo. Štoviše, podržani upravljački programi izdaju se pod Apache licencom v2.0. Ovo je dozvola. Ne zahtijeva objavljivanje izvornog koda, a aplikacija obično razgovara s MongoDB-om samo pomoću upravljačkog programa.

Kao posljedicu, ne trebate se baviti licenciranjem MongoDB-a da biste oko njega izgradili svoju aplikaciju. Oni čak šalju potpisana pisma u kojima potvrđuju obećanje pravnim odjelima ako postoje pitanja. Oni također pružaju komercijalne licence ako potpisano pismo nije dovoljno.

Napomena: iako me veliko iskustvo natjeralo da vjerujem ovoj analizi, ja nisam pravnik. Ovdje predstavljeno stajalište moje je osobno razumijevanje i nije službeno.

NoSQL

Da, MongoDB je NoSQL baza podataka. Ova riječ može biti prilično zbunjujuća. Pokušat ću analizirati najčešće ideje s naglaskom na to kako se to odnosi na MongoDB.

Orijentiran na dokument

U tradicionalnim SQL bazama podataka podaci su raspoređeni u obliku tablica i redaka. Svaki redak ima fiksni broj stupaca koji mogu pohraniti samo podatke određene vrste (npr. Integer, Text, Datetime). Ovo definira shemu vaših podataka.

U MongoDB-u podaci se pohranjuju u obliku BSON objekata organiziranih u zbirke. Podaci suobično se obrađuje u obliku JSON objekata. To čini mapiranje objekata u bazu podataka jednostavnim zadatkom, koji obično eliminira bilo što slično objektno-relacijskom mapiranju .

Transakcijski

Prije v4, MongoDB je pružao samo transakcije širom dokumenta. Zapisi nikada nisu djelomično primijenjeni na umetnuti ili ažurirani dokument. Operacija je bila atomska u smislu da ili ne uspije ili uspije. Za dokument u cijelosti rečeno je da je KISELINA na razini dokumenta. Kao posljedica toga, nije postojala mogućnost atomskih promjena koje obuhvaćaju više dokumenata. Morali ste oponašati potrebne transakcije baze podataka (npr. Pomoću dvofaznog predavanja).

Od v4, MongoDB podržava ACID transakcije s više dokumenata, što ga čini jedinom bazom podataka otvorenog koda koji kombinira model dokumenta s ACID jamstvima.

Bez sheme (stvarno?)

To znači da ne morate bazi podataka reći strukturu podataka i primitivne tipove koji će se koristiti prije nego što možete njima upravljati. To također znači da u istoj zbirci podataka možete miješati dokumente koji imaju različite strukture.

Jedna od velikih prednosti je što migracije shema postaju lakše (većina prilagodbi baze podataka su transparentne i automatske). Malo je vjerojatno da će vraćanje uzrokovati probleme. Sljedeća je prednost što je dinamičko proširivanje postojećih modela podataka s prilagođenim atributima tijekom izvođenja jednostavno .

Alisve to ne znači da uopće nemate nikakvu shemu. Ako nije izričito deklarirano, implicitno svijetli iz logike vaše aplikacije. Može se deklarirati na druge načine za obradu provjere oblika / podataka. Svejedno, još uvijek morate izričito reći bazi podataka kako stvoriti indekse kako bi se osigurala dobra izvedba.

Zapravo, dizajn sheme temelj je izrade sjajnih baza podataka, bez obzira jesu li SQL ili ne. Ako ne razumijete svoje podatke i ograničenja hardvera i softvera, ne možete učinkovito dizajnirati shemu.

Nerelacijski (stvarno?)

To znači da za obradu agregiranih struktura podataka ne morate uvijek stvarati vezu između dva dokumenta.

Zapravo, u relacijskim bazama podataka, klauzula SQL JOIN omogućuje vam kombiniranje redaka iz dvije ili više tablica koristeći zajedničko polje između njih. Baze podataka orijentirane na dokumente poput MongoDB dizajnirane su za pohranu denormaliziranih podataka. Idealno bi bilo da ne postoji veza između zbirki: ako su isti podaci potrebni u dva ili više dokumenata, mora se ponoviti. Jedna od velikih prednosti je što je za dobivanje svih podataka potrebna jedna operacija čitanja .

Ali i dalje možete stvoriti relacije i uputiti se na drugi dokument ako želite ili imate potrebu:

  • pomoću ID-a, možete ga ručno "popuniti" drugim upitom ili pomoću DBRef-a
  • bilo kojim drugim poljem, tada možete koristiti $lookupoperator

To MongoDB čini stvarno fleksibilnim i omogućuje vam odabir načina upravljanja odnosima između vaših objekata od slučaja do slučaja .

Izvođenje

Čitaj / piši

Da, MongoDB je poput bilo koje druge "istinske" baze podataka stvorena za rukovanje ogromnom količinom podataka. Ukratko, stotine ili tisuće objekata nisu ništa za bazu podataka, tako da ne morate brinuti ako imate takve brojeve. Naokolo možete pronaći puno mjerila. Evo jednostavnog da vam dam grubi poredak veličine. Pohranjeni dokumenti stvarno su jednostavni i obično predstavljaju vremenski označeno mjerenje:

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

Zbog načina na koji MongoDB delegira upravljanje memorijom na operativni sustav, posjedovanje složenijih dokumenata (koji obično sadrže desetke atributa) ne utječe značajno na rezultate

Oba su atributa indeksirana. MongoDB automatski dodaje i indeksira jedinstveni ID dokumenta. Testirao sam tri zahtjeva:

  • pronađite maksimalnu vrijednost zbirke pomoću okvira za agregiranje
  • naći 100 najvećih vrijednosti većih od 99,9
  • dobiti jedan dokument putem osobne iskaznice

"Maksimalni zahtjev" ne koristi indekse zbog agregacije, dok ga mogu koristiti "veći od" i "prema ID-u". Vidjet ćete kako je to važno za izvedbu.

Konfiguracija testa bila je MongoDB 3.4.1 64 bita - OS Windows 7 Pro SP1 - CPU Core i7–4712HQ 2,3 GHz - 16Go RAM - SSD HD, a rezultati testa bili su sljedeći:

Dakle, ako izradite ispravne indekse s upitom za milijardu dokumenata, to je i dalje dovoljno učinkovito za većinu aplikacija na jednom poslužitelju. Ako je potrebno, možete povećati performanse oštrenjem.

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.

As a consequence, the single parameter you can tune to optimize memory usage is the engine cache size. For example, by default, the WiredTiger engine uses 50% of RAM minus 1 GB, which can be pretty large on servers with a lot of memory. This can even cause some trouble if you use containers with limited memory, so simply find out the right balance for your use case.

Conclusion

I hope you know have a more precise idea of the benefits provided by MongoDB if it suits your needs. Recently, MongoDB has started a Database as a Service offer called MongoDB Atlas that might be useful for you to test out.

If you liked this article feel free to have a look at our Open Source solutions, the Kalisio team !