Наскоро разбрах това Red Hat премахва поддръжката на MongoDB от Satellite (да речем, поради промени в лиценза). Накара ме да мисля, че през последните няколко години видях куп статии за това колко ужасен е MongoDB и че никой никога не трябва да го използва. Но през това време MongoDB се превърна в много по-зрял продукт. Какво стана? Наистина ли цялата омраза се дължи на грешки в началото на маркетинга на новата СУБД? Или хората просто използват MongoDB на грешното място?

Ако изведнъж почувствате, че защитавам MongoDB, моля, прочетете опровержение в края на статията.

Нова тенденция

В софтуерната индустрия съм повече години, отколкото е честно да се каже, но все пак бях само част от тенденциите, които удариха нашата индустрия. Бях свидетел на възхода на 4GL, AOP, Agile, SOA, Web 2.0, AJAX, блокчейн... списъкът е безкраен. Всяка година има нови тенденции. Някои избледняват бързо, докато други фундаментално променят начина, по който се разработва софтуерът.

Около всяка нова тенденция се създава известно общо вълнение: хората или сами скачат в лодката, или виждат шума, генериран от другите - и следват тълпата. Този процес е кодифициран от Gartner през Hype цикъл. Макар и спорна, тази графика грубо описва какво се случва с технологиите, преди те в крайна сметка да станат полезни за използване.

Но от време на време има (или има второ идване, както в този случай) нова иновация, движена само от едно конкретно нейно изпълнение. В случая с NoSQL рекламата беше силно предизвикана от появата и стремителния възход на MongoDB. MongoDB не започна тази тенденция: всъщност големите интернет компании започнаха да имат проблеми с обработката на големи количества данни, което доведе до връщането на нерелационни бази данни. Общото движение започна с проекти като Bigtable на Google и Cassandra на Facebook, но MongoDB стана най-известната и достъпна реализация на базата данни NoSQL, до която повечето разработчици имаха достъп.

Забележка: Може да си помислите, че бъркам бази данни с документи с бази данни с колони, хранилища за ключ/стойност или някой от многото други видове хранилища за данни, които попадат в общата дефиниция на NoSQL. И си прав. Но по това време цареше хаос. Всички са обсебени от NoSQL, той се превърна във всичко абсолютно необходимо, въпреки че мнозина не виждат разликите в различните технологии. За мнозина MongoDB се превърна в синоним на NoSQL.

И разработчиците скочиха върху него. Идеята за база данни без схеми, която магически се мащабира, за да реши всеки проблем, беше доста примамлива. Около 2014 г. изглеждаше, че навсякъде, където преди година се използваше релационна база данни като MySQL, Postgres или SQL Server, се внедряваха бази данни MongoDB. На въпроса защо можете да получите отговори от баналното „това е мащабът на мрежата“ до по-обмисленото „данните ми са много слабо структурирани и се вписват добре в база данни без схема“.

Важно е да запомните, че MongoDB и документните бази данни като цяло решават редица проблеми с традиционните релационни бази данни:

• Строга схема: с релационна база данни, ако имате динамично генерирани данни, вие сте принудени или да създадете куп произволни „различни“ колони с данни, да вмъкнете петна данни там или да използвате конфигурация EAV разширение… всичко това има значителни недостатъци.
• Трудност при мащабиране: Ако има толкова много данни, че не се побират на един сървър, 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 там, където тя просто не пасва - и те ще трябва да живеят с нея още много години. Ако тези организации бяха отделили известно време, за да обмислят методично своя технологичен избор, мнозина щяха да направят различен избор.

Как да изберем правилната технология? Има няколко опита за създаване на систематична рамка за оценка на технологиите, като напр "Рамка за внедряване на технологии в софтуерни организации" и „Framefork за оценка на софтуерни технологии“, но ми се струва, че това е излишна сложност.

Много технологии могат да бъдат оценени интелигентно, като се зададат само два основни въпроса. Проблемът е в намирането на хора, които могат да им отговорят отговорно, като отделят време за намиране на отговори и без пристрастия.

Ако не се сблъскате с някакъв проблем, нямате нужда от нов инструмент. Точка.

Въпрос 1: Какви проблеми се опитвам да разреша?

Ако не се сблъскате с някакъв проблем, нямате нужда от нов инструмент. Точка. Няма нужда да търсите решение и след това да измислите проблем. Освен ако не сте изправени пред проблем, който новата технология не решава значително по-добре от вашата съществуваща технология, тогава няма какво да обсъждаме тук. Ако обмисляте да използвате тази технология, защото сте виждали други да я използват, помислете за проблемите, които имат, и попитайте дали вие имате такива проблеми. Лесно е да прегърнете технологията, защото другите я използват, трудността е да знаете дали сте изправени пред същите проблеми.

Въпрос 2: Какво пропускам?

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

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

Хората винаги развалят всичко

Опитвайки се да отговорите на тези въпроси възможно най-безпристрастно, запомнете едно нещо: трябва да се борите с човешката природа. Има редица когнитивни пристрастия, които трябва да бъдат преодолени, за да се оцени ефективно технологията. Ето само няколко:

• Ефектът от присъединяването към мнозинството Всички знаят за него, но въпреки това е трудно да се бориш с него. Просто се уверете, че технологията наистина отговаря на вашите реални нужди.
• ефект на новост Много разработчици са склонни да подценяват технологиите, с които работят от дълго време, и да надценяват предимствата на новата технология. Не само програмистите, всички са подложени на това когнитивно пристрастие.
• Ефект на положителен атрибут Склонни сме да виждаме какво е и да губим от поглед това, което не е. Това може да доведе до хаос, съчетан с ефекта на новост, тъй като вие не само присъщо надценявате новата технология, но и пренебрегвате нейните недостатъци..

Обективната оценка не е лесна, но разбирането на основните когнитивни пристрастия ще ви помогне да вземете по-рационални решения.

Обобщение

Когато се появи иновация, трябва да се отговори много внимателно на два въпроса:

• Този инструмент решава ли реален проблем?
• Добри ли сме в разбирането на компромисите?

Ако не можете да отговорите уверено на тези два въпроса, направете няколко крачки назад и помислете.

Така че като цяло la MongoDB беше правилният избор? Разбира се, да; както при повечето инженерни технологии, това зависи от много фактори. Сред тези, които отговориха на тези два въпроса, много са се възползвали от MongoDB и продължават да го правят. За тези от вас, които не са, надявам се, че сте научили ценен и не твърде болезнен урок за преминаването през цикъла на рекламите.

Опровержение

Искам да поясня, че нито обичам, нито мразя MongoDB. Просто нямахме проблемите, които MongoDB е най-подходящ за разрешаване. Познавам 10gen/MongoDB Inc. в началото действа много смело, задавайки несигурни настройки по подразбиране и рекламирайки MongoDB навсякъде (особено в хакатони) като едно гише решение за работа с всякакви данни. Вероятно беше лошо решение. Но това потвърждава описания тук подход: тези проблеми могат да бъдат открити много бързо дори с повърхностна оценка на технологията.

Източник: www.habr.com