Hiljuti sain teada, et (öeldakse, et see on tingitud litsentsimuudatustest). See pani mind mõtlema, et viimase paarikümne aasta jooksul olen ma näinud palju artikleid, kuidas MongoDB on kohutav ja et keegi ei peaks seda kunagi kasutama. Kuid selle aja jooksul on MongoDB saanud palju küpsemaks tooteks. Mis siis juhtus? Kas kogu see vihkamine on tingitud algsetest turundusvigadest uue andmebaasi süsteemi puhul? Või kasutavad inimesed lihtsalt MongoDB-d valedes kohtades?
Kui teil tekib tunne, et ma kaitsen MongoDB-d, palun lugege artikli lõpus.
Uus trend
Olen töötanud tarkvaratööstuses rohkem aastaid, kui väärikas oleks rääkida, kuid ometigi on mulle jäänud vaid väike osa suundumustest, mis on meie valdkonda tabanud. Olen olnud tunnistajaks 4GL, AOP, Agile, SOA, Web 2.0, AJAX, plokiahela… nimekiri on lõputu. Iga aasta ilmuvad uued suundumused. Mõned kustuvad kiiresti, samas kui teised muudavad oluliselt tarkvaraarenduse viise.
Iga uus suund tekitab teatavat üldist elevust: inimesed kas hüppavad ise paati või näevad teiste genereeritud müra – ja järgivad rahvahulka. Seda protsessi on koodifitseerinud ettevõte Gartner . Kuigi see on vaieldav, kirjeldab see diagramm umbkaudu, mis juhtub tehnoloogiatega enne, kui need lõpuks kasulikuks osutuvad.
Kuid aeg-ajalt ilmub (või toimub teise tulek, nagu käesoleval juhul) uus innovatsioon, mida juhib vaid üks konkreetne rakendus. NoSQL puhul oli hüpe tugevalt seotud MongoDB kiire tõusuga. MongoDB ei käivitanud seda trendi: tegelikult tekkisid suurtes internetiettevõtetes probleemid suurte andmemahtude töötlemisel, mis tõid tagasi mitte-relationaalsed andmebaasid. Üksikprojektid, nagu Google'i Bigtable ja Facebooki Cassandra, käivitasid üldise liikumise, kuid just MongoDBst sai kõige kuulsam ja kergesti ligipääsetav NoSQL andmebaasi rakendus, millele enamik arendajatest ligi pääses.
Märkus: võite arvata, et segan dokumendibaase veergude ja võtme/väärtuse andmebaasidega või mis tahes muude andmete salvestamise tüüpidega, mis kuuluvad laiemasse NoSQL määratlemisse. Ja te olete õigus. Aga sel ajal valitses kaos. Kõik olid NoSQL'i peal. See oli absoluutne vaja, kuigi paljud ei näinud erinevusi erinevate tehnoloogiate vahel. Paljude jaoks sai MongoDB sümboliks NoSQL-ile. Ja arendajad langesid selle kallale. Idee skeemivabast andmebaasist, mis imekombel skaleerub, et lahendada kõiki probleeme, oli küllaltki ahvatlev. Aastal 2014 tundus, et igal pool, kus veel aasta tagasi kasutati relatsioonilisi andmebaase nagu MySQL, Postgres või SQL Server, hakati käivitama MongoDB andmebaase. Küsimusele, miks, võisite saada vastuseks alates jamast „see on veebiskaleerimine” kuni arvestatava „minu andmed on väga halvasti struktureeritud ja sobivad hästi skeemivabasse andmebaasi”.
Ja arendajad haarasid selle järele. Idee skeemivabast andmebaasist, mis maagiliselt skaleerub, et lahendada igasuguseid probleeme, on olnud üsna ahvatlev. Umbes 2014. aastal tundus, et igas kohas, kus veel aasta tagasi kasutati relatsioonilist andmebaasi nagu MySQL, Postgres või SQL Server, hakati juurutama MongoDB andmebaase. Küsimusele, miks, võisite saada vastuseks tobeda "see on veebiskaleerimine" kuni tõsisema "minu andmed on väga nõrgalt struktureeritud ja sobivad hästi skeemivabasse andmebaasi."
Oluline on meeles pidada, et MongoDB ja dokumendibaasid üldiselt lahendavad mitmeid traditsiooniliste relatsiooniliste andmebaaside probleemidega:
- Range skeem: relatsioonilise andmebaasiga, kui teil on dünaamiliselt genereeritud andmed, peate kas looma hulga juhuslikke "erinevaid" andmeveerge, sisestama sinna andmeblobe või kasutama konfiguratsiooni … kõigil neil on märkimisväärsed puudused.
- Skaalautumisraskused: kui andmeid on nii palju, et need ei mahu ühele serverile, pakkus MongoDB mehhanisme nende jagamiseks mitmele masinale.
- Kompikatsioonid skeemi muutmisel: mingit migreerimist! Suhtelises andmebaasis võib andmebaasi struktuuri muutmine osutuda tohutuks probleemiks (eriti siis, kui andmeid on palju). MongoDB suutis seda protsessi oluliselt lihtsustada. See tegi selle nii lihtsaks, et saate lihtsalt skeemi jooksvalt värskendada ja kiiresti edasi liikuda.
- Kirjutamise tulemuslikkus: MongoDB tulemuslikkus oli hea, eriti hea seadistuse puhul. Isegi MongoDB konfigureerimine kastist välja, mille üle sageli kritiseeriti, näitas mõningaid muljetavaldavaid tulemuslikkuse näitajaid.
Kõik riskid on teie õlul
MongoDB potentsiaalsed eelised olid tohutad, eriti teatud probleemiklasside jaoks. Kui lugeda ülaltoodud nimekirja ilma konteksti mõistmata ja ilma kogemusteta, võib jääda mulje, et MongoDB on tõeliselt revolutsiooniline andmebaasi haldustarkvara. Ainuke probleem oli see, et eespool loetletud eelised tulid koos mitmete tingimustega, millest mõned on loetletud allpool.
Õiguse säilitamiseks ei ütle keegi 10gen/MongoDB Inc.-st, et allpool toodud pole tõsi, need on lihtsalt kompromissid.
- Tehingute kaotus: tehingud on paljude relatsiooniliste andmebaaside (mitte kõigi, aga enamiku) peamine omadus. Tehingulikkus tähendab, et saate teostada mitu toimingut aatomiliselt ja tagada, et andmed jäävad järjepidevaks. Loomulikult võib NoSQL andmebaasis tehingulikkus olla ühe dokumendi ulatuses või võite kasutada kahemõttelisi komiteesid, et saavutada tehinguliste semantika. Kuid peate selle funktsionaalsuse ise rakendama... mis võib olla keeruline ja aeganõudev ülesanne. Tihti te ei teadvusta probleemide olemasolu enne, kui näete, et andmed andmebaasis satuvad kehtetuks, sest aatomilisuse tagamine ei ole võimalik. Märkus: paljud on mulle teadnud, et eelmisel aastal ilmus MongoDB 4.0-s tehingud, kuid mitmete piirangutega. Artikli järeldus jääb samaks: hindage, kui hästi tehnoloogia teie vajadustega kokku läheb.
- Relatsioonilise terviklikkuse (välised võtmed) kaotus: kui teie andmetes on seoseid, peate neid rakenduses rakendama. Andmebaasi olemasolu, mis järgib neid seoseid, vähendab oluliselt rakenduse ja seega ka teie programmeerijate töömahtu.
- Andmestruktuuri rakendamise võimaluse puudumine: ranged skeemid võivad mõnikord olla suur probleem, kuid need on ka võimas mehanism andmete korralikuks struktureerimiseks, kui neid õigesti kasutada. Dokumendipõhised andmebaasid, nagu MongoDB, pakuvad uskumatut skeemide paindlikkust, kuid see paindlikkus vabastab vastutuse andmete puhtuse säilitamise eest. Kui te nende eest ei hoolitse, peate lõpuks rakenduses kirjutama palju koodi, et arvestada andmeid, mis ei ole hoitud oodatud kujul. Kuidas me meie ettevõttes Simple Thread sageli ütleme... rakendust kirjutatakse kunagi uuesti, kuid andmed elavad igavesti. Märkus: MongoDB toetab skeemide valideerimist: see on kasulik, kuid ei paku samu garanteerimisi kui relatsioonilised andmebaasid. Esiteks, skeemi valideerimise lisamine või muutmine ei mõjuta olemasolevaid andmeid kollektsioonis. Peate ise veenduma, et uuendate andmeid vastavalt uuele skeemile. Otsustage ise, kas see on teie vajaduste rahuldamiseks piisav.
- Kohandatud päringukeel / ökosüsteemi tööriistade kadumine: SQL-i ilmumine oli absoluutne revolutsioon ning sellest ajast alates pole midagi muutunud. See on uskumatu võimas keel, kuid ka üsna keeruline. Uue keele, mis koosneb JSON-i fragmentidest, abil andmebaaside päringute koostamise vajadust peetakse suureks sammuks tagasi neile, kellel on kogemusi SQL-iga. SQL-andmebaasidega suhtlemiseks on terve universum tööriistu: alates IDE-dest kuni aruandlustööriistadeni. Andmebaasile üleminek, mis ei toeta SQL-i, tähendab, et te ei saa kasutada enamikku neist tööriistadest või peate andmed SQL-i edastama, et neid kasutada, mis võib osutuda keerulisemaks, kui arvate.
Paljud arendajad, kes pöördusid MongoDB poole, ei mõistnud väga kompromisse ja tihti hüppasid nad pea ees, seadistades selle oma peamiseks andmehoidmiseks. Pärast seda oli sageli äärmiselt keeruline tagasi minna.
Mida oleks saanud teisiti teha?
Kõik ei hüpanud pea ees ja ei lõiganud põhja. Kuid mitmed projektid paigaldasid MongoDB sinna, kuhu see lihtsalt ei sobinud — ja nad peavad elama selle kaaslasega veel palju aastaid. Kui need organisatsioonid oleksid kulutanud veidi aega ja mõelnud süsteemselt tehnoloogiate valikule, oleks paljud teinud teistsuguse valiku.
Kuidas valida sobiv tehnoloogia? Oli mitmeid katseid luua süsteemne raamistik tehnoloogiate hindamiseks, näiteks ja , kuid mulle tundub, et see on liiga keeruline.
Paljusid tehnoloogiaid saab mõistlikult hinnata, esitades vaid kaks peamist küsimust. Probleem seisneb inimeste leidmises, kes suudavad vastutada nendele küsimustele vastamise eest, pühendades aega vastuste leidmisele ja ilma eelarvamusteta.
Kui te ei pruugi silmitsi seista mingi probleemiga, siis ei vajata uut tööriista. Punkt.
Küsimus 1: Milliseid probleeme ma üritan lahendada?
Kui te ei seisa silmitsi mingi probleemiga, siis ei vajata uut tööriista. Punkt. Pole vaja otsida lahendust ja seejärel probleem leiutada. Kui te ei ole silmitsi probleemiga, mida uus tehnoloogia ei lahenda märkimisväärselt paremini kui teie olemasolev tehnoloogia, siis pole siin midagi arutada. Kui te kaalute selle tehnoloogia kasutuselevõttu, kuna olete näinud, kuidas teised seda kasutavad, mõelge, milliste probleemidega nad silmitsi seisavad, ja küsige, kas teil on selliseid probleeme. Tehnoloogia omaksvõtt on lihtne, kuid keeruliseks muutub küsimus, kas seisate silmitsi samade probleemidega.
Küsimus 2: Millest ma ilma jään?
See on kindlasti keerulisem küsimus, sest peate süübima ja hästi mõistma nii vana kui ka uut tehnoloogiat. Mõnikord ei saa te tegelikult uut mõista, kuni ei ole ehitanud midagi selle abil või kuni teil ei ole töötajat, kellel on selline kogemus.
Kui teil ei ole ei seda, ega teist, siis tasub mõelda minimaalsetele investeeringutele, et hinnata selle tööriista väärtust. Ja kui teete investeeringu, kui keeruline on otsust tühistada?
Inimesed rikuvad alati asju
Püüdke vastata nendele küsimustele võimalikult erapooletult, pidage meeles ühte asja: peate võitlema inimloomusega. On mitmeid kognitiivseid moonutusi, millele peate üle saama, et tõhusalt hinnata tehnoloogiat. Siin on mõned:
- — kõik teavad sellest, kuid sellega on ikkagi raske võidelda. Lihtsalt veenduge, et tehnoloogia vastab tõeliselt teie vajadustele.
- — paljud arendajad on altid alahindama tehnoloogiaid, millega nad on pikka aega töötanud, ja ülehindama uue tehnoloogia eeliseid. Mitte ainult programmeerijad, kõik on sellele kognitiivsele moonutusele vastuvõtlikud.
- — me kaldame nägema seda, mis on olemas, ja jätame tähelepanuta selle, mis puudub. See võib põhjustada segadust, kui uudsuse efekt, kuna te mitte ainult ei alahinda uut tehnoloogiat, vaid ignoreerite ka selle puudusi..
Objektiivset hinnangut on keeruline anda, kuid põhiteadmised kognitiivsetest moonutustest aitavad teha mõistlikumaid otsuseid.
Kokkuvõte
Kui ilmub mõni innovatsioon, tuleb väga ettevaatlikult vastata kahele küsimusele:
- Kas see tööriist lahendab tõelise probleemi?
- Kas me mõistame kompromisse piisavalt hästi?
Kui te ei suuda nendele kahele küsimusele kindlalt vastata, astuge paar sammu tagasi ja mõelge.
Kas MongoDB oli tegelikult õige valik? Muidugi, jah; nagu paljude inseneritehnoloogiate puhul, sõltub see paljuski paljusest. Neid, kes vastasid nendele kahele küsimusele, on palju, kellel on MongoDB-st kasu ja kes saavad seda jätkuvalt. Loodan, et need, kes seda ei teinud, on saanud väärtusliku ja mitte liiga valusa õppetunni hübriiditsükli kaudu.
Vastutusest loobumine
Tahan selgitada, et mul ei ole MongoDB suhtes ei armastust ega vihkamist. Lihtsalt meil ei ole olnud mingeid probleeme, mille lahendamiseks MongoDB kõige paremini sobiks. Tean, et 10gen/MongoDB Inc. oli alguses väga julge, seades ebaturvalisi vaikeväärtusi ja edendades MongoDB igal pool (eriti hackathonidel) kui universaalset lahendust igasuguste andmete töötlemiseks. Tõenäoliselt oli see halb otsus. Kuid see kinnitab siin kirjeldatud lähenemisviisi: neid probleeme oleks olnud väga lihtne avastada isegi tehnoloogia pinnapealsel hindamisel.
Allikas: habr.com
