Mi ĵus eksciis tion (oni diras pro licencaj ŝanĝoj). Ĉi tio pensigis min ĉar en la lastaj jaroj mi vidis amason da artikoloj pri kiom terura estas MongoDB kaj kiel neniu iam devus uzi ĝin. Sed dum ĉi tiu tempo, MongoDB fariĝis multe pli matura produkto. Kio okazis? Ĉu la tuta malamo vere estas pro eraroj en la frua merkatado de nova DBMS? Aŭ ĉu homoj nur uzas MongoDB en malĝustaj lokoj?
Se vi sentas, ke mi defendas MongoDB, bonvolu legi ĉe la fino de la artikolo.
Nova tendenco
Mi laboras en la programara industrio dum pli da jaroj ol mi povas diri, sed mi ankoraŭ nur estis elmontrita al malgranda parto de la tendencoj kiuj trafis nian industrion. Mi atestis la pliiĝon de 4GL, AOP, Agile, SOA, Web 2.0, AJAX, Blockchain... la listo estas senfina. Ĉiujare aperas novaj tendencoj. Iuj rapide forvelkas, dum aliaj esence ŝanĝas la manieron kiel programaro estas disvolvita.
Ĉiu nova tendenco kreas specon de ĝenerala ekscito: homoj aŭ mem saltas sur la boaton, aŭ vidas la bruon generitan de aliaj - kaj sekvas la homamason. Ĉi tiu procezo estas kodigita de Gartner en . Kvankam polemika, ĉi tiu templinio proksimume priskribas kio okazas al teknologioj antaŭ ol ili poste iĝas utilaj.
Sed de tempo al tempo nova novigo aperas (aŭ havas duan venon, kiel en ĉi tiu kazo) pelita de nur unu specifa efektivigo. En la kazo de NoSQL, la ekzaltiĝo estis forte pelita de la apero kaj meteora kresko de MongoDB. MongoDB ne komencis ĉi tiun tendencon: fakte, grandaj interretaj kompanioj komencis havi problemojn pri prilaborado de grandaj kvantoj da datumoj, kio kaŭzis revenon de ne-rilataj datumbazoj. La ĝenerala movado komenciĝis per projektoj kiel Bigtable de Google kaj Cassandra de Facebook, sed estis MongoDB kiu iĝis la plej konata kaj alirebla NoSQL-datumbaza efektivigo al kiu la plej multaj programistoj havis aliron.
Noto: Vi eble pensas, ke mi konfuzas dokumentajn datumbazojn kun kolumnaj datumbazoj, ŝlosilaj/valoraj vendejoj, aŭ iu ajn el la multaj aliaj specoj de datumbutikoj, kiuj kategoriiĝas sub la ĝenerala NoSQL-difino. Kaj vi pravas. Sed en tiu tempo regis kaoso. Ĉiuj estas obsedita de NoSQL, ĝi fariĝis ĉiuj absolute necesa, kvankam multaj ne vidis la diferencojn en malsamaj teknologioj. Por multaj, MongoDB fariĝis sinonima NoSQL.
Kaj la programistoj saltis sur ĝin. La ideo de senskema datumbazo, kiu magie grimas por solvi ajnan problemon, estis sufiĉe tenta. Ĉirkaŭ 2014, ŝajnis, ke ĉie, ke antaŭ jaro uzis interrilatan datumbazon kiel MySQL, Postgres aŭ SQL Server, komencis disfaldi MongoDB-datumbazon. Se demandite kial, vi povus ricevi respondon de la banala "ĉi tio estas la skalo de la reto" al la pli pripensema "miaj datumoj estas tre loze strukturitaj kaj bone taŭgas en datumbazo sen skemo."
Gravas memori, ke MongoDB, kaj dokumenta datumbazoj ĝenerale, solvas kelkajn problemojn kun tradiciaj interrilataj datumbazoj:
- Strikta skemo: Kun interrilata datumbazo, se vi dinamike generis datumojn, vi estas devigita aŭ krei amason da hazardaj "diversaj" kolumnoj da datumoj, enŝovi tien datumojn aŭ uzi agordon. ... ĉio ĉi havas signifajn malavantaĝojn.
- Malfacileco grimpi: Se estas tiom da datumoj, ke ĝi ne taŭgas sur unu servilo, MongoDB ofertis mekanismojn por permesi al ĝi grimpi trans pluraj maŝinoj.
- Kompleksaj cirkvitaj modifoj: neniuj migradoj! En interrilata datumbazo, ŝanĝi la datumbazan strukturon povas esti grandega problemo (precipe kiam estas multaj datumoj). MongoDB povis multe simpligi la procezon. Kaj ĝi tiel facilas, ke vi povas simple ĝisdatigi la cirkviton dum vi iras kaj antaŭeniri tre rapide.
- Registrada rendimento: MongoDB-agado estis bona, precipe kiam konvene agordita. Eĉ la eksterordinara agordo de MongoDB, pro kiu ĝi ofte estis kritikita, montris kelkajn imponajn rendimentajn nombrojn.
Ĉiuj riskoj estas sur vi
La eblaj avantaĝoj de MongoDB estis enormaj, precipe por certaj klasoj de problemoj. Se vi legas la supran liston sen kompreni la kuntekston kaj sen sperto, vi eble havos la impreson, ke MongoDB estas vere revolucia DBMS. La nura problemo estis, ke la avantaĝoj listigitaj supre venis kun kelkaj avertoj, kelkaj el kiuj estas listigitaj malsupre.
Por esti justa, neniu ĉe 10gen/MongoDB Inc. ne diros, ke la sekvanta ne estas vera, ĉi tiuj estas nur kompromisoj.
- Perditaj transakcioj: Transakcioj estas kerna trajto de multaj rilataj datumbazoj (ne ĉiuj, sed plej multaj). Transakcia signifas, ke vi povas fari plurajn operaciojn atome kaj povas certigi, ke la datumoj restas konsekvencaj. Kompreneble, kun NoSQL-datumbazo, transakcebleco povas esti ene de ununura dokumento, aŭ vi povas uzi dufazajn komitojn por akiri transakcian semantikon. Sed vi mem devos efektivigi ĉi tiun funkcion... kio povas esti malfacila kaj tempopostula tasko. Ofte vi ne rimarkas, ke ekzistas problemo ĝis vi vidas, ke la datumoj en la datumbazo finiĝas en nevalidaj ŝtatoj ĉar la atomeco de operacioj ne povas esti garantiita. Noto: Multaj homoj diris al mi, ke MongoDB 4.0 enkondukis transakciojn pasintjare, sed kun iuj limigoj. La preskribo de la artikolo restas la sama: taksu kiom bone la teknologio plenumas viajn bezonojn.
- Perdo de interrilata integreco (fremdaj ŝlosiloj): Se viaj datumoj havas rilatojn, tiam vi devos apliki ilin en la aplikaĵo. Havi datumbazon, kiu respektas ĉi tiujn rilatojn, prenos multan laboron de la aplikaĵo kaj sekve de viaj programistoj.
- Manko de kapablo apliki datumstrukturon: Striktaj skemoj foje povas esti granda problemo, sed ili ankaŭ estas potenca mekanismo por bona datumstrukturado se uzataj saĝe. Dokumentaj datumbazoj kiel MongoDB provizas nekredeblan skemflekseblecon, sed ĉi tiu fleksebleco forigas la respondecon konservi la datumojn puraj. Se vi ne prizorgas ilin, vi finos skribi multe da kodo en via aplikaĵo por kontentigi datumojn, kiuj ne estas konservitaj en la formo, kiun vi atendas. Kiel ni ofte diras ĉe nia kompanio Simple Thread... la aplikaĵo iam estos reverkita, sed la datumoj vivos eterne. Noto: MongoDB subtenas skemkontroladon: ĝi estas utila, sed ne provizas la samajn garantiojn kiel en rilata datumbazo. Antaŭ ĉio, aldoni aŭ ŝanĝi skemkontrolon ne influas ekzistantajn datumojn en la kolekto. Dependas de vi certigi, ke vi ĝisdatigas la datumojn laŭ la nova skemo. Decidu mem ĉu tio sufiĉas por viaj bezonoj.
- Denaska demandlingvo / perdo de ila ekosistemo: La apero de SQL estis absoluta revolucio kaj nenio ŝanĝiĝis de tiam. Ĝi estas nekredeble potenca lingvo, sed ankaŭ sufiĉe kompleksa. La bezono konstrui datumbazajn demandojn en nova lingvo konsistanta el JSON-fragmentoj estas rigardata kiel granda paŝo malantaŭen de homoj, kiuj havas sperton pri laborado kun SQL. Estas tuta universo de iloj, kiuj interagas kun SQL-datumbazoj, de IDEoj ĝis raportaj iloj. Moviĝi al datumbazo kiu ne subtenas SQL signifas ke vi ne povas uzi la plej multajn el ĉi tiuj iloj aŭ vi devas traduki la datumojn en SQL por uzi ilin, kio povas esti pli malfacila ol vi pensas.
Multaj programistoj, kiuj turnis sin al MongoDB, ne vere komprenis la kompromisojn, kaj ofte plonĝis kapunue por instali ĝin kiel sian ĉefan datumbutikon. Post tio ofte estis nekredeble malfacile reveni.
Kio povus esti farita alimaniere?
Ne ĉiuj saltis kapunue kaj trafis la fundon. Sed sufiĉe multaj projektoj instalis MongoDB en lokoj kie ĝi simple ne konvenis—kaj ili devos vivi kun ĝi dum multaj jaroj. Se ĉi tiuj organizoj pasigus iom da tempo kaj metode pripensus siajn teknologiajn elektojn, multaj farus malsamajn elektojn.
Kiel elekti la ĝustan teknologion? Okazis pluraj provoj krei sisteman kadron por teknologia taksado, kiel ekzemple и , sed ŝajnas al mi, ke tio estas nenecesa komplekseco.
Multaj teknologioj povas esti inteligente taksitaj demandante nur du bazajn demandojn. La problemo estas trovi homojn kiuj povas respondi ilin respondece, prenante la tempon por trovi la respondojn kaj sen antaŭjuĝo.
Se vi ne alfrontas problemon, vi ne bezonas novan ilon. Punkto.
Demando 1: Kiajn problemojn mi provas solvi?
Se vi ne alfrontas problemon, vi ne bezonas novan ilon. Punkto. Ne necesas serĉi solvon kaj poste elpensi problemon. Krom se vi renkontis problemon, kiun la nova teknologio solvas signife pli bone ol via ekzistanta teknologio, estas nenio por diskuti ĉi tie. Se vi pripensas uzi ĉi tiun teknologion ĉar vi vidis aliajn uzi ĝin, pensu pri kiaj problemoj ili alfrontas kaj demandu ĉu vi havas tiujn problemojn. Estas facile akcepti teknologion ĉar aliaj uzas ĝin, la defio estas kompreni ĉu vi alfrontas la samajn problemojn.
Demando 2: Kion mi mankas?
Ĉi tio certe estas pli malfacila demando, ĉar vi devos fosi kaj bone kompreni kaj la malnovan kaj novan teknologion. Foje vi ne povas vere kompreni novan ĝis vi konstruis ion per ĝi aŭ havas iun kun tiu sperto.
Se vi ne havas nek, tiam havas sencon pensi pri la minimuma ebla investo por determini la valoron de ĉi tiu instrumento. Kaj kiam vi faros la investon, kiom malfacile estos inversigi la decidon?
Homoj ĉiam ruinigas ĉion
Dum vi provas respondi ĉi tiujn demandojn kiel eble plej senpartie, memoru unu aferon: vi devos batali la homan naturon. Estas kelkaj kognaj biasoj, kiuj devas esti venkitaj por efike taksi teknologion. Jen nur kelkaj:
- - ĉiuj scias pri li, sed estas ankoraŭ malfacile batali kontraŭ li. Nur certigu, ke la teknologio efektive kongruas kun viaj realaj bezonoj.
- - Multaj programistoj emas subtaksi teknologiojn, kun kiuj ili laboris dum longa tempo, kaj supertaksi la avantaĝojn de nova teknologio. Ne temas nur pri programistoj, ĉiuj estas susceptibles al ĉi tiu kogna biaso.
- - Ni emas vidi kio estas tie kaj perdi vidon de kio mankas. Ĉi tio povas konduki al kaoso kiam kombinite kun la noveca efiko, ĉar vi ne nur esence supervaloras novan teknologion, sed ankaŭ ignoras ĝiajn mankojn..
Objektiva taksado ne estas facila, sed kompreni la subestajn kognajn biasojn helpos vin fari pli raciajn decidojn.
Resumo
Kiam ajn novigo aperas, du demandoj devas esti responditaj tre zorge:
- Ĉu ĉi tiu ilo solvas veran problemon?
- Ĉu ni bone komprenas la kompromisojn?
Se vi ne povas memfide respondi ĉi tiujn du demandojn, faru kelkajn paŝojn malantaŭen kaj pripensu.
Do ĉu MongoDB eĉ estis la ĝusta elekto? Kompreneble jes; Kiel ĉe plej multaj inĝenieraj teknologioj, ĉi tio dependas de multaj faktoroj. Inter tiuj, kiuj respondis ĉi tiujn du demandojn, multaj profitis de MongoDB kaj daŭre faras tion. Por tiuj, kiuj ne faris, mi esperas, ke vi lernis valoran kaj ne tro doloran lecionon pri moviĝado tra la ciklo de ekzaltiĝo.
Malgarantio
Mi volas klarigi, ke mi havas nek amon nek malaman rilaton kun MongoDB. Ni simple ne havis tiajn problemojn, kiujn MongoDB plej taŭgas por solvi. Mi scias, ke 10gen/MongoDB Inc. estis tre aŭdaca komence, fiksante nesekurajn defaŭltojn kaj reklamante MongoDB ĉie (precipe ĉe hakatonoj) kiel universala solvo por labori kun ajnaj datumoj. Ĝi verŝajne estis malbona decido. Sed ĝi konfirmas la aliron priskribitan ĉi tie: ĉi tiuj problemoj povus esti detektitaj tre rapide eĉ kun supraĵa takso de la teknologio.
fonto: www.habr.com