Наскоро разбрах, че (казват, заради промени в лиценза). Това ме накара да се замисля, че през последните няколко години съм виждал много статии за това колко ужасна е 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
