Neseniai tai sužinojau (sakoma dėl licencijos pakeitimų). Tai privertė mane susimąstyti, nes per pastaruosius kelerius metus mačiau daugybę straipsnių apie tai, koks baisus yra MongoDB ir kaip niekas neturėtų jo naudoti. Tačiau per šį laiką MongoDB tapo daug brandesniu produktu. Kas nutiko? Ar visa neapykanta tikrai kyla dėl klaidų ankstyvoje naujosios DBVS rinkodaros metu? O gal žmonės tiesiog naudoja MongoDB netinkamose vietose?
Jei manote, kad aš ginu MongoDB, perskaitykite straipsnio pabaigoje.
Nauja tendencija
Aš dirbu programinės įrangos pramonėje daugiau metų, nei galiu pasakyti, bet vis tiek patyriau tik nedidelę dalį tendencijų, kurios paveikė mūsų pramonę. Esu liudininkas 4GL, AOP, Agile, SOA, Web 2.0, AJAX, Blockchain... sąrašas yra begalinis. Kiekvienais metais atsiranda naujų tendencijų. Kai kurios greitai išnyksta, o kitos iš esmės keičia programinės įrangos kūrimo būdą.
Kiekviena nauja tendencija sukuria bendrą jaudulį: žmonės arba įšoka į laivą, arba mato kitų keliamą triukšmą ir seka minią. Šį procesą užkodavo Gartner . Nors ir prieštaringai vertinama, ši laiko juosta apytiksliai apibūdina, kas nutinka technologijoms, kol jos galiausiai tampa naudingos.
Tačiau karts nuo karto atsiranda (arba turi antrą atėjimą, kaip šiuo atveju) nauja naujovė, kurią skatina tik vienas konkretus įgyvendinimas. „NoSQL“ atveju ažiotažą labai lėmė MongoDB atsiradimas ir didžiulis augimas. „MongoDB“ nepradėjo šios tendencijos: iš tikrųjų didelėms interneto įmonėms pradėjo kilti problemų apdorojant didelius duomenų kiekius, o tai paskatino sugrįžti nesusijusių duomenų bazių. Bendras judėjimas prasidėjo nuo tokių projektų kaip Google Bigtable ir Facebook Cassandra, tačiau būtent MongoDB tapo žinomiausiu ir prieinamiausiu NoSQL duomenų bazės diegimu, prie kurio turėjo prieigą dauguma kūrėjų.
Pastaba: galite manyti, kad aš painioju dokumentų duomenų bazes su stulpelių duomenų bazėmis, raktų / reikšmių saugyklomis arba bet kuria iš daugelio kitų tipų duomenų saugyklų, kurioms taikomas bendrasis NoSQL apibrėžimas. Ir tu teisus. Tačiau tuo metu viešpatavo chaosas. Visi yra apsėsti NoSQL, juo tapo visi visiškai būtina, nors daugelis neįžvelgė skirtingų technologijų skirtumų. Daugeliui MongoDB tapo sinonimas NoSQL.
Ir kūrėjai puolė į tai. Idėja apie beschemą duomenų bazę, kuri stebuklingai keičiasi, kad išspręstų bet kokią problemą, buvo gana viliojanti. Maždaug 2014 m. atrodė, kad visur, kur prieš metus buvo naudojamos reliacinės duomenų bazės, tokios kaip MySQL, Postgres ar SQL Server, buvo pradėtos diegti MongoDB duomenų bazės. Paklausus kodėl, galite gauti atsakymą nuo banalaus „tai yra žiniatinklio mastelis“ iki labiau apgalvoto „mano duomenys yra labai laisvos struktūros ir puikiai telpa duomenų bazėje be schemos“.
Svarbu atsiminti, kad MongoDB ir apskritai dokumentų duomenų bazės išsprendžia daugybę tradicinių reliacinių duomenų bazių problemų:
- Griežta schema: naudodami reliacinę duomenų bazę, jei turite dinamiškai generuojamų duomenų, esate priversti arba sukurti krūvą atsitiktinių „įvairių“ duomenų stulpelių, įterpti ten duomenų dėmes arba naudoti konfigūraciją. ...visa tai turi reikšmingų trūkumų.
- Mastelio keitimo sunkumai: Jei yra tiek daug duomenų, kad jie netelpa viename serveryje, MongoDB pasiūlė mechanizmus, leidžiančius juos išplėsti keliose mašinose.
- Sudėtingos grandinės modifikacijos: jokių migracijų! Reliacinėje duomenų bazėje duomenų bazės struktūros keitimas gali būti didžiulė problema (ypač kai duomenų yra daug). MongoDB sugebėjo labai supaprastinti procesą. Ir tai tapo taip paprasta, kad galite tiesiog atnaujinti grandinę ir labai greitai judėti toliau.
- Spektaklio įrašymas: MongoDB našumas buvo geras, ypač tinkamai sukonfigūravus. Net „MongoDB“ konfigūracija, dėl kurios ji dažnai buvo kritikuojama, parodė įspūdingus našumo skaičius.
Visa rizika tenka jums
Galima „MongoDB“ nauda buvo didžiulė, ypač kai kurių klasių problemų atveju. Jei perskaitysite aukščiau pateiktą sąrašą nesuprasdami konteksto ir neturėdami patirties, galite susidaryti įspūdį, kad MongoDB yra tikrai revoliucinė DBVS. Vienintelė problema buvo ta, kad pirmiau išvardyti privalumai buvo susiję su daugybe įspėjimų, kai kurie iš jų išvardyti toliau.
Tiesą sakant, niekas iš 10gen / MongoDB Inc. nesakys, kad tai netiesa, tai tik kompromisai.
- Prarastos operacijos: operacijos yra pagrindinė daugelio reliacinių duomenų bazių funkcija (ne visų, bet daugumos). Sandoris reiškia, kad galite atomiškai atlikti kelias operacijas ir užtikrinti, kad duomenys išliktų nuoseklūs. Žinoma, naudojant NoSQL duomenų bazę, sandoriai gali būti atliekami viename dokumente arba galite naudoti dviejų fazių įsipareigojimus, kad gautumėte operacijos semantiką. Tačiau šią funkciją turėsite įdiegti patys... o tai gali būti sudėtinga ir daug laiko reikalaujanti užduotis. Dažnai nesuvokiate, kad yra problema, kol nepamatote, kad duomenų bazėje esantys duomenys patenka į netinkamas būsenas, nes operacijų atomiškumas negali būti garantuotas. Pastaba: Daugelis žmonių man pasakė, kad MongoDB 4.0 pernai pristatė operacijas, tačiau su tam tikrais apribojimais. Straipsnio ištrauka išlieka ta pati: įvertinkite, kaip technologija atitinka jūsų poreikius.
- Santykių vientisumo praradimas (svetimi raktai): Jei jūsų duomenys turi ryšių, turėsite juos pritaikyti programoje. Turėdami duomenų bazę, kurioje atsižvelgiama į šiuos ryšius, programa, taigi ir programuotojai, atims daug darbo.
- Negebėjimas pritaikyti duomenų struktūros: Griežtos schemos kartais gali būti didelė problema, tačiau jos taip pat yra galingas gero duomenų struktūrizavimo mechanizmas, jei jos naudojamos protingai. Dokumentų duomenų bazės, tokios kaip MongoDB, suteikia neįtikėtiną schemos lankstumą, tačiau šis lankstumas pašalina atsakomybę už duomenų švarą. Jei jais nesirūpinsite, savo programoje turėsite įrašyti daug kodo, kad atsižvelgtumėte į duomenis, kurie nėra saugomi tokia forma, kokios tikitės. Kaip dažnai sakome mūsų įmonėje Simple Thread... programa kada nors bus perrašyta, bet duomenys gyvuos amžinai. Pastaba: MongoDB palaiko schemų tikrinimą: tai naudinga, bet nesuteikia tokių pat garantijų kaip reliacinėje duomenų bazėje. Visų pirma, schemos patikros pridėjimas arba keitimas neturi įtakos esamiems kolekcijoje esantiems duomenims. Jūs turite užtikrinti, kad atnaujintumėte duomenis pagal naują schemą. Ar to pakanka jūsų poreikiams, nuspręskite patys.
- Gimtoji užklausos kalba / įrankių ekosistemos praradimas: SQL atsiradimas buvo absoliuti revoliucija ir nuo to laiko niekas nepasikeitė. Tai neįtikėtinai galinga kalba, bet ir gana sudėtinga. Poreikis kurti duomenų bazės užklausas nauja kalba, sudarytas iš JSON fragmentų, žmonių, turinčių darbo su SQL, laiko dideliu žingsniu atgal. Yra daugybė įrankių, kurie sąveikauja su SQL duomenų bazėmis, nuo IDE iki ataskaitų teikimo įrankių. Perėjimas prie duomenų bazės, kuri nepalaiko SQL, reiškia, kad negalite naudoti daugumos šių įrankių arba turite išversti duomenis į SQL, kad galėtumėte juos naudoti, o tai gali būti sudėtingiau, nei manote.
Daugelis kūrėjų, kurie kreipėsi į „MongoDB“, nelabai suprato kompromisų ir dažnai stačia galva įdėjo jį kaip pagrindinę duomenų saugyklą. Po to dažnai būdavo neįtikėtinai sunku sugrįžti.
Ką buvo galima padaryti kitaip?
Ne visi šoko galvomis ir atsitrenkė į dugną. Tačiau daugelis projektų „MongoDB“ įdiegė ten, kur jis tiesiog netilpo – ir su juo teks gyventi dar daug metų. Jei šios organizacijos būtų praleidusios šiek tiek laiko ir metodiškai apgalvojusios savo technologijų pasirinkimą, daugelis būtų pasirinkusios kitaip.
Kaip pasirinkti tinkamą technologiją? Buvo ne kartą bandoma sukurti sistemingą technologijų vertinimo sistemą, pvz и , bet man atrodo, kad tai nereikalingas sudėtingumas.
Daugelį technologijų galima protingai įvertinti užduodant tik du pagrindinius klausimus. Problema yra rasti žmonių, kurie galėtų atsakyti į juos atsakingai, skirdami laiko atsakymams rasti ir be šališkumo.
Jei nesusiduriate su jokia problema, naujo įrankio jums nereikia. Taškas.
1 klausimas: kokias problemas aš bandau išspręsti?
Jei nesusiduriate su jokia problema, naujo įrankio jums nereikia. Taškas. Nereikia ieškoti sprendimo ir tada sugalvoti problemos. Jei nesusidūrėte su problema, kurią naujoji technologija išsprendžia žymiai geriau nei esama, nėra apie ką čia diskutuoti. Jei ketinate naudoti šią technologiją, nes matėte, kaip ją naudoja kiti, pagalvokite, su kokiomis problemomis jie susiduria, ir paklauskite, ar turite tų problemų. Lengva priimti technologiją, nes ja naudojasi kiti, iššūkis yra suprasti, ar jūs susiduriate su tomis pačiomis problemomis.
2 klausimas: ko man trūksta?
Tai tikrai sunkesnis klausimas, nes turėsite įsigilinti ir gerai suprasti seną ir naują technologiją. Kartais jūs negalite iš tikrųjų suprasti naujo, kol nieko su juo nesukūrėte arba neturite tos patirties.
Jei neturite nei vieno, nei kito, prasminga pagalvoti apie minimalias galimas investicijas, kad nustatytumėte šio instrumento vertę. O kai investuosite, kaip sunku bus atšaukti sprendimą?
Žmonės visada viską sugadina
Bandydami atsakyti į šiuos klausimus kuo nešališkiau, prisiminkite vieną dalyką: teks kovoti su žmogaus prigimtimi. Norint veiksmingai įvertinti technologijas, reikia įveikti daugybę pažinimo paklaidų. Štai tik keletas:
- - Visi apie jį žino, bet vis tiek sunku su juo kovoti. Tiesiog įsitikinkite, kad technologija iš tikrųjų atitinka jūsų tikrus poreikius.
- — Daugelis kūrėjų linkę nuvertinti technologijas, su kuriomis dirbo ilgą laiką, ir pervertinti naujų technologijų naudą. Tai ne tik programuotojai, bet ir visi yra jautrūs šiam pažintiniam šališkumui.
- – Mes linkę pamatyti, kas yra, ir pamiršti, ko trūksta. Tai gali sukelti chaosą kartu su naujumo efektu, nes jūs ne tik pervertinate naują technologiją, bet ir ignoruojate jos trūkumus..
Objektyvus vertinimas nėra lengvas, tačiau suprasdami pagrindinius kognityvinius šališkus, galėsite priimti racionalesnius sprendimus.
Santrauka
Kai tik atsiranda naujovė, reikia labai atsargiai atsakyti į du klausimus:
- Ar šis įrankis išsprendžia tikrą problemą?
- Ar gerai suprantame kompromisus?
Jei negalite užtikrintai atsakyti į šiuos du klausimus, ženkite kelis žingsnius atgal ir pagalvokite.
Taigi ar MongoDB buvo teisingas pasirinkimas? Žinoma taip; Kaip ir dauguma inžinerinių technologijų, tai priklauso nuo daugelio veiksnių. Tarp tų, kurie atsakė į šiuos du klausimus, daugelis gavo naudos iš MongoDB ir toliau tai daro. Tiems, kurie to nepadarė, tikiuosi, kad išmokote vertingą ir ne per daug skausmingą pamoką apie judėjimą ažiotažas.
Atsakomybės apribojimas
Noriu paaiškinti, kad su MongoDB neturiu nei meilės, nei neapykantos santykių. Mes tiesiog neturėjome tokių problemų, kurias MongoDB geriausiai tiktų išspręsti. Žinau, kad 10gen/MongoDB Inc. iš pradžių buvo labai drąsus, nustatydamas nesaugius numatytuosius nustatymus ir visur (ypač hakatonuose) reklamuodamas MongoDB kaip universalų sprendimą dirbant su bet kokiais duomenimis. Tikriausiai tai buvo blogas sprendimas. Tačiau tai patvirtina čia aprašytą požiūrį: šias problemas galima labai greitai aptikti net ir paviršutiniškai įvertinus technologiją.
Šaltinis: www.habr.com