Недавно сам то сазнао Ред Хат уклања подршку за МонгоДБ са Сателита (кажу због промена лиценце). Ово ме је навело на размишљање јер сам у последњих неколико година видео гомилу чланака о томе колико је МонгоДБ ужасан и како нико никада не би требало да га користи. Али за то време, МонгоДБ је постао много зрелији производ. Шта се десило? Да ли је сва мржња заиста последица грешака у раном маркетингу новог ДБМС-а? Или људи само користе МонгоДБ на погрешним местима?

Ако се осећате као да браним МонгоДБ, прочитајте одрицање од одговорности на крају чланка.

Нови тренд

Радим у софтверској индустрији више година него што могу да кажем, али сам још увек био изложен само малом делу трендова који су погодили нашу индустрију. Био сам сведок успона 4ГЛ, АОП, Агиле, СОА, Веб 2.0, АЈАКС, Блоцкцхаин... листа је бескрајна. Сваке године се појављују нови трендови. Неки брзо нестају, док други суштински мењају начин на који се софтвер развија.

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

Али с времена на време се појави нова иновација (или има други долазак, као у овом случају) вођена само једном специфичном имплементацијом. У случају НоСКЛ-а, узбуђење је у великој мери подстакнуто појавом и метеорским успоном МонгоДБ-а. МонгоДБ није покренуо овај тренд: у ствари, велике интернет компаније почеле су да имају проблема са обрадом великих количина података, што је довело до враћања нерелационих база података. Целокупни покрет је почео са пројектима као што су Гоогле Бигтабле и Фацебоок Цассандра, али МонгоДБ је постао најпознатија и најприступачнија имплементација НоСКЛ базе података којој је већина програмера имала приступ.

Напомена: Можда мислите да бркам базе података докумената са базама података у колонама, складиштима кључева/вредности или било којим од бројних других типова складишта података који потпадају под општу НоСКЛ дефиницију. И у праву си. Али у то време је владао хаос. Сви су опседнути НоСКЛ-ом, постао је свако апсолутно неопходно, иако многи нису видели разлике у различитим технологијама. За многе је МонгоДБ постао синоним НоСКЛ.

И програмери су насрнули на то. Идеја о бази података без шеме која се магично повећава да би решила било који проблем била је прилично примамљива. Око 2014. изгледало је да су свуда где су пре годину дана користили релационе базе података као што су МиСКЛ, Постгрес или СКЛ Сервер почели да примењују МонгоДБ базе података. На питање зашто, могли бисте добити одговор од баналног „ово је размера веба“ до промишљенијег „моји подаци су веома лабаво структурирани и добро се уклапају у базу података без шеме“.

Важно је запамтити да МонгоДБ, и базе података докумената уопште, решавају бројне проблеме са традиционалним релационим базама података:

• Строга шема: Са релационом базом података, ако имате динамички генерисане податке, приморани сте или да креирате гомилу насумичних „разних“ колона података, убаците мрвице података у њих или користите конфигурацију ЕАВ...све ово има значајне недостатке.
• Потешкоће у скалирању: Ако има толико података да не стану на један сервер, МонгоДБ је понудио механизме који им омогућавају да се скалирају на више машина.
• Комплексне модификације кола: нема миграција! У релационој бази података, промена структуре базе података може бити велики проблем (нарочито када има много података). МонгоДБ је успео да у великој мери поједностави процес. И то је учинило тако лаким да можете једноставно ажурирати коло док идете и врло брзо наставити даље.
• Перформансе снимања: МонгоДБ перформансе су биле добре, посебно када су правилно конфигурисане. Чак је и МонгоДБ-ова готова конфигурација, због које је често био критикован, показала неке импресивне бројке перформанси.

Сви ризици су на вама

Потенцијалне предности МонгоДБ-а биле су огромне, посебно за одређене класе проблема. Ако прочитате горњу листу без разумевања контекста и без искуства, можете стећи утисак да је МонгоДБ заиста револуционарни ДБМС. Једини проблем је био то што су горе наведене предности долазиле са бројним упозорењима, од којих су неке наведене у наставку.

Да будемо поштени, нико у 10ген/МонгоДБ Инц. неће рећи да следеће није тачно, то су само компромиси.

• Изгубљене трансакције: Трансакције су основна карактеристика многих релационих база података (не свих, али већине). Трансакциони значи да можете да извршите више операција атомски и да можете осигурати да подаци остану доследни. Наравно, са НоСКЛ базом података, трансакција може бити унутар једног документа, или можете користити двофазна урезивања да бисте добили трансакциону семантику. Али мораћете сами да имплементирате ову функционалност... што може бити тежак и дуготрајан задатак. Често не схватате да постоји проблем све док не видите да подаци у бази података заврше у неважећим стањима јер се атомичност операција не може гарантовати. Напомена: Многи људи су ми рекли да је МонгоДБ 4.0 увео трансакције прошле године, али са неким ограничењима. Закључак из чланка остаје исти: процените колико добро технологија задовољава ваше потребе.
• Губитак релационог интегритета (страни кључеви): Ако ваши подаци имају везе, онда ћете морати да их примените у апликацији. Поседовање базе података која поштује ове односе одузеће много посла апликацији, а самим тим и вашим програмерима.
• Недостатак могућности примене структуре података: Строге шеме понекад могу бити велики проблем, али су такође моћан механизам за добро структурирање података ако се користе мудро. Базе података докумената као што је МонгоДБ пружају невероватну флексибилност шеме, али ова флексибилност уклања одговорност за одржавање чистоће података. Ако не водите рачуна о њима, на крају ћете написати много кода у својој апликацији да бисте узели у обзир податке који нису ускладиштени у облику који очекујете. Као што често кажемо у нашој компанији Симпле Тхреад... апликација ће једног дана бити преписана, али подаци ће живети заувек. Напомена: МонгоДБ подржава проверу шеме: корисна је, али не пружа исте гаранције као у релационој бази података. Пре свега, додавање или промена провере шеме не утиче на постојеће податке у колекцији. На вама је да обезбедите да ажурирате податке у складу са новом шемом. Одлучите сами да ли је ово довољно за ваше потребе.
• Изворни језик упита / губитак екосистема алата: Појава СКЛ-а је била апсолутна револуција и од тада се ништа није променило. То је невероватно моћан језик, али и прилично сложен. Потребу за конструисањем упита базе података на новом језику који се састоји од ЈСОН фрагмената људи који имају искуства у раду са СКЛ-ом сматрају великим кораком уназад. Постоји читав универзум алата који комуницирају са СКЛ базама података, од ИДЕ-а до алата за извештавање. Прелазак на базу података која не подржава СКЛ значи да не можете да користите већину ових алата или морате да преведете податке у СКЛ да бисте их користили, што може бити теже него што мислите.

Многи програмери који су се окренули МонгоДБ-у нису баш разумели компромисе и често су се упуштали у његову инсталацију као примарно складиште података. После овога је често било невероватно тешко вратити се.

Шта је могло другачије да се уради?

Нису сви скочили главом и ударили у дно. Али многи пројекти су инсталирали МонгоДБ на местима где се једноставно није уклапао - и мораће да живе са њим дуги низ година. Да су ове организације провеле неко време и методично размишљале о својим технолошким изборима, многе би донеле другачије изборе.

Како одабрати праву технологију? Било је неколико покушаја да се створи систематски оквир за процену технологије, као нпр „Оквир за увођење технологија у софтверске организације“ и „Оквир за процену софтверских технологија“, али чини ми се да је то непотребна сложеност.

Многе технологије се могу интелигентно проценити постављањем само два основна питања. Проблем је у проналажењу људи који могу да им одговоре одговорно, узимајући време да пронађу одговоре и без пристрасности.

Ако се не суочавате са било каквим проблемом, не треба вам нови алат. Дот.

Питање 1: Које проблеме покушавам да решим?

Ако се не суочавате са било каквим проблемом, не треба вам нови алат. Дот. Нема потребе тражити решење, а затим измишљати проблем. Осим ако нисте наишли на проблем који нова технологија решава знатно боље од постојеће технологије, овде нема шта да се расправља. Ако размишљате о коришћењу ове технологије јер сте видели да је други користе, размислите са каквим се проблемима суочавају и питајте да ли имате те проблеме. Лако је прихватити технологију јер је други користе, изазов је разумети да ли се и ви суочавате са истим проблемима.

Питање 2: Шта ми недостаје?

Ово је дефинитивно теже питање јер ћете морати да се удубите и добро разумете и стару и нову технологију. Понекад не можете заиста да разумете нови док не изградите нешто са њим или имате некога са тим искуством.

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

Људи увек све покваре

Док покушавате да што непристрасније одговорите на ова питања, запамтите једну ствар: мораћете да се борите против људске природе. Постоји велики број когнитивних предрасуда које се морају превазићи да би се технологија ефикасно проценила. Ево само неколико:

• Ефекат придруживања већини - сви знају за њега, али је и даље тешко борити се против њега. Само се уверите да технологија заиста одговара вашим стварним потребама.
• Ефекат новитета — Многи програмери имају тенденцију да потцењују технологије са којима су дуго радили и прецене предности нове технологије. Нису само програмери, сви су подложни овој когнитивној пристрасности.
• Утицај позитивних карактеристика - Склони смо да видимо шта има и изгубимо из вида оно што недостаје. Ово може довести до хаоса када се комбинује са ефектом новитета, јер не само да инхерентно прецењујете нову технологију, већ и игноришете њене недостатке.

Објективна процена није лака, али разумевање основних когнитивних предрасуда ће вам помоћи да донесете рационалније одлуке.

Резиме

Кад год се појави иновација, потребно је пажљиво одговорити на два питања:

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

Ако не можете са сигурношћу да одговорите на ова два питања, вратите се неколико корака уназад и размислите.

Дакле, да ли је МонгоДБ уопште био прави избор? Наравно да; Као и код већине инжењерских технологија, ово зависи од многих фактора. Међу онима који су одговорили на ова два питања, многи су имали користи од МонгоДБ-а и настављају да то чине. За оне који нису, надам се да сте научили вредну и не превише болну лекцију о кретању кроз циклус хипе.

Одрицање од одговорности

Желим да појасним да немам ни љубав ни однос мржње са МонгоДБ-ом. Једноставно нисмо имали проблеме за које би МонгоДБ најбоље одговарао. Знам да 10ген/МонгоДБ Инц. у почетку је био веома храбар, постављајући несигурне подразумеване вредности и промовишући МонгоДБ свуда (нарочито на хакатонима) као универзално решење за рад са било којим подацима. Вероватно је то била лоша одлука. Али то потврђује приступ који је овде описан: ови проблеми могу се врло брзо открити чак и уз површну процену технологије.

Извор: ввв.хабр.цом