Së fundi mësova se (thonë, për shkak të ndryshimeve në lisencë). Kjo më bëri të mendoj se në vitet e fundit kam parë shumë artikuj që flasin sa e keqe është MongoDB dhe se askush nuk duhet ta përdorë kurrë. Por gjatë kësaj periudhe, MongoDB ka evoluar në një produkt shumë më të pjekur. Çfarë ndodhi? A është vërtet e gjithë kjo urrejtje e shpjeguar nga gabimet në fillim të marketingut të këtij DB të ri? Ose ndoshta njerëzit thjesht e përdorin MongoDB në situata ku nuk është e nevojshme?
Nëse ndonjëherë mendoni se po mbroj MongoDB, ju lutem lexoni në fund të artikullit.
Trendi i ri
Unë punoj në industrinë e softuerit më shumë vite nga sa është e arsyeshme të thuhet, por sërish, pjesa ime në trendet që e goditën sektorin tonë është e vogël. 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 shuhen shpejt, ndërsa të tjera ndryshojnë në mënyrë thelbësore mënyrat e zhvillimit të softuerit.
Rreth çdo trendi të ri krijohet një lëvizje e përgjithshme: njerëzit ose hopin vetë në anije, ose shohin zhurmën e gjeneruar nga të tjerët - dhe ndjekin turmën. Ky proces është kodifikuar nga kompania Gartner në . Edhe pse është i diskutueshëm, ky grafik përshkruan në mënyrë të arsyeshme se çfarë ndodh me teknologjitë përpara se ato të bëhen në fund të dobishme për përdorim.
Por herë pas here shfaqet (ose ndodh një ringjallje, si në këtë rast) një inovacion i ri, i drejtuar vetëm nga një zbatim specifik i tij. Në rastin e NoSQL, hype ishte shumë i ndikuar nga shfaqja dhe rritja e shpejtë e MongoDB. Nuk ishte MongoDB që e nisi këtë trend: në të vërtetë, problemet me përpunimin e volumit të madh të të dhënave filluan në kompanitë e mëdha të internetit, gjë që çoi në rikthimin e DB-ve jo-relaionale. Lëvizja filloi me projekte si Bigtable nga Google dhe Cassandra nga Facebook, por MongoDB u bë implementimi më i famshëm dhe më i arritshëm i DB-ve NoSQL të cilat ishin në dispozicion për shumicën e zhvilluesve.
Shënim: mund të mendoni se po i përziej BD-të dokumentuese me BD-të kolone, ruajtjet e çelikut/vlerave ose ndonjë nga shumë lloje të tjera të ruajtjeve të të dhënave që i përkasin definicionit të përgjithshëm NoSQL. Dhe keni të drejtë. Por në atë kohë mbizotëronte kaosi. Të gjithë ishin të çmendur pas NoSQL, dhe të gjithë ajo bëri absolutisht është e nevojshme, edhe pse shumë nuk kanë parë dallime në teknologjitë e ndryshme. Për shumë, MongoDB është bërë sinonim i NoSQL.
Dhe zhvilluesit u hodhën mbi të. Ideja e një baze të dhënash pa skemë, që magjishëm shkallëzohet për të zgjidhur çdo problem, ishte mjaft joshëse. Rreth vitit 2014, dukej sikur kudo ku vitin e kaluar ishte përdorur një bazë e dhënash relacional si MySQL, Postgres ose SQL Server, filluan të vendosnin bazat MongoDB. Në pyetjen pse, mund të merrni një përgjigje nga e thjeshtë "është shkallëzimi i webit" deri te më e menduar "të dhënat e mia janë shumë pak të strukturuara dhe i përshtaten mirë një baze 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ë problemesh me bazat e dhënash tradicionale relacional
- Skema e rreptë: me një bazë të dhënash relacional, nëse keni të dhëna të formuara dinamikisht, ju detyroheni ose të krijoni një grumbull "kolonash" të rastësishme, të shtoni aty blloqe të dhënash ose të përdorni konfigurimin … të gjitha 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 përshtaten në një server, MongoDB ofron mekanizma që lejojnë shkallëzimin e tyre në disa makina.
- Modifikimet e komplikuara të skemës: asnjë migrim! Në një bazë të dhënash relacional, ndryshimi i strukturës së Baza e Dhënash mund të bëhet një problem i madh (sidomos kur të dhënat bëhen shumë të mëdha). MongoDB ka arritur të thjeshtojë ndjeshëm procesin. Dhe e bëri aq të lehtë sa që mund të thjesht përditësoni skemën gjatë rrugës dhe të ecni përpara shumë shpejt.
- Performanca e shkrimit: performanca e MongoDB ka qenë e mirë, veçanërisht me konfigurim të mirë. Edhe konfigurimi i MongoDB nga fabrika, për të cilin shpesh është kritikuar, tregonte disa tregues mahnitës të performancës.
Të gjitha rreziqet janë mbi ju
Përfitimet potenciale 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ë krijohet përshtypja se MongoDB është me të vërtetë një DBMS revolucionar. Problemi i vetëm ishte se përfitimet e përmendura më sipër ishin të shoqëruara me një sërë shënimesh, disa nga të cilat janë përmendur më poshtë.
Për drejtësinë e gjërave, askush në 10gen/MongoDB Inc. nuk do të thotë që ajo që do të thotë më në fund është e vërtetë, janë thjesht kompromiset.
- Humor i transaksioneve: transaksionet janë karakteristika kryesore e shumë bazave të të dhënave relacional (jo të gjitha, por shumicës). Transaksionaliteti do të thotë që mund të kryeni disa operacione në mënyrë atomike dhe mund të garantoni që të dhënat të qëndrojnë të koherente. Sigurisht, me një bazë të dhënash NoSQL, transaksionaliteti mund të jetë brenda një dokumenti ose mund të përdorni komitet e dyfishta për të marrë semantikën transaksionale. Por do të duhet ta implementoni ju vetë këtë funksionalitet... që mund të jetë një detyrë e komplikuar dhe e lodhshme. Shpesh nuk e kuptoni problemin derisa të shihni se të dhënat në DB kalojnë në shtete të papranueshme, sepse nuk është e mundur të garantohet atomikiteti i operacioneve. Shënim: shumë njerëz më thanë se vitin e kaluar në MongoDB 4.0 u shfaqën transaksionet, por me disa kufizime. Konkluzioni i artikullit mbetet i njëjtë: vlerësoni sa teknologjia i përshtatet nevojave tuaja.
- Humor i integritetit relational (çelësa të jashtëm): nëse të dhënat tuaja kanë marrëdhënie, atëherë do t'ju duhet t'i aplikoni ato në aplikacion. Të pasurit e një DB që respekton këto marrëdhënie do të reduktojë një pjesë të madhe të punës me aplikacionin dhe, si rezultat, me programuesit tuaj.
- Mungesa e mundësisë për të aplikuar një strukturë të dhënash: skemat e rrepta hera-herës bëhen një problem i madh, por gjithashtu janë një mekanizëm i fuqishëm për strukturimin e mirë të të dhënave, nëse i përdorni me kompetencë. Baza të dhënash dokumentike, si MongoDB, ofrojnë një fleksibilitet të jashtëzakonshëm të skemës, por kjo fleksibilitet heq përgjegjësinë për mbajtjen e të dhënave të pastra. Nëse nuk kujdeseni për to, në fund do t'ju duhet të shkruani shumë kod në aplikacion për të marrë parasysh të dhënat që ruhen në një formë që nuk e prisni. Siç thonë shpesh në kompaninë tonë Simple Thread… aplikacioni do të rishkruhet ndonjëherë, ndërsa të dhënat do të jetojnë përgjithmonë. Vërejtje: MongoDB mbështet verifikimin e skemës: është e dobishme, por nuk ofron të njëjtat garanti si në një DB relacional. Në radhë të parë, shtimi ose modifikimi i verifikimit të skemës nuk ndikon në të dhënat ekzistuese në koleksiyon. Ju duhet të siguroni që përditësoni të dhënat në përputhje me skemën e re. Vendosni vetë nëse kjo është e mjaftueshme për nevojat tuaja.
- Gjuha e saj e kërkesave / humbja e ekosistemit të mjeteve: shfaqja e SQL ishte një revolucion absolut, dhe që nga ajo kohë nuk ka ndryshuar asgjë. Kjo është një gjuhë përjashtueshëm e fuqishme, por edhe mjaft komplekse. Nevoja për të ndërtuar kërkesa për DB në një gjuhë të re, që përbëhet nga fragmente JSON, perceptohet si një hap i madh prapa nga njerëzit me përvojë në SQL. Ekziston një universit i tërë mjeteve që ndërveprojnë me bazat e të dhënave SQL: nga IDE deri te mjetet e raportimit. Kalimi në një bazë të dhënash që nuk mbështet SQL nënkupton se nuk mund të përdorni shumicën e këtyre mjeteve ose duhet të konvertoni të dhënat në SQL për t'i përdorur, gjë që mund të jetë më e komplikuar sesa mendoni.
Shumë zhvillues që iu drejtuan MongoDB-së nuk kuptuan shumë kompromiset, dhe shpesh hidhnin me kokë, duke e vendosur atë si ruajtjen kryesore të të dhënave. Pas kësaj, shpesh ishte jashtëzakonisht e vështirë të ktheheshit pas.
Çfarë mund të bëhej ndryshe?
Nuk të gjithë u hodhën me kokë përpara dhe u goditën në fund. Por shumë projekte vendosën bazën MongoDB aty ku ajo thjesht nuk përputhej - dhe do të duhet të jetojnë me të ende shumë vite. Nëse këto organizata do të kishin shpenzuar disa kohë për të menduar metodikisht për zgjedhjen e teknologjive, shumë do të kishin bërë një zgjedhje tjetër.
Si të zgjidhni teknologjinë e duhur? Ka pasur disa përpjekje për të krijuar një kuadër sistematik për vlerësimin e teknologjive, të tilla si dhe , por më duket se kjo është një kompleksitet i tepruar.
Shumë teknologji mund të vlerësohen në mënyrë logjike duke i bërë vetëm dy pyetje kryesore. Problemi është në gjetjen e njerëzve që mund të përgjigjen me përgjegjësi ndaj tyre, duke shpenzuar kohë në gjetjen 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: Çfarë problemesh po përpiqem të zgjidh?
Nëse nuk përballeni me ndonjë problem, nuk keni nevojë për një mjet të ri. Pikë. Nuk ka nevojë të kërkoni një zgjidhje dhe atëherë të shpikni një problem. Nëse nuk keni hasur ndonjë problem që teknologjia e re zgjidh ndjeshëm më mirë se teknologjia juaj ekzistuese, atëherë nuk ka çfarë të diskutohet. Nëse po shqyrtoni mundësinë e përdorimit të kësaj teknologjie, sepse keni parë të tjerët që e përdorin atë, mendoni për problemet me të cilat ata përballen dhe pyesni nëse keni probleme të tilla. E lehtë është të pranosh teknologjinë sepse e përdorin të tjerët; vështirësia është në kuptimin se a po përballeni me të njëjtat probleme.
Pyetja 2: Çfarë po humbas?
Ky është, patjetër, një pyetje më e vështirë, sepse do t'ju duhet të hidhni një vështrim të thellë dhe të kuptoni mirë si teknologjinë e vjetër ashtu edhe atë të re. Ndonjëherë nuk mund ta kuptoni plotësisht të rejnë deri sa të ndërtoni diçka me të ose të keni një punonjës me përvojë në këtë fushë.
Nëse nuk keni asnjërën nga këto, 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 investimet, sa e lehtë do të jetë të anashkaloni vendimin?
Njerëzit gjithmonë e prishin gjithçka
Duke u përpjekur të përgjigjeni këtyre pyetjeve sa më objektivisht të jetë e mundur, mbani mend një gjë: do t'ju duhet të luftoni me natyrën njerëzore. Ekziston një grup i çrregullimeve kognitive që duhet të tejkaloni për të vlerësuar në mënyrë efektive teknologjinë. Ja disa prej tyre:
- — e gjithë bota e di për të, por gjithsesi është e vështirë të luftohet. Thjesht sigurohuni që teknologjia të përputhet me nevojat tuaja reale.
- — shumë zhvillues janë të prirur të nënvlerësojnë teknologjitë me të cilat janë duke punuar për një kohë të gjatë dhe të tepruar përfitimet e teknologjisë së re. Jo vetëm programuesit, të gjithë janë të ekspozuar ndaj këtij çrregullimi kognitiv.
- — jemi të prirur të shohim atë që kemi dhe ta injorojmë atë që mungon. Kjo mund të çojë në kaos në kombinim me efektin e novitetit, pasi jo vetëm që e nënvlerësoni teknologjinë e re, por edhe injoroni disavantazhet e saj..
Vlerësimi objektiv nuk jepet lehtësisht, por kuptimi i keqkuptimeve kognitive themelore ndihmon në marrjen e vendimeve më të arsyeshme.
CV
Kur shfaqet një inovacion, duhet t'u përgjigjemi dy pyetjeve me shumë kujdes:
- A zgjidh ky mjet një problem real?
- A e kuptojmë mirë kompromisin?
Nëse nuk jeni në gjendje të përgjigjeni me siguri në këto dy pyetje, bëni disa hapa mbrapa dhe mendoni.
Pra, ishte MongoDB një zgjedhje e duhur? Sigurisht që po; si në shumicën e teknologjive inxhinierike, kjo varet nga shumë faktorë. Mes atyre që iu përgjigjën këtyre dy pyetjeve, shumë përfituan nga MongoDB dhe vazhdojnë ta bëjnë këtë. Shpresoj që ata që nuk e bënë, morën një mësim të vlefshëm dhe jo shumë të dhimbshëm në lidhje me rrethin e hype-it.
Kërcënimi
Dua të sqaroj se nuk kam as dashuri as urrejtje për MongoDB. Thjesht nuk kishim probleme të tilla, për zgjidhjen e të cilave MongoDB do të ishte më e përshtatshme. E di se 10gen/MongoDB Inc. në fillim veproi shumë guximshëm, duke vendosur vlera të pasigurta si parazgjedhje dhe duke promovuar MongoDB kudo (sidomos në hackathon) si një zgjidhje universale për të punuar me çdo lloj të dhënash. Ndoshta kjo ishte një vendim i keq. Por konfirmon qasjen e përmendur këtu: këto probleme mund të ishin zbuluar shumë shpejt edhe me një vlerësim sipërfaqësor të teknologjisë.
Burimi: habr.com
