Нещодавно я дізнався, що (Кажуть, через зміни ліцензії). Це змусило мене замислитись, що в останні кілька років я бачив купу статей, як жахлива MongoDB і що ніхто ніколи не повинен її використовувати. Але за цей час MongoDB стала набагато зрілішим продуктом. Що ж сталося? Чи вся ненависть пояснюється помилками на початку маркетингу нової СУБД? Або люди просто використовують MongoDB не там, де потрібно?
Якщо вам раптом здається, що я захищаю MongoDB, будь ласка, прочитайте наприкінці статті.
новий тренд
Я працюю в софверній індустрії більше років, ніж пристойно говорити, але все одно на мою частку припала лише мала частина трендів, які вдарили по нашій галузі. Я був свідком зростання 4GL, AOP, Agile, SOA, Web 2.0, AJAX, блокчейна… список нескінченний. Щороку з'являються нові тенденції. Деякі швидко згасають, інші принципово змінюють способи розробки ПЗ.
Навколо кожного нового тренду створюється якесь загальне хвилювання: люди або самі стрибають у човен, або бачать шум, генерований іншими - і йдуть за натовпом. Цей процес кодифікований компанією Gartner в . Хоча спірний, але цей графік приблизно описує, що відбувається з технологіями, перш ніж вони в результаті стануть корисними для використання.
Але іноді виникає (чи буває друге наступ, як у разі) нова інновація, рухома лише однією конкретної її реалізацією. У разі NoSQL хайп був обумовлений появою і стрімким підйомом MongoDB. Не MongoDB запустила цей тренд: насправді у великих інтернет-компаніях почалися проблеми з обробкою великих обсягів даних, які призвели до повернення нереляційних БД. Загальний рух стартував з таких проектів, як Bigtable від Google та Cassandra від Facebook, але саме MongoDB стала найвідомішою та найдоступнішою реалізацією бази даних NoSQL, до якої мали доступ більшість розробників.
Примітка: Ви можете подумати, що я змішую документальні БД з колонковими БД, сховищами ключів/значень або будь-яким з численних інших типів сховищ даних, які підпадають під загальне визначення NoSQL. І ви маєте рацію. Але на той час панував хаос. Всі збожеволіли на NoSQL, всім воно стало абсолютно необхідно, хоча багато хто не бачив відмінностей у різних технологіях. Для багатьох MongoDB стала синонімом NoSQL.
І розробники накинулися на неї. Була досить привабливою ідея бази даних без схеми, яка магічно масштабується для вирішення будь-якої проблеми. Близько 2014 здавалося, що скрізь, де ще рік тому використовувалася реляційна база даних, така як MySQL, Postgres або SQL Server, почали розгортати бази MongoDB. На питання чому, ви могли отримати відповідь від банального «це масштаб вебу» до більш продуманого «мої дані дуже структуровані і добре вписуються в базу даних без схеми».
Важливо пам'ятати, що MongoDB і бази даних документів загалом вирішують низку проблем із традиційними реляційними базами даних:
- Сувора схема: з реляційною базою даних, якщо у вас динамічно сформовані дані, ви змушені або створити купу випадкових «різних» стовпців даних, впхнути туди блоби даних або використовувати конфігурацію … у цього значні недоліки.
- Складність масштабування: якщо даних настільки багато, що вони не розміщуються на одному сервері, MongoDB пропонувала механізми, що дозволяють масштабувати їх на декількох машинах.
- Складні модифікації схеми: жодних міграцій! У реляційній базі даних зміна структури БД може стати величезною проблемою (особливо, коли даних стає дуже багато). MongoDB змогла значно спростити процес. І зробило його настільки легким, що ви можете просто оновлювати схему на ходу і швидко рухатися далі.
- Продуктивність запису: продуктивність MongoDB була гарною, особливо при грамотному налаштуванні. Навіть конфігурація MongoDB із коробки, за яку її часто критикували, демонструвала деякі вражаючі показники продуктивності.
Усі ризики на вас
Потенційні переваги MongoDB були величезними, особливо для певних класів проблем. Якщо прочитати наведений вище список без розуміння контексту і не маючи досвіду, то може скластися враження, що MongoDB дійсно революційна СУБД. Єдина проблема полягала в тому, що перелічені вище переваги супроводжувалися низкою застережень, деякі з яких наведені нижче.
Заради справедливості, ніхто в 10gen/MongoDB Inc. не скаже, що це неправда, це просто компроміси.
- Втрата транзакцій: транзакції є основною особливістю багатьох реляційних баз даних (не всіх, але більшості). Транзакційність означає, що ви можете виконувати кілька операцій атомарно і гарантувати, що дані залишаться узгодженими. Звичайно, з базою даних NoSQL транзакційність може бути в рамках одного документа або ви можете використовувати двофазні коміти, щоб отримати транзакційну семантику. Але вам доведеться самому реалізувати цю функціональність, що може бути складним і трудомістким завданням. Часто ви не усвідомлюєте проблеми, поки не побачите, що дані БД потрапляють у неприпустимі стани, тому що неможливо гарантувати атомарність операцій. Примітка: багато хто мені повідомив, що минулого року в MongoDB 4.0 з'явилися транзакції, але з рядом обмежень. Висновок зі статті залишається тим самим: оцініть, наскільки технологія відповідає вашим потребам.
- Втрата реляційної цілісності (зовнішні ключі): якщо у ваших даних є стосунки, то вам доведеться застосовувати їх у додатку. Наявність БД з дотриманням цих відносин зніме значну частину роботи з програми і, отже, з програмістів.
- Відсутність можливості застосовувати структуру даних: Суворі схеми іноді стають великою проблемою, але це також і потужний механізм хорошого структурування даних, якщо грамотно їх використовувати. Документні БД, такі як MongoDB, забезпечують неймовірну гнучкість схеми, але це гнучкість знімає відповідальність збереження даних у чистоті. Якщо ви не подбаєте про них, то в кінцевому підсумку доведеться писати в додатку багато коду для обліку даних, які зберігаються не в тій формі, яку ви очікуєте. Як часто кажуть у нашій компанії Simple Thread… додаток колись перепишуть, а дані житимуть вічно. Примітка: MongoDB підтримує перевірку схеми: вона корисна, але не надає ті ж гарантії, що в реляційній базі даних. Насамперед додавання або зміна перевірки схеми не впливає на наявні дані в колекції. Ви самі повинні переконатися, що оновлюєте дані відповідно до нової схеми. Вирішуйте самі, чи цього достатньо для ваших потреб.
- Власна мова запитів / втрата екосистеми інструментів: поява SQL стала абсолютною революцією, і з того часу нічого не змінилося Це неймовірно потужна мова, але й досить складна. Необхідність конструювати запити до БД новою мовою, що складається з фрагментів JSON, розцінюється як великий крок назад людьми, які мають досвід роботи з SQL. Існує цілий всесвіт інструментів, які взаємодіють із базами даних SQL: від IDE до інструментів звітності. Перехід до бази даних, яка не підтримує SQL, означає, що ви не можете використовувати більшість цих інструментів або вам потрібно перевести дані в SQL, щоб їх використовувати, а це може виявитися складнішим, ніж ви думаєте.
Багато розробників, які звернулися до MongoDB, не дуже розуміли компроміси, і часто пірнали з головою, встановлюючи її як основне сховище даних. Після такого часто було неймовірно важко повернутися назад.
Що можна було зробити інакше?
Не всі стрибали головою вперед і врізалися на дно. Але чимало проектів встановлювали базу MongoDB туди, куди вона просто не підходила — і їм доведеться жити з нею ще багато років. Якби ці організації витратили деякий час і методично обміркували вибір технологій, то багато хто зробив інший вибір.
Як вибрати потрібну технологію? Було кілька спроб створити систематичний фреймворк для оцінки технологій, таких як и але мені здається, що це зайва складність.
Багато технологій можна розумно оцінити, поставивши лише два основні питання. Проблема полягає у пошуку людей, які можуть відповідально на них відповісти, витративши час на пошук відповідей і без упередженості.
Якщо ви не стикаєтеся з проблемою, вам не потрібен новий інструмент. Крапка.
Запитання 1: Які проблеми я намагаюся вирішити?
Якщо ви не стикаєтеся з проблемою, вам не потрібен новий інструмент. Крапка. Не потрібно шукати рішення, а потім вигадувати проблему. Якщо ви не зіткнулися з проблемою, яку нова технологія не вирішує значно краще, ніж ваша технологія, то тут нема чого обговорювати. Якщо ви розглядаєте можливість використання цієї технології, тому що бачили, як її використовують інші, подумайте, з якими проблемами вони стикаються, і запитайте, чи є у вас такі проблеми. Легко прийняти технологію, тому що її використовують інші, складність полягає в розумінні, чи стикаєтеся ви з тими самими проблемами.
Питання 2: Чого я втрачаю?
Це, безумовно, важче питання, тому що доведеться копатися і добре зрозуміти як стару, так і нову технологію. Іноді ви не можете по-справжньому зрозуміти нову, поки не збудуєте щось з її допомогою або у вас не з'явиться співробітник, який має такий досвід.
Якщо у вас немає ні того, ні іншого, то варто подумати про мінімально можливі інвестиції для визначення цінності цього інструменту. І якщо ви зробите інвестиції, наскільки важко скасувати рішення?
Люди завжди все псують
Намагаючись відповісти на ці питання якомога неупередженіше, пам'ятайте одну річ: вам доведеться боротися з людською природою. Існує низка когнітивних спотворень, які необхідно подолати, щоб ефективно оцінити технологію. Ось лише кілька:
- - всі про нього знають, але все одно з ним важко боротися. Просто переконайтеся, що технологія справді відповідає вашим реальним потребам.
- — багато розробників схильні недооцінювати технології, з якими працювали протягом тривалого часу, та переоцінювати переваги нової технології. Не тільки програмісти, всі схильні до цього когнітивного спотворення.
- — ми схильні бачити те, що є, і не беремо до уваги те, що відсутнє. Це може призвести до хаосу у поєднанні з ефектом новизни, оскільки ви не тільки за своєю суттю переоцінюєте нову технологію, а й ігноруєте її недоліки.
Об'єктивна оцінка дається непросто, але розуміння основних когнітивних спотворень допоможе ухвалити раціональніші рішення.
Резюме
Коли з'являється інновація, потрібно з великою обережністю відповісти на два питання:
- Чи цей інструмент вирішує реальну проблему?
- Чи добре ми розуміємо компроміси?
Якщо ви не можете впевнено відповісти на ці два питання, зробіть кілька кроків тому і подумайте.
То чи була MongoDB взагалі правильним вибором? Звісно так; як і в більшості інженерних технологій, це залежить від багатьох факторів. Серед тих, хто відповів на ці два питання, багато хто отримав користь з MongoDB і продовжує її отримувати. Хто ж цього не зробив, сподіваюся, отримали цінний і не надто болісний урок про рух за циклом хайпа.
Дисклеймер
Хочу уточнити, що я не відчуваю ні кохання, ні ненависті до MongoDB. Просто ми не мали таких проблем, для вирішення яких найкраще підходить MongoDB. Я знаю, що 10gen/MongoDB Inc. Спочатку діяла дуже сміливо, встановивши небезпечні значення за умовчанням і просуваючи MongoDB скрізь (особливо на хакатонах) як універсальне рішення для роботи з будь-якими даними. Мабуть, це було погане рішення. Але воно підтверджує описаний тут підхід: ці проблеми можна було виявити дуже швидко навіть за поверхневої оцінки технології.
Джерело: habr.com