Hiljuti sain teada, et Red Hat eemaldab MongoDB toe Satellite'ist (öeldakse, et litsentsimuudatuste tõttu). See pani mind mõtlema, et viimastel aastatel olen näinud hulgaliselt artikleid selle kohta, kui kohutav on MongoDB ja et keegi ei tohiks seda kunagi kasutada. Kuid selle aja jooksul on MongoDB muutunud palju küpsemaks tooteks. Mis siis juhtus? Kas kogu see viha on tõesti seotud varajaste turundusvigadega? Või kasutavad inimesed MongoDB-d lihtsalt valedes kohtades?

Kui teil tundub, et ma kaitsen MongoDB-d, lugege palun eemaldatud artikli lõpus.

Uus suundumus

Olen töötanud tarkvaraarenduse valdkonnas kauem, kui on viisakas rääkida, kuid selle aja jooksul on mind tabanud vaid väike osa meie valdkonda mõjutanud suundumustest. Olen olnud tunnistajaks 4GL, AOP, Agile, SOA, Web 2.0, AJAX, blokchaini... loetelu on lõputu. Iga aasta tulevad välja uued suundumused. Osa neist hajub kiiresti, samas kui teised muudavad oluliselt tarkvaraarenduse viise.

Iga uue suundumuse ümber tekib mingi üldine elevus: inimesed kas hüppavad ise paati või näevad teistelt tekkinud müra ja järgivad rahvamassi. Seda protsessi kodeeris ettevõte Gartner hype'i tsüklis. Kuigi see on vaieldav, kirjeldab see graafik umbes seda, mis igasugustega tehnoloogiatega juhtub, enne kui need saavad lõpuks kasutamiseks kasulikuks.

Kuid aeg-ajalt ilmub (või toimub teine tulemine, nagu sel juhul) uus innovatsioon, mille motiveerib ainult üks konkreetne rakendus. NoSQL hype'it määratses tugevalt MongoDB kiire tõus. Mitte MongoDB alustas seda trendi: tegelikult tekkisid suurtes internetifirmades probleemid suurte andmemahtude töötlemisega, mis tõi tagasi mitte-relatsioonilised andmebaasid. Üldine liikumine algas selliste projektidega nagu Google'i Bigtable ja Facebooki Cassandra, kuid just MongoDB-st sai kõige tuntum ja kergemini ligipääsetav NoSQL andmebaasi rakendus, millega enamik arendajatest sai töötada.

Märkus: võite mõelda, et segan dokumentide andmebaase veergude andmebaaside, võtme-väärtuse ladude või paljude teiste andmelaod tüüpiliste NoSQL määratlemise alla. Ja teil on õigus. Kuid toona valitses segadus. Kõik oli NoSQL-i fännid ja see muutus absoluutseks on vajalik, kuigi paljud ei ole tehnoloogiate vahel erinevusi näinud. Paljudele on MongoDB saanud sünonüümiks NoSQL-ile.

Ja arendajad ründasid seda. Idee skeemivabast andmebaasist, mis maagiliselt skaleerub kõikide probleemide lahendamiseks, oli piisavalt ahvatlev. Umbes 2014. aastal näis, et igas kohas, kus veel aasta tagasi kasutati relatsioonilist andmebaasi, nagu MySQL, Postgres või SQL Server, hakati kasutama MongoDB-sid. Küsimusele miks, võisite saada vastuse alates lihtsast „see on veebiskaal” kuni läbimõelduma „mu andmed on väga halvasti struktureeritud ja sobivad hästi skeemivabasse andmebaasi”.

Oluline on meeles pidada, et MongoDB ja dokumendipõhised andmebaasid lahendavad teatud probleeme traditsiooniliste relatsiooniliste andmebaasidega:

• Range skeem: relatsioonilise andmebaasi puhul, kui teil on dünaamiliselt loodud andmed, peate kas looma hulga juhuslikke "erinevaid" andmesambasid, pressima sinna andmepunkte või kasutama konfiguratsiooni EAV... kõikidel sellel on olulised puudused.
• Skaalamisvaev: kui andmeid on nii palju, et need ei mahu ühele serverile, pakkus MongoDB mehhanisme, mis võimaldasid neid skaleerida mitmele masinale.
• Skeemi keerulised muutused: mingeid migreerimisi! Relatsioonilises andmebaasis andmebaasi struktuuri muutmine võib olla suur probleem (eriti kui andmeid on tõeliselt palju). MongoDB suutis protsessi oluliselt lihtsustada. Ja tegi selle nii lihtsaks, et saate lihtsalt skeemi jooksvalt uuendada ja väga kiiresti edasi minna.
• Kirjutamisvõimekus: MongoDB jõudlus oli hea, eriti korraliku seadistuse korral. I even MongoDB out-of-the-box configuration, for which it was often criticized, demonstrated some impressive performance metrics.

Kõik riskid on teie peal.

MongoDB potentsiaalsed eelised olid tohutud, eriti teatud probleemide klasside jaoks. Kui lugeda ülaltoodud loetelu ilma konteksti mõistmata ja kogemusteta, võib tekkida mulje, et MongoDB on tõeliselt revolutsiooniline andme­baasi­haldus­süsteem. Ainus probleem oli see, et eespool nimetatud eelised kaasnesid hulga märgustega, millest mõned on allpool toodud.

Aus õigusemõistmise nimel, keegi 10gen/MongoDB Inc.-is ei ütle, et alljärgnev pole tõsi, need on lihtsalt kompromissid.

• Tehingute kaotus: tehingud on paljude relatsiooniliste andmebaaside (mitte kõikide, kuid enamik) põhijoon. Tehingulisus tähendab, et saate teostada mitu operatsiooni aatomaaridena ja võite tagada, et andmed jäävad kooskõlla. Loomulikult võib NoSQL andmebaasis tehingulisus olla ühe dokumendi piires või võite kasutada kahefaasilisi kinnitusi, et saavutada tehinguline semantika. Kuid peate selle funktsionaalsuse ise rakendama... mis võib olla keeruline ja aeganõudev ülesanne. Sageli ei teadvusta te probleeme enne kui näete, et andmed andmebaasis satuvad lubamatutesse olekutesse, sest operatsioonide aatomaarset tagamist ei saa garanteerida. Märkus: paljud on mulle teatanud, et eelmisel aastal ilmus MongoDB 4.0-s tehingud, kuid mitmete piirangutega. Artikli järeldus jääb endiseks: hindage, kui hästi tehnoloogia vastab teie vajadustele.
• Relatsiooni terviklikkuse kaotus (välishiid): kui teie andmetes on suhted, peate neid rakenduses rakendama. Sukeldumine andmebaasi, mis järgib neid suhteid, vähendab märkimisväärselt töökoormust rakendusel ja seega ka teie arendajatele.
• Andmestruktuuri rakendamise puudumine: ranged skeemid võivad mõnikord osutuda suureks probleemiks, kuid need on ka võimas mehhanism andmete korralikuks struktureerimiseks, kui neid õigesti kasutada. Dokumentide andmebaasid, nagu MongoDB, pakuvad uskumatut skeemi paindlikkust, kuid see paindlikkus vabastab vastutuse andmete säilitamise eest korralikult. Kui te nende eest ei hooli, peate lõpuks rakenduses kirjutama palju koodi, et arvestada andmetega, mis on salvestatud teie ootustele mittevastavas vormis. Nagu meie ettevõttes Simple Thread sageli öeldakse… rakendus kirjutatakse kunagi ümber, kuid andmed elavad igavesti. Märkus: MongoDB toetab skeemide kontrollimist: see on kasulik, kuid ei paku samu garantiisid kui relationaalne andmebaas. Esiteks, skeemide kontrollimise lisamine või muutmine ei mõjuta olemasolevaid andmeid kogus. Te peaksite ise veenduma, et värskendate andmeid vastavalt uuele skeemile. Otsustage ise, kas see on teie vajaduste jaoks piisav.
• Omandatud päringukeel / ökosüsteemi tööriistade kaotus: SQL-i ilmumine oli absoluutne revolution, ning sellest ajast alates ei ole midagi muutunud. See on uskumatult võimas keel, kuid ka üsna keeruline. Tehniliselt on uusi päringute koostamine andmebaasi uue keele abil, mis koosneb JSON-i fragmentidest, inimestele, kellel on SQL-i kogemus, suur tagasilangemine. SQL-andmebaasidega töötamiseks on terve universum tööriistu: alates IDE-dest kuni aruandlustööriistadeni. Andmebaasi üleminek, mis ei toeta SQL-i, tähendab, et te ei saa kasutada enamikku neist tööriistadest või peate oma andmed SQL-i viima, et neid kasutada, ja see võib osutuda keerulisemaks, kui arvate.

Paljud arendajad, kes pöördusid MongoDB poole, ei mõistnud väga hästi kompromisse ja sageli hüppasid nad pea ees sisse, seadistades selle peamiseks andmesalvestuseks. Pärast seda oli sageli uskumatult keeruline tagasi tulla.

Mida oleks saanud teisiti teha?

Kõik ei hüpanud peadpidi ning ei paisanud end põhja. Kuid paljusid projekte seadistati MongoDB-se, kuhu see lihtsalt ei sobinud - ja nad peavad sellega veel palju aastaid elama. Kui need organisatsioonid oleksid veetnud natuke aega ja mõelnud süsteemselt tehnoloogia valikule, oleks paljud teinud teistsuguse valiku.

Kuidas valida sobiv tehnoloogia? Oli mitmeid katse, et luua süsteemne raamistik tehnoloogiate hindamiseks, nagu „Raamistik tehnoloogiate rakendamiseks tarkvarorganisatsioonides“ ja „Raamistik tarkvaratehnoloogiate hindamiseks“, kuid mulle tundub, et see on ülemäärane keerukus.

Paljusid tehnoloogiaid saab mõistlikult hinnata, esitamata vaid kahte peamist küsimust. Probleem seisneb selles, et leida inimesi, kes saavad vastutustundlikult vastata, kulutades aega vastuste leidmiseks ja ilma eelarvamusteta.

Kui te ei seisate silmitsi mingi probleemiga, ei vajate uut tööriista. Punkt.

Küsimus 1: Milliseid probleeme ma püüan lahendada?

Kui te ei kohta mingit probleemi, ei vaja te uut tööriista. Lõpp. Pole mõtet otsida lahendust ja seejärel välja mõelda probleem. Kui te ei ole silmitsi probleemiga, mille uus tehnoloogia lahendab oluliselt paremini kui teie olemasolev tehnoloogia, siis siin pole midagi arutada. Kui kaalute selle tehnoloogia kasutuselevõttu, kuna olete näinud, kuidas teised seda kasutavad, siis mõelge, milliste probleemidega nad silmitsi seisavad, ja küsige endalt, kas teil on sarnaseid probleeme. On lihtne omaks võtta tehnoloogiat, kuna teised seda kasutavad, kuid raskus seisneb selles, et mõista, kas olete silmitsi samade probleemidega.

Küsimus 2: Millest ma loobun?

See on kindlasti raskem küsimus, sest tuleb süveneda ja hästi mõista nii vana kui ka uut tehnoloogiat. Mõnikord ei saa te uut tõeliselt mõista, kuni ei ehita midagi selle abil või kuni teil ei ole töötajat, kellel on selline kogemus.

Kui teil ei ole ei ühtegi ega teist, siis on mõistlik mõelda minimaalsetele investeeringutele, et kindlaks teha selle tööriista väärtus. Ja kui teete investeeringud, kui raske on otsus tagasi võtta?

Inimesed rikuvad alati kõik ära

Püüdes nendel küsimustele vastata võimalikult objektiivselt, pidage meeles ühte asja: peate võitlema inimloomusega. On mitmeid kognitiivseid väärarusaamu, millele tuleb üle saada, et tehnoloogiat tõhusalt hinnata. Siin on vaid mõned:

• Müügipooluse effekt — kõik teavad sellest, kuid sellega on ikkagi raske võidelda. Veenduge, et tehnoloogia rahuldab teie tegelikke vajadusi.
• Uudsuse effekt — paljud arendajad kipuvad alahindama tehnoloogiaid, millega nad on pikka aega töötanud, ja ülehindama uue tehnoloogia eeliseid. Mitte ainult programmeerijad, vaid kõik on sellele kognitiivsele väärarusaamale vastuvõtlikud.
• Positiivsete omaduste effekt — me kipume nägema seda, mis on olemas, ja unustame, mis puudub. See võib koos uudsuse effektiga viia segadusse, kuna te mitte ainult ei alahinda uut tehnoloogiat, vaid ignoreerite ka selle puudusi..

Objektiivne hinnang pole kerge, kuid peamiste kognitiivsete väärarusaamade mõistmine aitab teha ratsionaalsemaid otsuseid.

Elulookirjeldus

Kui ilmub mingi uuendus, tuleb väga ettevaatlikult vastata kahele küsimusele:

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

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

Kas MongoDB oli tõepoolest õige valik? Loomulikult jah; nagu paljude inseneritehnoloogiate puhul, sõltub see paljuski erinevatest teguritest. Paljude seas, kes vastasid neile kahele küsimusele, on mitmed saanud MongoDB-st kasu ja saavad seda endiselt. Loodetavasti need, kes ei saanud, õppisid väärtusliku ja mitte liiga valusa õppetunni hüppe tsükli käigus.

Märkus

Tahan selgitada, et ma ei tunne ei armastust ega vihkamist MongoDB vastu. Lihtsalt meil polnud selliseid probleeme, mille jaoks MongoDB oleks parim lahendus. Tean, et 10gen/MongoDB Inc. tegutses alguses väga julgesti, seades ebaturvalised vaikeväärtused ja edendades MongoDB-d igal pool (eriti hackathon'idelt) universaalse lahendusena kõigi andmete töötlemiseks. See oli ilmselt vale otsus. Kuid see kinnitab siin kirjeldatud lähenemist: neid probleeme oleks saanud tuvastada väga kiiresti isegi pindmise tehnoloogia hindamise korral.

Allikas: habr.com