Как да решите дали MongoDB е подходящ за вас

През последните няколко години изградих уеб приложения около MongoDB. В тази кратка статия бих искал да отговоря на някои от повтарящите се въпроси или недоразумения, които повечето разработчици имат, когато го оценяват:

  • Какво е лицензирането?
  • Какво означава MongoDB е NoSQL база данни?
  • Ами изпълненията на MongoDB?

Лицензиране

Да, MongoDB е лицензиран под GNU AGPL v3.0 на Фондация за свободен софтуер . На практика това означава, че подобренията, които правите в MongoDB, трябва да бъдат предоставени на общността. Изходният код на всяко производно произведение също трябва да бъде разпространен.

Може да се чудите дали вашето приложение е производна работа. Трябва да призная, че никога не съм намерил просто определение на такъв термин. В конкретния случай на MongoDB обаче те просто осъзнават, че приложенията, използващи тяхната база данни, са отделна работа. Нещо повече, поддържаните от тях драйвери се издават под Apache License v2.0. Това е разрешителен лиценз. Не изисква да публикувате изходния си код и приложението ви обикновено говори само с MongoDB с помощта на драйвер.

В резултат на това не е нужно да се занимавате с лицензирането на MongoDB, за да изградите приложението си около него. Те дори изпращат подписани писма с утвърждаване на обещанието до юридически отдели, ако има въпроси. Те също така предоставят търговски лицензи, ако подписаното писмо не е достатъчно.

Забележка: въпреки че богат опит ме кара да се доверя на този анализ, аз не съм юрист. Представеният тук възглед е мое лично разбиране и не е официален.

NoSQL

Да, MongoDB е база данни NoSQL. Тази дума може да бъде доста объркваща. Ще се опитам да анализирам най-често срещаните идеи с фокус върху това как това се отнася за MongoDB.

Ориентиран към документ

В традиционните бази данни на SQL данните са подредени под формата на таблици и редове. Всеки ред има фиксиран брой колони, които могат да съхраняват само данни от определен тип (напр. Integer, Text, Datetime). Това определя схемата на вашите данни.

В MongoDB данните се съхраняват под формата на BSON обекти, организирани в колекции. Данните саобикновено се обработва под формата на JSON обекти. Това прави картографирането на обекти в базата данни проста задача, обикновено елиминираща всичко подобно на обектно-релационно картографиране .

Транзакционна

Преди v4, MongoDB предоставяше само транзакции в целия документ. Писанията никога не са били приложени частично към вмъкнат или актуализиран документ. Операцията беше атомна в смисъл, че или се проваля, или успява. За документа в неговата цялост се казва, че е ACID на ниво документ. В резултат на това нямаше възможност за атомни промени, обхващащи множество документи. Трябваше да емулирате необходимите транзакции в базата данни (напр. Като използвате двуфазен ангажимент).

От v4, MongoDB поддържа транзакции с много документи на ACID, което го прави единствената база данни с отворен код, която комбинира модела на документ с ACID гаранции.

Без схеми (наистина?)

Това означава, че не е нужно да казвате на базата данни структурата на вашите данни и примитивните типове, които да се използват, преди да можете да ги управлявате. Това също означава, че можете да смесвате документи, които имат различни структури в една и съща колекция от данни.

Едно от големите предимства е, че миграциите на схеми стават по - лесни (повечето корекции в базата данни са прозрачни и автоматични). Малко вероятно е връщането да създаде проблеми. Друго предимство е, че динамичното разширяване на съществуващите модели данни с персонализирани атрибути по време на изпълнение е лесно .

Новсичко това не означава, че изобщо нямате никаква схема. Ако не е изрично деклариран, той свети неявно от логиката на вашето приложение. Може да бъде деклариран по други начини за обработка на проверка на формуляр / данни. Както и да е, все още трябва изрично да кажете на базата данни как да създавате индекси, за да осигурите добра производителност.

Всъщност дизайнът на схемата е крайъгълният камък за създаването на страхотни бази данни, независимо дали SQL или не. Ако не разбирате данните си и ограниченията на хардуера и софтуера, не можете ефективно да проектирате схема.

Нерелационни (наистина?)

Това означава, че не е необходимо винаги да създавате връзка между два документа, за да обработвате агрегирани структури от данни.

Всъщност в релационните бази данни клаузата SQL JOIN ви позволява да комбинирате редове от две или повече таблици, използвайки общо поле между тях. Ориентираните към документи бази данни като MongoDB са предназначени да съхраняват денормализирани данни. В идеалния случай не трябва да има връзка между колекциите: ако се изискват едни и същи данни в два или повече документа, те трябва да се повторят. Едно от големите предимства е, че за получаване на всички данни е необходима една операция за четене .

Но все пак можете да създавате отношения и да се позовавате на друг документ, ако искате или имате нужда:

  • по ID, тогава можете да го „попълните“ ръчно с втора заявка или с помощта на DBRefs
  • от всяко друго поле, тогава можете да използвате $lookupоператора

Това прави MongoDB наистина гъвкав и ви позволява да избирате как да обработвате връзките между вашите обекти за всеки отделен случай .

производителност

Чети пиши

Да, MongoDB като всяка друга „истинска“ база данни е създадена да обработва огромен обем данни. Накратко, стотици или хиляди обекти не са нищо за база данни, така че не е нужно да се притеснявате, ако имате такива числа. Можете да намерите много критерии наоколо. Ето един прост, за да ви даде груб порядък. Съхраняваните документи са наистина прости и обикновено представляват измерване с отметка във времето:

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

Поради начина, по който MongoDB делегира управлението на паметта на операционната система, наличието на по-сложни документи (обикновено съдържащи десетки атрибути) не влияе значително на резултатите

Both attributes have been indexed. MongoDB automatically adds and indexes the document unique ID. I tested three requests:

  • find the maximum value of the collection using the aggregation framework
  • find the 100 greatest values greater than 99.9
  • get a single document by ID

The “maximum request” is not benefitting from indexes because of the aggregation, while the “greater than” and “by ID” requests can use it. You will see how this is important for performance.

The test configuration was MongoDB 3.4.1 64 bits — OS Windows 7 Pro SP1 — CPU Core i7–4712HQ 2.3GHz — 16Go RAM—SSD HD, and the test results were the following:

So if you build the correct indices querying a billion documents, it is still performant enough for most applications on a single server. If needed, you can increase performance using 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.

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 !