Hiljuti sain sellest teada Red Hat eemaldab satelliidilt MongoDB toe (nad ütlevad, et litsentsi muudatuste tõttu). See pani mind mõtlema, sest viimastel aastatel olen näinud palju artikleid selle kohta, kui kohutav on MongoDB ja kuidas keegi ei peaks seda kunagi kasutama. Kuid selle aja jooksul on MongoDB muutunud palju küpsemaks tooteks. Mis juhtus? Kas kogu vihkamine on tõesti tingitud vigadest uue DBMS-i varajases turustamises? Või kasutavad inimesed MongoDB-d lihtsalt valedes kohtades?

Kui teile tundub, et ma kaitsen MongoDB-d, lugege lahtiütlemine artikli lõpus.

Uus trend

Olen tarkvaratööstuses töötanud rohkem aastaid, kui oskan öelda, kuid siiski olen kokku puutunud vaid väikese osaga meie tööstust tabanud trendidest. Olen olnud tunnistajaks 4GL, AOP, Agile, SOA, Web 2.0, AJAX, Blockchaini tõusule... nimekiri on lõputu. Igal aastal ilmuvad uued trendid. Mõned kaovad kiiresti, teised muudavad tarkvara arendamise viisi põhjalikult.

Iga uus trend tekitab üldist elevust: inimesed kas hüppavad pardale või näevad teiste tekitatud müra ja järgivad rahvamassi. Selle protsessi on kodifitseerinud Gartner hype tsükkel. Kuigi see ajaskaala on vastuoluline, kirjeldab see ligikaudu seda, mis juhtub tehnoloogiatega enne, kui need lõpuks kasulikuks muutuvad.

Kuid aeg-ajalt ilmub mõni uus uuendus (või sellel on teine ​​tulemine, nagu antud juhul), mida juhib ainult üks konkreetne teostus. NoSQL-i puhul ajendas hüpet suurel määral MongoDB tekkimine ja meteoriline tõus. MongoDB seda suundumust ei käivitanud: tegelikult hakkasid suurtel Interneti-ettevõtetel olema probleeme suurte andmemahtude töötlemisega, mis tõi kaasa mitterelatsiooniliste andmebaaside tagastamise. Üldine liikumine algas sellistest projektidest nagu Google'i Bigtable ja Facebooki Cassandra, kuid MongoDB sai kõige tuntumaks ja ligipääsetavamaks NoSQL-i andmebaasi juurutamiseks, millele enamikul arendajatest oli juurdepääs.

Märkus. Võite arvata, et ma ajan segamini dokumendiandmebaase veergude andmebaaside, võtme-/väärtussalvedega või mis tahes arvukatest muudest andmesalve tüüpidest, mis kuuluvad NoSQL-i üldise definitsiooni alla. Ja sul on õigus. Kuid sel ajal valitses kaos. Kõik on NoSQL-ist kinnisideeks, sellest on saanud kõik absoluutselt vajalik, kuigi paljud ei näinud erinevate tehnoloogiate erinevusi. Paljude jaoks on MongoDB muutunud sünonüüm NoSQL.

Ja arendajad ründasid seda. Idee skeemita andmebaasist, mis maagiliselt mastaabib mis tahes probleemi lahendamiseks, oli üsna ahvatlev. 2014. aasta paiku tundus, et kõikjal, kus aasta tagasi kasutati relatsiooniandmebaase, nagu MySQL, Postgres või SQL Server, hakati juurutama MongoDB andmebaase. Küsimusele, miks, võis saada vastuse banaalsest “see on veebi mastaap” kuni läbimõelduma “minu andmed on väga lõdvalt struktureeritud ja sobivad hästi ilma skeemita andmebaasi”.

Oluline on meeles pidada, et MongoDB ja dokumendiandmebaasid üldiselt lahendavad traditsiooniliste relatsiooniandmebaasidega mitmeid probleeme:

• Range skeem: kui teil on dünaamiliselt genereeritud andmeid, peate relatsioonilise andmebaasi puhul looma hunniku juhuslikke "mitmesuguseid" andmeveerge, toppima sinna andmeplokke või kasutama konfiguratsiooni. EAV... kõigel sellel on olulisi puudusi.
• Skaleerimise raskused: Kui andmeid on nii palju, et need ei mahu ühte serverisse, pakkus MongoDB mehhanisme, mis võimaldavad sellel skaleerida mitmes masinas.
• Keerulised vooluahela modifikatsioonid: ei mingeid migratsioone! Relatsiooniandmebaasis võib andmebaasi struktuuri muutmine olla suur probleem (eriti kui andmeid on palju). MongoDB suutis protsessi oluliselt lihtsustada. Ja see tegi selle nii lihtsaks, et saate vooluringi lihtsalt uuendada ja väga kiiresti edasi liikuda.
• Esituse salvestamine: MongoDB jõudlus oli hea, eriti kui see oli õigesti seadistatud. Isegi MongoDB kasutusvalmis konfiguratsioon, mille pärast seda sageli kritiseeriti, näitas muljetavaldavaid jõudlusnumbreid.

Kõik riskid on teie enda kanda

MongoDB potentsiaalsed eelised olid tohutud, eriti teatud probleemide klasside puhul. Kui loete ülaltoodud loendit konteksti mõistmata ja kogemusteta, võib teile jääda mulje, et MongoDB on tõesti revolutsiooniline DBMS. Ainus probleem oli see, et ülaltoodud eelistega kaasnesid mitmed hoiatused, millest mõned on loetletud allpool.

Ausalt öeldes ei keegi ettevõttes 10gen/MongoDB Inc. ei ütle, et järgnev ei vasta tõele, need on lihtsalt kompromissid.

• Kaotatud tehingud: tehingud on paljude relatsiooniandmebaaside (mitte kõigi, aga enamiku) põhifunktsioon. Tehing tähendab, et saate teha mitu toimingut aatomipõhiselt ja tagada andmete järjepidevuse. Muidugi võib NoSQL-i andmebaasi puhul tehingulisus olla ühe dokumendi piires või tehingusemantika saamiseks võite kasutada kahefaasilisi piiranguid. Kuid selle funktsiooni peate ise juurutama... mis võib olla keeruline ja aeganõudev ülesanne. Sageli ei saa te probleemi olemasolust aru enne, kui näete, et andmebaasis olevad andmed jõuavad kehtetutesse olekutesse, kuna toimingute tuumalisust ei saa garanteerida. Märkus. Paljud inimesed ütlesid mulle, et MongoDB 4.0 tutvustas eelmisel aastal tehinguid, kuid teatud piirangutega. Artikli sisu jääb samaks: hinnake, kui hästi tehnoloogia teie vajadustele vastab.
• Relatsiooni terviklikkuse kaotus (võõrvõtmed): kui teie andmetel on seoseid, peate need rakenduses rakendama. Neid suhteid austava andmebaasi olemasolu võtab rakenduselt ja seega ka teie programmeerijatelt palju tööd.
• Andmestruktuuri rakendamise oskuse puudumine: Ranged skeemid võivad mõnikord olla suureks probleemiks, kuid need on ka võimas mehhanism hea andmete struktureerimiseks, kui seda kasutatakse targalt. Dokumendiandmebaasid, nagu MongoDB, pakuvad uskumatut skeemipaindlikkust, kuid see paindlikkus eemaldab vastutuse andmete puhtana hoidmise eest. Kui te nende eest ei hoolitse, kirjutate lõpuks oma rakendusse palju koodi, et võtta arvesse andmeid, mida ei ole salvestatud soovitud kujul. Nagu me oma ettevõttes Simple Thread sageli ütleme... kunagi kirjutatakse rakendus ümber, aga andmed jäävad igaveseks elama. Märkus. MongoDB toetab skeemi kontrollimist: see on kasulik, kuid ei anna samu garantiisid kui relatsiooniandmebaasis. Esiteks ei mõjuta skeemikontrolli lisamine või muutmine kogus olemasolevaid andmeid. Teie ülesanne on tagada andmete värskendamine uue skeemi järgi. Otsustage ise, kas see on teie vajaduste jaoks piisav.
• Päringu emakeel / tööriista ökosüsteemi kadumine: SQL-i tulek oli absoluutne revolutsioon ja sellest ajast pole midagi muutunud. See on uskumatult võimas keel, kuid samas ka üsna keeruline. SQL-iga töötamise kogemusega inimesed peavad vajadust koostada andmebaasipäringuid uues JSON-i fragmentidest koosnevas keeles. SQL-andmebaasidega suhtlemiseks on olemas terve universum tööriistu, alates IDE-dest kuni aruandlustööriistadeni. SQL-i mittetoetavasse andmebaasi liikumine tähendab, et te ei saa enamikku neist tööriistadest kasutada või peate nende kasutamiseks andmed SQL-i tõlkima, mis võib olla keerulisem, kui arvate.

Paljud arendajad, kes pöördusid MongoDB poole, ei mõistnud tegelikult kompromisse ja sukeldusid sageli pea ees sellesse, et see oma peamise andmehoidlana installida. Pärast seda oli sageli uskumatult raske tagasi tulla.

Mida oleks saanud teisiti teha?

Kõik ei hüpanud pea ees ja ei löönud põhja. Kuid paljud projektid on installinud MongoDB kohtadesse, kuhu see lihtsalt ei sobinud – ja nad peavad sellega elama veel palju aastaid. Kui need organisatsioonid oleksid veidi aega kulutanud ja oma tehnoloogiavalikuid metoodiliselt läbi mõelnud, oleksid paljud teinud teistsuguseid valikuid.

Kuidas valida õiget tehnoloogiat? Tehnoloogia hindamiseks on tehtud mitmeid katseid luua süstemaatilist raamistikku, nt "Raamistik tehnoloogiate juurutamiseks tarkvaraorganisatsioonides" и "Tarkvaratehnoloogiate hindamise raamistik", kuid mulle tundub, et see on tarbetu keerukus.

Paljusid tehnoloogiaid saab arukalt hinnata, esitades vaid kaks põhiküsimust. Probleem seisneb inimeste leidmises, kes suudavad neile vastutustundlikult vastata, võttes vastuste leidmiseks aega ja ilma erapoolikusteta.

Kui teil pole probleeme, pole teil uut tööriista vaja. Punkt.

1. küsimus: milliseid probleeme ma püüan lahendada?

Kui teil pole probleeme, pole teil uut tööriista vaja. Punkt. Pole vaja otsida lahendust ja seejärel leiutada probleemi. Kui te pole kokku puutunud probleemiga, mille uus tehnoloogia lahendab oluliselt paremini kui teie olemasolev tehnoloogia, pole siin midagi arutada. Kui kaalute selle tehnoloogia kasutamist, kuna olete näinud, kuidas teised seda kasutavad, mõelge nende probleemidele ja küsige, kas teil on neid probleeme. Tehnoloogiat on lihtne aktsepteerida, sest teised kasutavad seda, väljakutse on mõista, kas teil on samad probleemid.

2. küsimus: millest ma ilma olen jäänud?

See on kindlasti keerulisem küsimus, sest peate süvenema ja hästi aru saama nii vanast kui ka uuest tehnoloogiast. Mõnikord ei saa te uuest päriselt aru enne, kui olete sellega midagi ehitanud või kellelgi on see kogemus.

Kui teil pole kumbagi, on selle instrumendi väärtuse määramiseks mõttekas mõelda minimaalsele võimalikule investeeringule. Ja kui olete investeeringu teinud, siis kui raske on otsust tagasi pöörata?

Inimesed rikuvad alati kõik ära

Kui proovite neile küsimustele võimalikult erapooletult vastata, pidage meeles üht: peate võitlema inimloomuse vastu. Tehnoloogia tõhusaks hindamiseks tuleb ületada mitmeid kognitiivseid eelarvamusi. Siin on vaid mõned:

• Enamusega liitumise mõju - kõik teavad temast, kuid temaga on endiselt raske võidelda. Lihtsalt veenduge, et tehnoloogia vastaks teie tegelikele vajadustele.
• Uudsuse efekt — Paljud arendajad kipuvad alahindama tehnoloogiaid, millega nad on pikka aega töötanud, ja ülehindavad uue tehnoloogia eeliseid. See ei ole ainult programmeerijad, kõik on selle kognitiivse eelarvamuse suhtes vastuvõtlikud.
• Positiivsete omaduste mõju - Me kipume nägema, mis seal on, ja kaotame silmist selle, mis on puudu. See võib koos uudsuse efektiga kaasa tuua kaose, kuna te mitte ainult ei hinda uut tehnoloogiat loomupäraselt üle, vaid eirate ka selle puudusi.

Objektiivne hindamine ei ole lihtne, kuid kognitiivsete eelarvamuste mõistmine aitab teil teha ratsionaalsemaid otsuseid.

Kokkuvõte

Uuenduse ilmnemisel tuleb väga hoolikalt vastata kahele küsimusele:

• Kas see tööriist lahendab tõelise probleemi?
• Kas me mõistame kompromisse hästi?

Kui te ei suuda neile kahele küsimusele enesekindlalt vastata, astuge paar sammu tagasi ja mõelge.

Kas MongoDB oli isegi õige valik? Muidugi jah; Nagu enamiku inseneritehnoloogiate puhul, sõltub see paljudest teguritest. Nende hulgas, kes neile kahele küsimusele vastasid, on MongoDB-st kasu saanud ja teevad seda ka edaspidi. Neile, kes seda ei teinud, loodan, et said väärtusliku ja mitte liiga valusa õppetunni hüpetsüklist läbi liikumise kohta.

Vastutusest loobumine

Tahan selgitada, et mul ei ole MongoDB-ga ei armastus- ega vihkamissuhet. Meil pole lihtsalt olnud selliseid probleeme, mille lahendamiseks MongoDB kõige paremini sobiks. Ma tean, et 10gen/MongoDB Inc. oli alguses väga julge, määrates ebaturvalised vaikeseaded ja reklaamides MongoDB-d kõikjal (eriti häkatonidel) kui universaalset lahendust mis tahes andmetega töötamiseks. See oli ilmselt halb otsus. Kuid see kinnitab siin kirjeldatud lähenemist: neid probleeme saab väga kiiresti avastada isegi tehnoloogia pealiskaudsel hindamisel.

Allikas: www.habr.com