Së fundmi mësova se Red Hat po heq mbështetje për MongoDB nga Satellite (thuhet, për shkak të ndryshimeve në licencë). Kjo më bëri të mendoj se në vitet e fundit kam parë shumë artikuj që flasin për si e tmerrshme është MongoDB dhe se askush nuk duhet ta përdorë atë. Por gjatë kësaj kohe, MongoDB është bërë një produkt shumë më i pjekur. Çfarë ndodhi? A është e vërtetë se gjithë urrejtja shpjegohet nga gabimet në fillim të marketingut të kësaj SGBD? Apo ndoshta njerëzit thjesht po e përdorin MongoDB në vende që nuk janë të duhura?

Nëse ndonjëherë mendoni se po e mbroj MongoDB, ju lutem lexoni çështjen e përjashtimit në fund të artikullit.

Tendenca e re

Kam punuar në industrinë e softuerit për më shumë vite sesa është e hijshme të flas, por megjithatë kam përjetuar vetëm një pjesë të vogël të trendeve që kanë goditur industrinë tonë. Kam qenë dëshmitar i rritjes së 4GL, AOP, Agile, SOA, Web 2.0, AJAX, blockchain... lista është e pafund. Çdo vit shfaqen trende të reja. Disa shuhet shpejt, ndërsa të tjera ndryshojnë thelbësisht mënyrat e zhvillimit të softuerit.

Rreth çdo trendi të ri krijohet një lloj eksitimi të përgjithshëm: njerëzit ose hopin vetë në këtë anije, ose shohin zhurmën e gjeneruar nga të tjerët - dhe ndjekin turmën. Ky proces është kodifikuar nga kompania Gartner në ciklin e hype. Edhe pse është diskutueshme, ky grafik përfaqëson për mjeshtërish se çfarë ndodh me teknologjitë para se ato të bëhen të dobishme për përdorim.

Por herë pas here shfaqet (ose ndodh kthimi i dytë, si në këtë rast) një inovacion i ri, i drejtuar vetëm nga një zbatim i veçantë. Në rastin e NoSQL, hype u ndikua shumë nga shfaqja dhe ngjitja e shpejtë e MongoDB. Nuk ishte MongoDB që e nisi këtë trend: në fakt, problemet filluan në kompanitë e mëdha të internetit me trajtimin e volumit të madh të të dhënave, që çuan në kthimin e bazave të të dhënave jo-relacionale. Lëvizja filloi me projekte të tilla si Bigtable nga Google dhe Cassandra nga Facebook, por në fakt MongoDB u bë implementimi më i njohur dhe më i aksesueshëm i bazës së të dhënave NoSQL për shumicën e zhvilluesve.

Shënim: mund të mendoni se po e përziej bazat e të dhënave dokumentare me bazat e të dhënave kolonale, depozitat e çelësit/vlerës ose ndonjë nga shumë llojet e tjera të depozitave të të dhënave që bien nën përkufizimin e përgjithshëm NoSQL. Dhe keni të drejtë. Por në atë kohë kishte kaos. Të gjithë ishin çmendur pas NoSQL, të gjithëve iu bë absolutisht nevojitet, megjithëse shumë nuk kanë parë dallime në teknologji të ndryshme. Për shumë, MongoDB është bërë synonim i NoSQL.

Dhe zhvilluesit iu afruan asaj. Ideja e një baze të dhënash pa skemë që magjishëm shkallëzohet për të zgjidhur çdo problem ishte mjaft tërheqëse. Rreth vitit 2014, dukej se kudo, atje ku një vit më parë përdorej një bazë e dhënash relacionale si MySQL, Postgres ose SQL Server, filluan të implementonin baza MongoDB. Në pyetjen pse, mund të merrnit një përgjigje nga e thjeshta "është shkalla e web-it" deri te një "të dhënat e mia janë shumë pak të strukturuara dhe përshtaten mirë në një bazë të dhënash pa skemë".

Është e rëndësishme të mbani mend se MongoDB dhe bazat e dhënash dokumentesh në përgjithësi zgjidhin një sërë problemash me bazat tradicionale të dhënash relacionale:

Skema rigoroze: me një bazë të dhënash relacionale, nëse keni të dhëna të formuara dinamikisht, jeni të detyruar të krijoni shumë "kolona të ndryshme" të rastësishme, të futni blob të të dhënave ose të përdorni konfigurimin EAV… të gjithë këto kanë disavantazhe të konsiderueshme.
Vështirësia në shkallëzim: nëse të dhënat janë aq të mëdha sa që nuk i përngjiten një serveri, MongoDB ofronte mekanizma që lejojnë shkallëzimin e tyre në disa makina.
Modifikimet e komplikuara të skemës: asnjë migrim! Në një bazë të dhënash relacionale, ndryshimi i strukturës më pas mund të jetë një problem i madh (sidomos kur të dhënat bëhen shumë të mëdha). MongoDB arriti ta thjeshtojë ndjeshëm këtë proces. Dhe e bëri aq të lehtë sa mund të thjesht përditësoni skemën në lëvizje dhe të ecni përpara shumë shpejt.
Performanca e shkruar: performanca e MongoDB ishte e mirë, veçanërisht kur ishte e konfiguruar mirë. Edhe konfigurimi i MongoDB nga fabrika, për të cilin shpesh është kritikuar, tregonte disa rezultate mbresëlënëse në performancë.

Të gjitha rreziqet bien mbi ju

Përfitimet e mundshme të MongoDB ishin të mëdha, veçanërisht për disa kategori problemesh. Nëse e lexoni listën e mësipërme pa kuptuar kontekstin dhe pa pasur përvojë, mund të krijoni përshtypjen se MongoDB është vërtet një sistem i dhënash revolucionar. Problemi i vetëm ishte se përfitimet e renditura më lart erdhën me një sërë kushesh, disa prej të cilave janë përmendur më poshtë.

Për të qenë të drejtë, askush në 10gen/MongoDB Inc. nuk do të thotë se ajo që do të përmendet më poshtë është e pavërtetë, kjo është thjesht kompromis.

Humbje e transaksioneve: transaksionet janë karakteristika kryesore e shumë bazave të të dhënave relacionale (jo të gjitha, por shumica). Transaksionaliteti do të thotë se mund të kryeni disa operacione në mënyrë atomike dhe mund të garantoni që të dhënat do të mbeten të qëndrueshme. Sigurisht, me një bazë të dhënash NoSQL, transaksionaliteti mund të jetë brenda një dokumenti ose mund të përdorni komitete dy-fazës për të arritur semantikën transaksionale. Por do t'ju duhet ta implementoni vetë këtë funksionalitet... që mund të jetë një detyrë e komplikuar dhe e punës së rëndë. Shpesh nuk e kuptoni problemin deri sa të shihni se të dhënat në DB përfundojnë në gjendje të papranueshme, sepse nuk është e mundur të garantoni atomikën e operacioneve. Shënim: shumë më kanë thënë se vitin e kaluar në MongoDB 4.0 u shfaqën transaksionet, por me disa kufizime. Konkluzioni nga artikulli mbetet i njëjtë: vlerësoni sesa mirë teknologjia përputhet me nevojat tuaja.
Humbje e integritetit relational (çelësat e jashtëm): nëse të dhënat tuaja kanë marrëdhënie, do t'ju duhet t'i zbatoni ato në aplikacion. Të keni një DB që respekton këto marrëdhënie do të heqë një pjesë të madhe të punës nga aplikacioni dhe, për rrjedhojë, nga programuesit tuaj.
Mungesa e mundësisë për të aplikuar strukturën e të dhënave: skemat strikte ndonjëherë bëhen një problem të madh, por gjithashtu janë një mekanizëm i fuqishëm për strukturimin e mirë të të dhënave, nëse përdoren siç duhet. Bazat e të dhënave dokumentare, të tilla si MongoDB, ofrojnë një fleksibilitet të jashtëzakonshëm të skemave, por kjo fleksibilitet heq përgjegjësinë për ruajtjen e të dhënave në një formë të pastër. Nëse nuk kujdeseni për to, në fund të fundit do t'ju duhet të shkruani shumë kod në aplikacion për të pasur parasysh të dhënat që ruajnë nuk janë në formën që prisni. Siç thonë shpesh në kompaninë tonë Simple Thread... aplikacioni do të rishkruhet ndonjëherë, por të dhënat do të jetojnë përherë. Shënim: MongoDB mbështet verifikimin e skemës: është e dobishme, por nuk ofron të njëjtat garanci si në DB-në relacionale. Para së gjithash, shtimi ose ndryshimi i verifikimit të skemës nuk ndikon në të dhënat ekzistuese në koleksion. Ju vetë duhet të jeni të sigurt se përditësoni të dhënat sipas skemës së re. Vendosni vetë nëse kjo është e mjaftueshme për nevojat tuaja.
Gjuha e vetë kërkesave / humbja e ekosistemit të mjeteve: shfaqja e SQL u bë një revolucion absolut, dhe prej atëherë nuk ka ndryshuar asgjë. Është një gjuhë jashtëzakonisht e fuqishme, por mjaft e komplikuar. Nevoja për të ndërtuar kërkesat për DB në një gjuhë të re, e përbërë nga fragmente JSON-i, përjetohet si një hap i madh mbrapa nga njerëzit me përvojë në SQL. Ekziston një univers mjetesh që ndërveprojnë me databazat SQL: nga IDE tek mjetet e raportimit. Kalimi në një databazë që nuk mbështet SQL do të thotë se nuk mund të përdorni shumicën e këtyre mjeteve ose ju duhet të përktheni të dhënat në SQL për t'i përdorur, dhe kjo mund të jetë më e vështirë se sa mendoni.

Shumë zhvillues që iu drejtuan MongoDB-së nuk kuptonin shumë kompromisët, dhe shpesh zhyteshin thellë, duke e instaluar atë si ruajtjen e tyre kryesore të të dhënave. Pas kësaj, shpesh bëhej jashtëzakonisht e vështirë të kthehesh pas.

Çfarë mund të kishte ndodhur ndryshe?

Jo të gjithë u hodhën përpara dhe u goditën në fund. Por shumë projekte vendosën bazën MongoDB në vende ku ajo thjesht nuk përshtatej - dhe do t'u duhet të jetojnë me të edhe për shumë vite. Nëse këto organizata do të kishin kaluar disa kohë dhe do ishin menduar sistematikisht në lidhje me zgjedhjen e teknologjive, shumë do të kishin bërë një zgjedhje ndryshe.

Si të zgjidhni teknologjinë e duhur? Kishte disa përpjekje për të krijuar një kornizë sistematike për vlerësimin e teknologjive, siç janë «Korniza për implementimin e teknologjive në organizatat softuerike» dhe «Korniza për vlerësimin e teknologjive të softuerit», por më duket se kjo është një kompleksitet i tepërt.

Shumë teknologji mund të vlerësohen arsyeshëm duke iu bërë vetëm dy pyetje themelore. Problemi është në gjetjen e njerëzve që mund të përgjigjen me përgjegjshmëri ndaj tyre, duke kaluar kohë në kërkimin e përgjigjeve dhe pa paragjykime.

Nëse nuk po përballeni me ndonjë problem, nuk keni nevojë për një mjet të ri. Pikë.

Pyetja 1: Cilat janë problemet që po përpiqem të zgjidh?

Nëse nuk po hasni ndonjë problem, atëherë nuk ju nevojitet një instrument i ri. Pikë. Nuk ka nevojë të kërkoni një zgjidhje dhe pastaj të shpikni një problem. Nëse nuk keni hasur në një problem që teknologjia e re nuk e zgjidh dot ndjeshëm më mirë se teknologjia juaj ekzistuese, atëherë nuk ka çfarë të diskutohet. Nëse po shqyrtoni përdorimin e kësaj teknologjie sepse e keni parë atë në përdorim nga të tjerët, mendoni për problemet me të cilat ata përballen dhe pyesni veten nëse keni të njëjtat probleme. Është e lehtë të pranohet teknologjia sepse përdoret nga të tjerët; e vështirë është të kuptosh nëse hasni të njëjtat probleme.

Pyetja 2: Çfarë po heq?

Ky është padyshim një pyetje më e vështirë, sepse do të duhet të thelloheni dhe të kuptoni mirë si teknologjinë e vjetër ashtu edhe atë të re. Ndonjëherë nuk mund të kuptoni në të vërtetë të rejën derisa të ndërtoni diçka me të ose të keni një punonjës me përvojë të tillë.

Nëse nuk keni as ndonjërin as tjetrin, ka kuptim të mendoni për investimet minimale të mundshme për të përcaktuar vlerën e këtij instrumenti. Dhe nëse bëni investime, sa e lehtë do të jetë të anuloni vendimin?

Njerëzit gjithmonë e prishin gjithçka

Duke u përpjekur të përgjigjeni sa më paanësisht, mbani mend një gjë: do t'ju duhet të luftoni me natyrën njerëzore. Ekzistojnë një sërë distorsionesh digjestive që duhet të kaloni për të vlerësuar teknologjinë me efektivitet. Këtu janë disa prej tyre:

E efekti i bashkimit me shumicën — të gjithë e dinë për të, por është ende e vështirë ta përballosh. Thjesht sigurohuni që teknologjia vërtet përmbush nevojat tuaja reale.
E efekti i novitetit — shumë zhvillues tendencojnë ta nënvlerësojnë teknologjinë me të cilën kanë punuar për një kohë të gjatë dhe e teprojnë me përfitimet e teknologjisë së re. Jo vetëm programuesit, të gjithë janë të ekspozuar ndaj këtij distorsioni kognitiv.
E efekti i karakteristikave pozitive — priremi të shohim atë që është dhe të injorojmë atë që mungon. Kjo mund të çojë në kaos në kombinim me efektin e novitetit, pasi jo vetëm që mbiçmojmë në natyrë teknologjinë e re, por edhe injorojmë disavantazhet e saj..

Vlerësimi objektiv nuk është i lehtë, por kuptimi i shtrembërimeve kognitive qëndron në themel të vendimmarrjes më të arsyeshme.

Curriculum Vitae

Kur shfaqet një novacion, është e nevojshme të përgjigjemi me kujdes në dy pyetje:

A zgjidh ky mjet një problem të vërtetë?
A e kuptojmë mirë kompromisin?

Nëse nuk mund të përgjigjeni me siguri për këto dy pyetje, merrni disa hapa prapa dhe reflektoni.

A ishte MongoDB vërtet një zgjedhje e duhur? Sigurisht, po; si në shumicën e teknologjive inxhinierike, kjo varet nga një mori faktorësh. Mes atyre që i dhanë përgjigje këtyre dy pyetjeve, shumë përfituan nga MongoDB dhe vazhdojnë ta bëjnë këtë. Shpresoj që ata që nuk e bënë, të kenë marrë një mësim të vlefshëm dhe jo shumë të dhimbshëm për kalimin në ciklin e hype-it.

Kufizimi

Dua të sqaroj se nuk ndiej as dashuri, as urrejtje për MongoDB. Thjesht, nuk kemi pasur probleme për zgjidhjen e të cilave MongoDB është më e përshtatshme. E di që 10gen/MongoDB Inc. vepronte shumë guximshëm në fillim, duke vendosur vlera të pasigurta si të zakonshme dhe duke promovuar MongoDB kudo (veçanërisht në hackathon) si një zgjidhje universale për të punuar me të dhëna të çdo lloji. Ndoshta, kjo ishte një vendim i keq. Por kjo konfirmon qasjen e përshkruar këtu: këto probleme mund të zbulohet shumë shpejt, madje edhe me një vlerësim të sipërfaqshëm të teknologjisë.

Burimi: habr.com