Коли ми повинні використовувати MongoDB?

MongoDB - це база даних NoSQL, яку я вважаю досить простою у використанні. Нещодавно мені довелося розробити простий додаток, який потребував збору деяких даних за допомогою HTTP-запитів та зберігання деяких результатів після обробки даних, і я спробував використовувати MongoDB.

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

Тим не менш, іноді я не знаю, коли я повинен використовувати MongoDB замість традиційної реляційної бази даних, як-от SQL Server або MySQL.

У такому випадку, коли ми можемо використовувати MongoDB замість реляційних баз даних? Чи є по-справжньому великий застереження щодо MongoDB, яке робить його неналежним для деяких ситуацій?

В основному:

• Якщо ви можете представити свої дані у вигляді купки документів, MongoDB може стати хорошим вибором.

• Якщо ви хочете уявити свої дані як купу взаємопов'язаних таблиць, MongoDB може виявитися не найкращим вибором.

Ось два приклади, які я вважаю наочними:

• Кілька років тому я створив двигун блогу. Її мета - розміщення статей у блогах, а для кожної статті зберігати різні версії, деякі метадані, статистику відвідувань тощо.

  Це може зберігатися як купа таблиць, але, намагаючись побудувати модель, вона дуже швидко зростає до десятка таблиць, якщо не більше. Деякі запити SQL можуть стати некрасивими з великою кількістю joins, і ... ну, ви отримаєте зображення.

  Проблема тут полягає в тому, що є основна річ - стаття в блозі - і все це є навколо статті, що робить її добре підходящою для бази даних на документах. За допомогою MongoDB моделювати базу даних було надзвичайно просто: одна колекція містить статті в блозі, а друга крихітна колекція містить список користувачів, яким дозволено писати статті. Кожен документ у першій колекції містив би всю інформацію, яка мені потрібна під час показу статті, чи буде це ім'я автора чи теги.

• Тепер уявіть зовсім інший проект. Є деякі користувачі, які можуть писати речі та ділитися ними, написаними іншими користувачами. На сторінці користувача ви можете розраховувати як речі, написані цим користувачем, так і ті, якими вона поділилася. Є одне обмеження: коли хтось редагує те, що писав раніше, зміна з’являється скрізь, де ділився оригінальним текстом.

  При підході на основі документа важко знайти, яким був би документ. Користувач може? Ну, це вдалий початок. Документ користувача містив би все, що написав цей користувач. Але що з речами, якими вона поділилася?

  Можливий спосіб - помістити ці речі в один і той же документ. Проблема такого підходу полягає в тому, що якщо хтось редагує запис, додаток повинен пройти кожен документ користувача в базі даних, щоб відредагувати кожне виникнення старого запису. Не рахуючи дублювання даних.

  Альтернативою було б зберігати в документі користувача лише список записів, якими цей користувач надав спільний доступ (з ідентифікатором згаданого користувача та записом). Але зараз виникла б інша проблема: якщо користувач поділився тисячами записів від тисяч користувачів, для отримання цих запитів потрібно було б відкрити тисячі документів.

  Або ми можемо моделювати нашу колекцію навколо самих записів, кожен запис із зазначенням свого автора та зі списком користувачів, які ними поділилися. Знову ж таки, проблеми з ефективністю можуть стати помітними, коли вам потрібно буде ознайомитися з усіма документами, щоб показати ті, які опублікував даний користувач.

  Тепер, скільки таблиць вам знадобиться, якби ви використовували реляційну базу даних? Правильно, три. Зробити це було б просто, а також просто.

Кожна технологія має свої переваги.

Переваги реляційних баз даних полягають у тому, що RDBMS робить для вас щось, наприклад:

• Підтримка референтної цілісності (не дозволяє вставляти детальну інформацію про рахунок-фактуру, якщо рахунок-фактура, до якої вона належить, не існує)
• Уникайте надмірності: речі зберігаються лише один раз.
• Складні запити можна виконувати за допомогою декларативної мови (SQL), яка є зрілою, перевіреною часом та широко розповсюдженою.

Все це зводиться до того, що вам потрібно писати менше коду, оскільки RDBMS виконує завдання для вас.

Крім того, незалежність даних: часто, якщо ви використовуєте стандартні структури SQL, а не конкретні для постачальника, ви можете переміщувати свої дані з однієї RDBMS в іншу з мінімальними клопотами, тоді як бази даних NOSQL взагалі не стандартизовані.

З іншого боку, однією з переваг баз даних NOSQL є те, що вони масштабують кращу підтримку продуктивності на мільйони рядків. Вони краще підходять для зберігання на основі документів, тобто неструктурованих даних. Але більшості додатків ці функції не потрібні.

Для вашого конкретного випадку MongoDB здається хорошим вибором, але існує маса сценаріїв (можливо, більшість із них), де це було б не найкращим вибором.

MongoDB більше підходить для сценаріїв, які вимагають зчитувати / записувати багато даних, без особливого акценту на безпеці транзакцій (якщо деякі дані час від часу втрачаються при збої на сервері, це не є великою справою), очікуйте, що масштаб буде масштабним і не ставте ' t дійсно має стабільну схему.

MongoDB не підходить для сценаріїв, які вимагають:

1. Сильні гарантії кислотної кислоти: MongoDB дозволяє зберігати дублікати даних, непослідовні зчитування та навіть втрату даних. У деяких програмах такі речі добре, але в більшості.
2. Багатооб'єктні транзакції: MongoDB підтримує транзакції ACID, але лише для одного об'єкта / документа. Це просто не скоротить це для складніших операцій, таких як банківські перекази, бронювання тощо.
3. Традиційний BI: є багато інструментів BI, які добре грають лише з традиційними SQL.
4. SQL: MongoDB має дуже специфічну мову запитів, тоді як SQL дуже добре відомий багатьма людьми (це може бути важливим аспектом для розгляду), може робити багато складних речей (тоді як з MongoDB у вас виникнуть проблеми із виконанням простого приєднатись) і може бути передано у багатьох реалізаціях.

MongoDB швидше і дозволить вам досягти більшої продуктивності в системі, усуваючи багато матеріалів, які RDBMS застосовують за замовчуванням, як-от перевірки цілісності (зауважте, що ви також можете налаштувати RDBMS для таких цілей), але правда, у більшості сценаріїв це просто не потрібно. Крім того, компроміс - це надійність та гнучкість (у вас виникнуть проблеми, якщо згодом ви вирішите, що вам потрібно зробити більш складні операції з наявними даними).

Все залежить від потреб програми, яку ви будуєте. Це швидкість та доступність чи безпека, надійність та гнучкість. Ви повинні знати, де у ваших даних (і в з'єднаннях ваших даних) лежить більше значення. Якщо ви ще не знаєте, це, мабуть, найкраще, якщо ви виберете щось, що не забарвить вас у кут у майбутньому, і дозволить вам додати функції та виконати операції, необхідні вашій програмі.

MongoDB - це чудово, коли ви можете представляти свої дані як незалежні "пакети" інформації. У вас є поштові індекси google maps, вбудовані в поштовий індекс - це компанії, а всередині компаній - співробітники. Всі поштові індекси не залежать один від одного, і ви можете отримати всю інформацію просто, красиво і швидко. Це хороший сценарій для не-SQL-рішення.

Колись це сказав, я повністю не погоджуюся з поточною тенденцією, яку я шукаю, що означає, що MongoDB - це своєрідний пост та найкраще рішення для RDBMS, і noSQL має бути вашим рішенням за замовчуванням. Все це абсурдно. MongoDB є нішевою базою даних, і 90% проектів є реляційними та потребують опції RDBMS, оскільки ви хочете, щоб потужне рішення запитів, як SQL, генерувало ваші звіти та шукало дисперсні дані: "приєднується" - це професіонал, а не шахрай. Крім того, сучасні RDBMS підтримують колекції BSON та геопросторову інтеграцію, тому, можливо, ніша для noSQL ще вужча.

MongoDB корисний для зберігання цілих структурованих даних, необхідних для створення певного примірника веб-сторінки. Ви можете отримати дані для певної сторінки, передати їх у свою клієнтську програму, яка потім може надати їх.

У такому контексті MongoDB дуже швидкий та надійний. Але ніколи не забувайте, що у вашій базі даних немає реляційних даних. Що означає, що якщо ви щось зміните в структурі своєї веб-сторінки, ви не зможете заповнити отвори у своїх уже збережених сторінках, оскільки у вас немає даних, необхідних для цього. Більше про це тут: http://www.sarahmei.com/blog/2013/11/11/why-you-should-never-use-mongodb/