Неодамна го дознав тоа Red Hat ја отстранува поддршката за MongoDB од сателит (велат поради промени во лиценцата). Ова ме натера да размислувам затоа што во последните неколку години видов еден тон статии за тоа колку е ужасен MongoDB и како никој никогаш не треба да го користи. Но, за ова време, MongoDB стана многу позрел производ. Што се случи? Дали целата омраза навистина се должи на грешки во раниот маркетинг на нов DBMS? Или луѓето само користат MongoDB на погрешни места?

Ако се чувствувате како да го бранам MongoDB, прочитајте одрекување на крајот од статијата.

Нов тренд

Работам во софтверската индустрија повеќе години отколку што можам да кажам, но сè уште сум изложен само на мал дел од трендовите што ја погодија нашата индустрија. Сведок сум на подемот на 4GL, AOP, Agile, SOA, Web 2.0, AJAX, Blockchain... списокот е бесконечен. Секоја година се појавуваат нови трендови. Некои брзо исчезнуваат, додека други суштински го менуваат начинот на кој се развива софтверот.

Секој нов тренд создава општа возбуда: луѓето или скокаат на бродот, или ја гледаат бучавата што ја создаваат другите и ја следат толпата. Овој процес е кодифициран од Гартнер во циклус на возбуда. Иако е контроверзен, оваа временска рамка грубо опишува што се случува со технологиите пред тие на крајот да станат корисни.

Но, одвреме-навреме се појавува нова иновација (или има второ доаѓање, како во овој случај) поттикната од само една специфична имплементација. Во случајот со 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 е навистина револуционерен DBMS. Единствениот проблем беше што придобивките наведени погоре дојдоа со голем број предупредувања, од кои некои се наведени подолу.

Да бидеме фер, никој во 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 насекаде (особено на хакатоните) како универзално решение за работа со какви било податоци. Веројатно тоа беше лоша одлука. Но, тоа го потврдува пристапот опишан овде: овие проблеми може да се откријат многу брзо дури и со површна проценка на технологијата.

Извор: www.habr.com