Kohët e fundit e mora vesh këtë Red Hat heq mbështetjen e MongoDB nga Sateliti (thonë për shkak të ndryshimeve të licencës). Kjo më bëri të mendoj sepse në vitet e fundit kam parë një ton artikujsh se sa e tmerrshme është MongoDB dhe se si askush nuk duhet ta përdorë atë. Por gjatë kësaj kohe, MongoDB është bërë një produkt shumë më i pjekur. Cfare ndodhi? A është vërtet e gjithë urrejtja për shkak të gabimeve në marketingun e hershëm të një DBMS të re? Apo njerëzit thjesht përdorin MongoDB në vendet e gabuara?

Nëse mendoni se po mbroj MongoDB, ju lutemi lexoni mohim në fund të artikullit.

Trend i ri

Unë kam punuar në industrinë e softuerit për më shumë vite sesa mund të them, por ende jam ekspozuar vetëm ndaj një pjese të vogël të tendencave që kanë goditur industrinë tonë. Unë kam qenë dëshmitar i rritjes së 4GL, AOP, Agile, SOA, Web 2.0, AJAX, Blockchain... lista është e pafund. Çdo vit shfaqen tendenca të reja. Disa zhduken shpejt, ndërsa të tjerët ndryshojnë rrënjësisht mënyrën e zhvillimit të softuerit.

Çdo prirje e re krijon një eksitim të përgjithshëm: njerëzit ose hidhen në bord, ose shohin zhurmën e krijuar nga të tjerët dhe ndjekin turmën. Ky proces është kodifikuar nga Gartner në cikli hype. Edhe pse i diskutueshëm, ky afat kohor përshkruan përafërsisht se çfarë ndodh me teknologjitë përpara se ato përfundimisht të bëhen të dobishme.

Por herë pas here, një risi e re shfaqet (ose ka një ardhje të dytë, si në këtë rast) e nxitur nga vetëm një zbatim specifik. Në rastin e NoSQL, zhurma u nxit shumë nga shfaqja dhe ngritja meteorike e MongoDB. MongoDB nuk e filloi këtë prirje: në fakt, kompanitë e mëdha të internetit filluan të kishin probleme me përpunimin e sasive të mëdha të të dhënave, gjë që çoi në kthimin e bazave të të dhënave jo-relacionale. Lëvizja e përgjithshme filloi me projekte si Bigtable i Google dhe Cassandra i Facebook, por ishte MongoDB ai që u bë zbatimi më i njohur dhe më i aksesueshëm i bazës së të dhënave NoSQL në të cilin shumica e zhvilluesve kishin akses.

Shënim: Ju mund të mendoni se po ngatërroj bazat e të dhënave të dokumenteve me bazat e të dhënave kolone, dyqanet e çelësave/vlerave ose ndonjë nga llojet e tjera të shumta të ruajtjes së të dhënave që bien nën përkufizimin e përgjithshëm NoSQL. Dhe ke te drejte. Por në atë kohë mbretëronte kaosi. Të gjithë janë të fiksuar pas NoSQL, janë bërë të gjithë absolutisht e nevojshme, megjithëse shumë nuk i panë dallimet në teknologji të ndryshme. Për shumë, MongoDB është bërë sinonim me NoSQL.

Dhe zhvilluesit u hodhën mbi të. Ideja e një baze të dhënash pa skema që shkallëzohet në mënyrë magjike për të zgjidhur çdo problem ishte mjaft joshëse. Rreth vitit 2014, dukej se kudo që një vit më parë përdorej një bazë të dhënash relacionale si MySQL, Postgres ose SQL Server filloi të vendoste bazat e të dhënave MongoDB. Kur ju pyesni pse, mund të merrni një përgjigje nga banale "kjo është shkalla e internetit" deri në atë më të menduar "të dhënat e mia janë të strukturuara shumë lirshëm dhe përshtaten mirë në një bazë të dhënash pa një skemë".

Është e rëndësishme të mbani mend se MongoDB, dhe bazat e të dhënave të dokumenteve në përgjithësi, zgjidhin një numër problemesh me bazat e të dhënave relacionale tradicionale:

• Skema strikte: Me një bazë të dhënash relacionale, nëse keni të dhëna të gjeneruara në mënyrë dinamike, jeni të detyruar ose të krijoni një grup kolonash të rastësishme "të ndryshme" të dhënash, të futni blloqe të dhënash atje ose të përdorni konfigurimin Zgjatja EAV...e gjithë kjo ka të meta të rëndësishme.
• Vështirësi në shkallëzim: Nëse ka aq shumë të dhëna që nuk përshtaten në një server, MongoDB ofroi mekanizma për t'i lejuar ato të shkallëzohen nëpër makina të shumta.
• Modifikime komplekse të qarkut: pa migrime! Në një bazë të dhënash relacionale, ndryshimi i strukturës së bazës së të dhënave mund të jetë një problem i madh (veçanërisht kur ka shumë të dhëna). MongoDB ishte në gjendje të thjeshtonte shumë procesin. Dhe e bëri kaq të lehtë sa që thjesht mund të përditësoni qarkun ndërsa shkoni dhe ecni përpara shumë shpejt.
• Performanca e regjistrimit: Performanca e MongoDB ishte e mirë, veçanërisht kur konfigurohej siç duhet. Edhe konfigurimi i jashtëm i MongoDB, për të cilin shpesh kritikohej, tregoi disa numra mbresëlënës të performancës.

Të gjitha rreziqet janë mbi ju

Përfitimet e mundshme të MongoDB ishin të mëdha, veçanërisht për klasa të caktuara problemesh. Nëse e lexoni listën e mësipërme pa e kuptuar kontekstin dhe pa përvojë, mund të keni përshtypjen se MongoDB është vërtet një DBMS revolucionare. Problemi i vetëm ishte se përfitimet e listuara më sipër erdhën me një numër paralajmërimesh, disa prej të cilave janë renditur më poshtë.

Për të qenë të drejtë, askush në 10gen/MongoDB Inc. nuk do të them se sa vijon nuk është e vërtetë, këto janë thjesht kompromise.

• Transaksionet e humbura: Transaksionet janë një tipar thelbësor i shumë bazave të të dhënave relacionale (jo të gjitha, por shumica). Transaksioni do të thotë që ju mund të kryeni operacione të shumta në mënyrë atomike dhe mund të siguroheni që të dhënat të mbeten të qëndrueshme. Natyrisht, me një bazë të dhënash NoSQL, transaksionaliteti mund të jetë brenda një dokumenti të vetëm, ose mund të përdorni angazhime dyfazore për të marrë semantikën e transaksioneve. Por ju do të duhet ta zbatoni vetë këtë funksionalitet... që mund të jetë një detyrë e vështirë dhe që kërkon shumë kohë. Shpesh nuk e kuptoni se ka një problem derisa të shihni që të dhënat në bazën e të dhënave përfundojnë në gjendje të pavlefshme, sepse atomiciteti i operacioneve nuk mund të garantohet. Shënim: Shumë njerëz më thanë se MongoDB 4.0 prezantoi transaksione vitin e kaluar, por me disa kufizime. Përfundimi nga artikulli mbetet i njëjtë: vlerësoni se sa mirë teknologjia i plotëson nevojat tuaja.
• Humbja e integritetit relacional (çelësat e huaj): Nëse të dhënat tuaja kanë lidhje, atëherë do t'ju duhet t'i zbatoni ato në aplikacion. Të kesh një bazë të dhënash që respekton këto marrëdhënie do të heqë shumë punë nga aplikacioni dhe për rrjedhojë edhe nga programuesit tuaj.
• Mungesa e aftësisë për të aplikuar strukturën e të dhënave: Skemat strikte ndonjëherë mund të jenë një problem i madh, por ato janë gjithashtu një mekanizëm i fuqishëm për strukturimin e mirë të të dhënave nëse përdoren me mençuri. Bazat e të dhënave të dokumenteve si MongoDB ofrojnë fleksibilitet të jashtëzakonshëm të skemës, por ky fleksibilitet heq përgjegjësinë për mbajtjen e të dhënave të pastra. Nëse nuk kujdeseni për to, do të përfundoni duke shkruar shumë kode në aplikacionin tuaj për të llogaritur të dhënat që nuk ruhen në formën që prisni. Siç themi shpesh në kompaninë tonë Simple Thread... aplikacioni një ditë do të rishkruhet, por të dhënat do të jetojnë përgjithmonë. Shënim: MongoDB mbështet kontrollin e skemës: është i dobishëm, por nuk ofron të njëjtat garanci si në një bazë të dhënash relacionale. Para së gjithash, shtimi ose ndryshimi i një kontrolli të skemës nuk ndikon në të dhënat ekzistuese në koleksion. Varet nga ju që të siguroheni që të përditësoni të dhënat sipas skemës së re. Vendosni vetë nëse kjo është e mjaftueshme për nevojat tuaja.
• Gjuha amtare e pyetjes / humbja e ekosistemit të veglave: Ardhja e SQL ishte një revolucion absolut dhe asgjë nuk ka ndryshuar që atëherë. Është një gjuhë tepër e fuqishme, por edhe mjaft komplekse. Nevoja për të ndërtuar pyetjet e bazës së të dhënave në një gjuhë të re të përbërë nga fragmente JSON konsiderohet si një hap i madh prapa nga njerëzit që kanë përvojë pune me SQL. Ekziston një univers i tërë mjetesh që ndërveprojnë me bazat e të dhënave SQL, nga IDE-të deri te mjetet e raportimit. Kalimi në një bazë të dhënash që nuk mbështet SQL do të thotë që nuk mund të përdorni shumicën e këtyre mjeteve ose duhet t'i përktheni të dhënat në SQL për t'i përdorur ato, gjë që mund të jetë më e vështirë nga sa mendoni.

Shumë zhvillues që iu drejtuan MongoDB-së nuk i kuptuan vërtet kompromiset dhe shpesh u zhytën me kokë në instalimin e tij si dyqanin e tyre kryesor të të dhënave. Pas kësaj, shpesh ishte tepër e vështirë të kthehesh.

Çfarë mund të ishte bërë ndryshe?

Jo të gjithë kërcyen me kokë dhe goditën fundin. Por shumë projekte kanë instaluar MongoDB në vende ku thjesht nuk përshtatej - dhe ata do të duhet të jetojnë me të për shumë vite në vijim. Nëse këto organizata do të kishin shpenzuar pak kohë dhe do të kishin menduar metodikisht për zgjedhjet e tyre teknologjike, shumë do të kishin bërë zgjedhje të ndryshme.

Si të zgjidhni teknologjinë e duhur? Ka pasur disa përpjekje për të krijuar një kornizë sistematike për vlerësimin e teknologjisë, si p.sh "Korniza për futjen e teknologjive në organizatat softuerike" и "Korniza për vlerësimin e teknologjive softuerike", por më duket se ky është një kompleksitet i panevojshëm.

Shumë teknologji mund të vlerësohen në mënyrë inteligjente duke bërë vetëm dy pyetje themelore. Problemi është gjetja e njerëzve që mund t'u përgjigjen atyre me përgjegjësi, duke marrë kohë për të gjetur përgjigjet dhe pa paragjykime.

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

Pyetja 1: Cilat probleme po përpiqem të zgjidh?

Nëse nuk po përballeni me ndonjë problem, nuk keni nevojë për një mjet të ri. Pika. 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 e zgjidh dukshëm më mirë se teknologjia juaj ekzistuese, nuk ka asgjë për të diskutuar këtu. Nëse po mendoni ta përdorni këtë teknologji sepse keni parë të tjerë që e përdorin atë, mendoni se me çfarë problemesh përballen dhe pyesni nëse i keni ato probleme. Është e lehtë të pranosh një teknologji sepse të tjerët po e përdorin atë, sfida është të kuptosh nëse përballesh me të njëjtat probleme.

Pyetja 2: Çfarë më mungon?

Kjo është padyshim një pyetje më e vështirë sepse do t'ju duhet të gërmoni dhe të keni një kuptim të mirë të teknologjisë së vjetër dhe të re. Ndonjëherë nuk mund ta kuptoni vërtet një të re derisa të keni ndërtuar diçka me të ose të keni dikë me atë përvojë.

Nëse nuk keni asnjërën, atëherë ka kuptim të mendoni për investimin minimal të mundshëm për të përcaktuar vlerën e këtij instrumenti. Dhe sapo të bëni investimin, sa e vështirë do të jetë të ktheni vendimin?

Njerëzit gjithmonë shkatërrojnë gjithçka

Ndërsa përpiqeni t'u përgjigjeni këtyre pyetjeve në mënyrë sa më të paanshme, mbani mend një gjë: do t'ju duhet të luftoni natyrën njerëzore. Ekzistojnë një numër paragjykimesh njohëse që duhen kapërcyer për të vlerësuar në mënyrë efektive teknologjinë. Këtu janë vetëm disa:

• Efekti i bashkimit me mazhorancën - të gjithë e dinë për të, por është ende e vështirë ta luftosh. Vetëm sigurohuni që teknologjia të përputhet me nevojat tuaja aktuale.
• Efekti risi — Shumë zhvillues priren të nënvlerësojnë teknologjitë me të cilat kanë punuar për një kohë të gjatë dhe të mbivlerësojnë përfitimet e teknologjisë së re. Nuk janë vetëm programuesit, të gjithë janë të ndjeshëm ndaj këtij paragjykimi kognitiv.
• Efekti i karakteristikave pozitive - Ne priremi të shohim atë që ka dhe të humbasim nga sytë atë që mungon. Kjo mund të çojë në kaos kur kombinohet me efektin e risisë, pasi jo vetëm që e mbivlerësoni teknologjinë e re, por edhe injoroni të metat e saj.

Vlerësimi objektiv nuk është i lehtë, por të kuptuarit e paragjykimeve themelore njohëse do t'ju ndihmojë të merrni vendime më racionale.

Përmbledhje

Sa herë që shfaqet një risi, dy pyetjeve duhet t'u përgjigjen me shumë kujdes:

• A zgjidh ky mjet një problem real?
• A i kuptojmë mirë kompromiset?

Nëse nuk mund t'u përgjigjeni me siguri këtyre dy pyetjeve, bëni disa hapa prapa dhe mendoni.

Pra, a ishte MongoDB edhe zgjedhja e duhur? Sigurisht po; Ashtu si me shumicën e teknologjive inxhinierike, kjo varet nga shumë faktorë. Ndër ata që iu përgjigjën këtyre dy pyetjeve, shumë kanë përfituar nga MongoDB dhe vazhdojnë ta bëjnë këtë. Për ata që nuk e bënë, shpresoj të keni mësuar një mësim të vlefshëm dhe jo shumë të dhimbshëm për të kaluar nëpër ciklin e reklamave.

Përgjegjësia

Dua ta bëj të qartë se nuk kam as një marrëdhënie dashurie dhe as urrejtjeje me MongoDB. Ne thjesht nuk kemi pasur llojin e problemeve që MongoDB është më i përshtatshmi për të zgjidhur. Unë e di që 10gen/MongoDB Inc. ishte shumë e guximshme në fillim, duke vendosur standarde të pasigurta dhe duke promovuar MongoDB kudo (veçanërisht në hackathons) si një zgjidhje universale për të punuar me çdo të dhënë. Ndoshta ishte një vendim i keq. Por konfirmon qasjen e përshkruar këtu: këto probleme mund të zbulohen shumë shpejt edhe me një vlerësim sipërfaqësor të teknologjisë.

Burimi: www.habr.com