5 причин використовувати Монго (MongoDB)


Дізнайтесь більше про нові кар'єрні можливості в EchoUA. Цікаві проекти, ринкова оплата, гарний колектив. Надсилайте резюме та приєднуйтеся до нас.

Отже, давайте розберемо більш детально, чому Вам варто розглянути використання Монго (MongoDB) на вашому проекті.

1. Відсутність схеми

Це найочевидніша перевага. Якщо ви працюєте над новими стартапами, в яких бізнес-модель ще не до кінця зрозуміла і з великою ймовірністю проект до виходу на ринок зазнає безліч змін, в тому числі на рівні організації даних – подивіться в сторону NoSQL рішень, зокрема на Монгу. Вся справа в тому, що на відміну від мого улюбленого PostgreSQL в Монго просто немає необхідності створювати таблиці, змінювати їх схеми, створювати міграції, думати про типах даних. Однак тут будьте обережні. Очевидний плюс цього пункту, що вам набагато простіше створювати нові таблиці, додавати і прибирати поля. Настільки просто, що в Mongoid (ORM для MongoDB) ви просто додаєте в свою модель рядок а-ля field: text, type: String і все, при наступному записі в БД у нового елемента буде це поле. Якщо ж ви вставляєте дані без ORM – то вам і ніякі “рядки” не потрібні – просто пхайте, що душі завгодно. Але тут же і темна сторона цієї сили. Ви не можете бути цілком впевнені, що в конкретному документі у вас є конкретне поле. (Примітка: документами в MongoDB називаються записи в колекції). Тобто якщо раніше у вас не було поля text і ви додали кілька записів, а потім додали це поле і додали ще записи – в старих записах у вас цього поля, звичайно ж, не з’явиться. Спасибі Mongoid, він зробить вигляд, що таке поле є і у них і просто поверне значення null.

2. Легкість горизонтального масштабування

Горизонтальне масштабування потрібно коли вам необхідно запхати в базу даних інформації більше, ніж диск на вашому сервері. Все, що пов’язано з горизонтальним масштабуванням є візитною карткою будь-якої NoSQL бази даних. Далі вони вже змагаються в тому, у кого вище надійність, у кого швидше запис, у кого швидше читання і т.д. На момент написання цієї статті в PostgreSQL немає вбудованого механізму горизонтального масштабування. Є сторонні пропрієтарні рішення (не можу не згадати компанію Citus, вони роблять прекрасну роботу). У MongoDB ж це робиться дуже просто, а статей про це написано багато, і механізми реплікації вупі з шардінгом на ній працюють прекрасно. Крім того можна дозволити балансувальнику автоматично вибирати, в якій шард складати конкретні документи, так і задати правила щодо якогось поля або набору полів.

3. Багатий функціонал агрегації

Мова SQL дуже багата і всім звична, каменів кидати я в неї не стану. Однак те, як дозволяє отримувати дані Монга однозначно заслуговує на похвалу. Тут вам і map-reduce, і груповання по складних умов, і переформатування документів на льоту, і отримання випадкових документів, і сортування. Загалом все те, що ви можете витиснути з SQL БД, плюс можливість записувати все це в форматі pipeline-ів і з більш читабельним синтаксисом.Мова SQL дуже багата і всім звична, каменів кидати я в неї не стану. Однак те, як дозволяє отримувати дані Монга однозначно заслуговує на похвалу. Тут вам і map-reduce, і груповання по складних умов, і переформатування документів на льоту, і отримання випадкових документів, і сортування. Загалом все те, що ви можете витиснути з SQL БД, плюс можливість записувати все це в форматі pipeline-ів і з більш читабельним синтаксисом.

Ось один з багатьох прикладів з документації:

SQL

SELECT cust_id,
SUM (price) as total
FROM orders
WHERE status = 'A'
GROUP BY cust_id
HAVING total> 250

Mongo

db.orders.aggregate( [
{ $match: { status: 'A' } },
{
$group: {
_id: "$cust_id",
total: { $sum: "$price" }
}
},
{ $match: { total: { $gt: 250 } } }
] )

Приклад з монго хоч і трохи більше багатослівний, але набагато більш адекватно структурований. Якщо ви тільки прийшли з SQL бази даних, буде потрібно якийсь час на звикання, але потім звикаєш і повертатися не хочеться.

4. Створена для денормалізації

У MongoDB прийнято зберігати дані так, як вам це зручно. У SQL базах даних завжди (примітка: насправді немає, варто завжди думати головою і не сприймати слово “завжди” як закон) варто піклуватися про організацію даних, щоб таблиці були нормалізовані, а запити будувати так, щоб вони могли лівою п’ятою вухо почухати, але потрібні дані дістати. У Монго якщо вам незручно, в якому форматі або в якому місці лежать дані – ви з чистою совістю можете їх або перемістити, тому що відсутність схеми це і має на увазі, або просто продублювати дані в потрібне місце. Тобто фактично у вас може бути одне і те ж поле з одними і тими ж даними, але в різних колекціях. Або два поля в одній колекції, а плюс до них ще одне поле, яке є композицією перших двох. Але це знову таки сила, яку слід застосовувати з розумом. Якщо ви будете неконтрольовано плодити поля в документах, підтримка на рівні розуміння розробником буде ставати все важче і важче.

5. Простий формат індексів

Індекси в Монго називаються гранично зрозуміло і їх використання практично позбавлене підводних каменів. Наприклад в Постгресі якщо у вас є b-tree індекс на одне поле і gist індекс на інше – при запиті, який використовує обидва цих індексу, використовуватися буде тільки один з них. У Монзі таких сюрпризів менше.

Висновки

Безсумнівно MongoDB – це не срібна куля. У ній є свої несподівані підводні камені. Наприклад, вона автоматично не відрубує повільні запити і вони продовжують висіти, поки ви їх не закриєте самостійно. Ще ви можете відчути низьку продуктивність при count запиті на великих колекціях. Але це все речі, які одного разу дізнаєшся і потім просто пам’ятаєш про них, тому що жити вони не сильно заважають. Я не агітую всіх йти з SQL БД і переводити продакшн проекти на Монгу, але якщо ви стоїте перед вибором, яку базу даних взяти для нового проекту – подумайте про неї. Якщо все-таки не зважитеся експериментувати з NoSQL рішенням – тоді беріть PostgreSQL. Вона дуже динамічно розвиваються, у них є частково-nosql рішення у вигляді json полів в таблиці, величезна кількість документації і прекрасна продуктивність.

Джерело: mkdev.me

Київ, Харків, Одеса, Дніпро, Запоріжжя, Кривий Ріг, Вінниця, Херсон, Черкаси, Житомир, Хмельницький, Чернівці, Рівне, Івано-Франківськ, Кременчук, Тернопіль, Луцьк, Ужгород, Кам'янець-Подільський, Стрий - за статистикою саме з цих міст програмісти найбільше переїжджають працювати до Львова. А Ви розглядаєте relocate?


Trends: distinct mongodb, mongo equal, монго

Коментарі 1

  • Ну на моєму досвіді скажу так – не можна порівнювати MongoDB і MySQL, це і не зовсім правильно, тому що для різних завдань води підходять по-різному, але для нашого проекту мені більше підходить саме MongoDB. І саме багатий функціонал агрегації і відсутність схеми – це саме те, що нам потрібно для різних типових завдань. Так, правильно написано, це не срібна куля, але варто один раз розібратися, щоб оцінити всі можливості Mongo.

Залишити відповідь

Ваша e-mail адреса не оприлюднюватиметься. Обов’язкові поля позначені *