Нядаўна я даведаўся, што (кажуць, з-за змен ліцэнзіі). Гэта прымусіла мяне задумацца, што ў апошнія некалькі гадоў я бачыў кучу артыкулаў, як жахлівая 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