Duela gutxi jakin dut hori (esan, lizentzia aldaketak direla eta). Pentsatu ninduen azken urteotan artikulu mordoa ikusi dudala MongoDB zein ikaragarria den eta inork ez lukeela inoiz erabili behar. Baina denbora horretan, MongoDB produktu askoz helduagoa bihurtu da. Zer gertatu da? Gorroto guztia DBMS berriaren merkaturatzearen hasieran egindako akatsengatik da benetan? Edo jendea MongoDB erabiltzen ari da leku okerrean?
Bat-batean MongoDB defendatzen ari naizela sentitzen baduzu, irakurri mesedez artikuluaren amaieran.
Joera berria
Esan behar den baino urte gehiago daramatzat softwarearen industrian, baina hala ere, gure industrian jo zuten joeren parte baino ez naiz izan. 4GL, AOP, Agile, SOA, Web 2.0, AJAX, blockchain-en gorakada ikusi dut... zerrenda amaigabea da. Urtero joera berriak sortzen dira. Batzuk azkar desagertzen ari dira, eta beste batzuk softwarea garatzeko modua funtsean aldatzen ari dira.
Joera berri bakoitzaren inguruan, nolabaiteko zirrara orokor bat sortzen da: jendea txalupara jauzi egiten da, edo besteek sortzen duten zarata ikusi eta jendetza jarraitzen du. Prozesu hau Gartnerrek kodetu du . Eztabaidagarria izan arren, grafiko honek, gutxi gorabehera, teknologiekin zer gertatzen den deskribatzen du azkenean erabiltzeko baliagarriak izan aurretik.
Baina noizean behin bada (edo bada bigarren etorrera, kasu honetan bezala) berrikuntza berri bat, horren ezarpen zehatz bakarrak bultzatuta. NoSQL-ren kasuan, hype-a MongoDBren etorrerak eta gorakada meteorikoak bultzatu zuen. MongoDB-k ez zuen joera hori hasi: izan ere, Interneteko konpainia handiak datu-kopuru handiak prozesatzeko arazoak izaten hasi ziren, eta horrek datu-base ez-erlazionalak itzultzea ekarri zuen. Mugimendu orokorra Google-ren Bigtable eta Facebook-en Cassandra bezalako proiektuekin hasi zen, baina MongoDB izan zen garatzaile gehienek eskura izan zuten NoSQL datu-basearen inplementazio ospetsuena eta eskuragarriena bihurtu zena.
Oharra: Pentsa dezakezu dokumentuen datu-baseak zutabe datu-baseekin, gako/balio-biltegiekin edo NoSQL-ren definizio orokorrean sartzen diren beste datu-biltegi mota batzuekin nahasten ari naizela. Eta arrazoi duzu. Baina garai hartan, kaosa zen nagusi. Denak obsesionatuta daude NoSQLrekin, dena bihurtu da erabat beharrezkoa, nahiz eta askok teknologia ezberdinetan ezberdintasunak ikusi ez. Askorentzat MongoDB bihurtu da sinonimoa NoSQL.
Eta garatzaileek horren gainean egin zuten salto. Edozein arazo konpontzeko magiaz eskalatzen duen eskemarik gabeko datu-base baten ideia nahiko tentagarria zen. 2014 inguruan, bazirudien nonahi erabiltzen zela MySQL, Postgres edo SQL Server bezalako datu-base erlazional bat duela urtebete, MongoDB datu-baseak zabaltzen ari zirela. Zergatik galdetuta, "hau da sarearen eskala" hutsaletik "nire datuak oso modu baxuan egituratuta daude eta eskemarik gabeko datu-base batean ondo sartzen dira".
Garrantzitsua da gogoratzea MongoDB-k eta, oro har, dokumentu-datu-baseek hainbat arazo konpontzen dituztela datu-base erlazional tradizionalekin:
- Eskema zorrotza: datu-base erlazional batekin, dinamikoki datuak sortu badituzu, behartuta zaude ausazko datu-zutabe "desberdin" sorta bat sortzera, datu-blobak bertan sartu edo konfigurazio bat erabiltzera. ... honek guztiak eragozpen nabarmenak ditu.
- Eskalatzeko zailtasuna: zerbitzari batean sartzen ez den datu asko badago, MongoDB-k hainbat makinatan eskalatzeko mekanismoak eskaini zituen.
- Zirkuitu konplexuen aldaketak: migraziorik ez! Datu-base erlazional batean, datu-basearen egitura aldatzea arazo izugarria izan daiteke (batez ere datu asko daudenean). MongoDB prozesua asko errazteko gai izan da. Eta oso erraza da, ezen edonon eskema eguneratu dezakezula eta oso azkar aurrera egin dezakezu.
- Idatzi performancea: MongoDB errendimendua ona izan zen, batez ere behar bezala sintonizatuta. Nahiz eta MongoDB-ren kanpoko konfigurazioak, askotan kritikatua izan zena, errendimendu zifra ikusgarriak erakutsi zituen.
Arrisku guztiak zure gainean daude
MongoDB-ren balizko onurak izugarriak ziren, batez ere arazo-klase batzuetarako. Goiko zerrenda irakurtzen baduzu testuingurua ulertu gabe eta esperientziarik izan gabe, baliteke MongoDB benetan DBMS iraultzailea dela irudikatzea. Arazo bakarra zen goian zerrendatutako onurak zenbait oharrekin zetozela, eta horietako batzuk behean zerrendatzen dira.
Bidezkoa izateko, inork ez du 10gen/MongoDB Inc. ez du esango honako hau egia ez denik, hauek konpromisoak besterik ez dira.
- Transakzioen galeraE: Transakzioak datu-base erlazional askoren ezaugarri nagusiak dira (guztiak ez, baina gehienak). Transakzionalak esan nahi du hainbat eragiketa atomikoki egin ditzakezula eta datuak koherenteak izaten direla ziurta dezakezula. Noski, NoSQL datu-base batekin, transakzionaltasuna dokumentu bakar baten barruan egon daiteke, edo bi faseko konpromisoak erabil ditzakezu transakzio-semantika lortzeko. Baina zuk zeuk inplementatu beharko duzu funtzionalitate hori... eta horrek lan zaila eta denbora asko eskatzen du. Askotan ez zara arazoaz konturatzen datu-baseko datuak egoera baliogabeetan sartzen direla ikusi arte, ezinezkoa baita eragiketen atomotasuna bermatzea. Oharra: askok esan didate iaz MongoDB 4.0-n transakzioak sartu zirela, baina muga batzuekin. Artikuluaren ondorioa berdina izaten jarraitzen du: ebaluatu teknologia zure beharretara nola egokitzen den.
- Erlazio-osotasuna galtzea (atzerriko gakoak): zure datuek harremanak badituzte, orduan aplikazioan aplikatu beharko dituzu. Harreman hauek errespetatzen dituen datu-base bat edukitzeak lan handia kenduko dio aplikazioari eta, beraz, zure programatzaileei.
- Datuen egitura aplikatzeko ezintasuna: Eskema zorrotzak arazo handiak izan daitezke batzuetan, baina datuen egituraketa ona egiteko mekanismo indartsuak ere badira zentzuz erabiltzen badira. MongoDB bezalako dokumentu datu-baseek eskema malgutasun izugarria eskaintzen dute, baina malgutasun horrek datuak garbi mantentzeko ardura kentzen du. Ez badituzu zaintzen, azkenean kode asko idatziko duzu zure aplikazioan espero duzun moduan gordeta ez dauden datuak kontuan hartzeko. Gure enpresa Simple Thread askotan esaten duten bezala⦠aplikazioa noizbait berridatziko da, baina datuak betiko biziko dira. Oharra: MongoDB-k eskema baliozkotzea onartzen du, erabilgarria dena baina ez du datu-base erlazional baten berme berdinak eskaintzen. Lehenik eta behin, eskemaren baliozkotzea gehitzeak edo aldatzeak ez du eragina bilduman dauden datuei. Datuak eskema berriaren arabera eguneratzen dituzula ziurtatu behar duzu. Zeuk erabaki zure beharretarako nahikoa den.
- Kontsulta-lengoaia propioa / tresna-ekosistema galtzea: SQLren etorrera erabateko iraultza izan zen, eta orduz geroztik ez da ezer aldatu. Izugarrizko hizkuntza indartsua da, baina baita nahiko konplexua ere. Datu-baseen kontsultak hizkuntza berri batean eraikitzeko beharra, JSON zatiez osatua, atzerapauso handia dela uste dute SQLrekin esperientzia duten pertsonek. SQL datu-baseekin elkarreraginean dauden tresnen unibertso oso bat dago, IDEetatik hasi eta txostenak egiteko tresnetara. SQL onartzen ez duen datu-base batera mugitzeak esan nahi du ezin dituzula tresna horietako gehienak erabili, edo datuak SQLra bihurtu behar dituzu haiek erabiltzeko, eta hori uste baino zailagoa izan daiteke.
MongoDB-ra jo zuten garatzaile askok ez zituzten konpromezuak ulertzen, eta askotan buru-belarri murgildu ziren datu-biltegi nagusi gisa konfiguratzera. Horren ostean, askotan, izugarri zaila zen atzera egitea.
Zer egin zitekeen ezberdin?
Denek ez zuten burua jauzi egin eta hondora talka egin zuten. Baina proiektu gutxik instalatu dute MongoDB oinarria kabitzen ez zen tokian, eta horrekin bizi beharko dute urte askoz gehiagoz. Erakunde horiek denbora pixka bat hartu izan balute beren teknologia-aukerak metodikoki aztertzeko, askok beste aukera bat egingo lukete.
Nola aukeratu teknologia egokia? Hainbat saiakera izan dira teknologiaren ebaluaziorako esparru sistematiko bat sortzeko, esaterako ΠΈ , baina iruditzen zait hori alferrikako konplexutasuna dela.
Teknologia asko modu adimentsuan baloratu daitezke oinarrizko bi galdera besterik ez eginez. Arazoa arduraz erantzuteko gai diren pertsonak aurkitzean datza, erantzunak bilatzeko denbora hartuz eta alborapenik gabe.
Arazoren bat aurkitzen ez baduzu, ez duzu tresna berririk behar. Dot.
1. galdera: Zein arazo konpontzen saiatzen ari naiz?
Arazoren bat aurkitzen ez baduzu, ez duzu tresna berririk behar. Dot. Ez da irtenbide bat bilatu beharrik eta gero arazo bat sortu. Teknologia berriak lehendik duzun teknologia baino askoz hobeto konpontzen ez duen arazoren baten aurrean ez bazaude, orduan ez dago ezer eztabaidatu hemen. Teknologia hau erabiltzea pentsatzen ari bazara beste batzuk erabiltzen ikusi dituzulako, pentsatu haiek dituzten arazoei buruz eta galdetu arazo horiek izaten ari zaren. Erraza da teknologia bereganatzea beste batzuk erabiltzen ari direlako, zailtasuna arazo berdinei aurre egiten ari zaren jakitea da.
2. galdera: Zer falta zait?
Zalantzarik gabe galdera zailagoa da, teknologia zaharra zein berria ondo zulatu eta ulertu behar duzulako. Batzuetan, ezin duzu berri bat ulertu harekin zerbait eraiki arte edo esperientzia horrekin lankide bat izan arte.
Bata ez bada ere, zentzuzkoa da tresna honen balioa zehazteko ahalik eta inbertsio minimoa pentsatzea. Eta inbertsio bat egiten baduzu, zein zaila izango da erabakia atzera botatzea?
Jendeak beti hondatzen du dena
Galdera horiei ahalik eta inpartzialki erantzuten saiatzean, gogoratu gauza bat: giza izaeraren aurka borrokatu behar duzu. Teknologia eraginkortasunez ebaluatzeko hainbat alde kognitibo gainditu behar dira. Hona hemen batzuk:
- Denek dakite haren berri, baina oraindik zaila da harekin borrokatzea. Ziurtatu teknologia benetan zure beharretara egokitzen dela.
- Garatzaile askok denbora luzez lan egiten duten teknologiak gutxiesten dituzte eta teknologia berri baten onurak gainbaloratzen dituzte. Programatzaileak ez ezik, denek alborapen kognitibo horren menpe daude.
- Zer den ikusi eta ez dena bistatik galdu ohi dugu. Horrek kaosa sor dezake, berritasun efektuarekin konbinatuta, teknologia berria berez gainbaloratzen ez ezik, bere gabeziak ere baztertzen dituzulako..
Ebaluazio objektiboa ez da erraza, baina azpian dauden alborapen kognitiboak ulertzeak erabaki arrazionalagoak hartzen lagunduko dizu.
Laburpena
Berrikuntza bat sortzen denean, arreta handiz erantzun behar dira bi galdera:
- Tresna honek benetako arazo bat konpontzen al du?
- Onak al gara trukeak ulertzen?
Ezin baduzu bi galdera hauei ziur erantzun, eman urrats batzuk atzera eta pentsatu.
Beraz, la MongoDB, oro har, aukera egokia al zen? Noski baietz; ingeniaritza teknologia gehienetan bezala, faktore askoren araberakoa da. Bi galdera hauei erantzun dieten artean, askok MongoDBri etekina atera diote eta hala jarraitzen dute. Ez duzuenontzat, espero dut hype-zikloan zehar mugitzeari buruzko lezio baliotsu eta ez mingarri bat ikasi izana.
Erantzukizuna
Argitu nahi dut ez dudala ez maite ez gorroto MongoDB. Ez genuen MongoDB konpontzeko egokiena den arazo motarik. Badakit 10gen/MongoDB Inc. Hasieran oso ausart jokatu zuen, lehenespen seguruak ezarriz eta MongoDB nonahi sustatuz (batez ere hackathons-etan) edozein daturekin lan egiteko irtenbide bakarreko irtenbide gisa. Ziurrenik erabaki txarra izan zen. Baina hemen deskribatutako ikuspegia berresten du: arazo hauek oso azkar detekta litezke teknologiaren azaleko ebaluazioa eginda ere.
Iturria: www.habr.com