Nedavno sam to saznao Red Hat uklanja podršku za MongoDB sa Satellita (kažu zbog promjena licence). Ovo me natjeralo na razmišljanje jer sam u posljednjih nekoliko godina vidio gomilu članaka o tome koliko je MongoDB grozan i kako ga nitko ne bi trebao koristiti. Ali tijekom tog vremena MongoDB je postao mnogo zreliji proizvod. Što se dogodilo? Je li sva mržnja doista posljedica pogrešaka u ranom marketingu novog DBMS-a? Ili ljudi samo koriste MongoDB na krivim mjestima?

Ako mislite da branim MongoDB, pročitajte odricanje na kraju članka.

Novi trend

Radim u softverskoj industriji više godina nego što mogu reći, ali još uvijek sam bio izložen samo malom dijelu trendova koji su pogodili našu industriju. Svjedočio sam usponu 4GL, AOP, Agile, SOA, Web 2.0, AJAX, Blockchain... popis je beskrajan. Svake godine pojavljuju se novi trendovi. Neki brzo nestaju, dok drugi iz temelja mijenjaju način razvoja softvera.

Svaki novi trend stvara opće uzbuđenje: ljudi ili uskaču u brod ili vide buku koju stvaraju drugi i slijede gomilu. Ovaj proces je kodificirao Gartner u hype ciklus. Iako je kontroverzan, ovaj vremenski okvir grubo opisuje što se događa s tehnologijama prije nego što konačno postanu korisne.

No, s vremena na vrijeme pojavi se nova inovacija (ili se ponovno pojavi, kao u ovom slučaju) vođena samo jednom specifičnom implementacijom. U slučaju NoSQL-a, hype je bio uvelike potaknut pojavom i meteorskim usponom MongoDB-a. MongoDB nije započeo ovaj trend: dapače, velike internetske tvrtke počele su imati problema s obradom velikih količina podataka, što je dovelo do povratka nerelacijskih baza podataka. Cjelokupni pokret započeo je s projektima poput Googleovog Bigtablea i Facebookove Cassandre, ali MongoDB je postao najpoznatija i najpristupačnija implementacija NoSQL baze podataka kojoj je većina programera imala pristup.

Napomena: Možda mislite da brkam baze podataka dokumenata s bazama podataka u stupcima, pohranama ključeva/vrijednosti ili bilo kojom od brojnih drugih vrsta pohrana podataka koje potpadaju pod opću NoSQL definiciju. I imaš pravo. Ali u to vrijeme vladao je kaos. Svi su opsjednuti NoSQL-om, postali su svi apsolutno potrebno, iako mnogi nisu vidjeli razlike u različitim tehnologijama. Za mnoge je MongoDB postao sinonim za NoSQL.

I programeri su se bacili na to. Ideja o bazi podataka bez sheme koja se magično skalira za rješavanje bilo kojeg problema bila je prilično primamljiva. Oko 2014. godine činilo se da su svugdje gdje su prije godinu dana koristile relacijsku bazu podataka kao što su MySQL, Postgres ili SQL Server počele implementirati MongoDB baze podataka. Na pitanje zašto, mogli biste dobiti odgovor od banalnog "ovo je razmjer weba" do promišljenijeg "moji su podaci vrlo labavo strukturirani i dobro se uklapaju u bazu podataka bez sheme."

Važno je upamtiti da MongoDB i baze podataka dokumenata općenito rješavaju niz problema s tradicionalnim relacijskim bazama podataka:

• Stroga shema: S relacijskom bazom podataka, ako imate dinamički generirane podatke, prisiljeni ste ili stvoriti hrpu nasumičnih "raznih" stupaca podataka, ugurati mrlje podataka tamo ili koristiti konfiguraciju EAV proširenje...sve ovo ima značajne nedostatke.
• Poteškoće u skaliranju: Ako ima toliko podataka da ne stane na jedan poslužitelj, MongoDB je ponudio mehanizme koji mu omogućuju skaliranje na više strojeva.
• Složene modifikacije krugova: nema migracija! U relacijskim bazama podataka, promjena strukture baze podataka može biti veliki problem (osobito kada ima puno podataka). MongoDB je uspio uvelike pojednostaviti proces. I učinio je to tako lakim da možete samo ažurirati strujni krug u hodu i nastaviti vrlo brzo.
• Snimanje izvedbe: Performanse MongoDB-a bile su dobre, posebno kada je ispravno konfiguriran. Čak je i konfiguracija MongoDB-a izvan okvira, zbog koje je često kritizirana, pokazala neke impresivne brojke performansi.

Svi rizici su na vama

Potencijalne prednosti MongoDB-a bile su ogromne, posebno za određene klase problema. Ako čitate gornji popis bez razumijevanja konteksta i bez iskustva, možete steći dojam da je MongoDB doista revolucionarni DBMS. Jedini je problem bio u tome što su gore navedene prednosti imale niz upozorenja, od kojih su neka navedena u nastavku.

Da budemo pošteni, nitko u 10gen/MongoDB Inc. neće reći da sljedeće nije točno, to su samo kompromisi.

• Izgubljene transakcije: Transakcije su temeljna značajka mnogih relacijskih baza podataka (ne svih, ali većine). Transakcijski znači da možete atomski izvesti više operacija i osigurati da podaci ostanu dosljedni. Naravno, s NoSQL bazom podataka, transakcijska vrijednost može biti unutar jednog dokumenta ili možete koristiti dvofazne obveze da biste dobili transakcijsku semantiku. Ali ovu ćete funkcionalnost morati implementirati sami... što može biti težak i dugotrajan zadatak. Često ne shvaćate da postoji problem dok ne vidite da podaci u bazi podataka završavaju u nevažećim stanjima jer se atomičnost operacija ne može jamčiti. Napomena: Mnogi ljudi su mi rekli da je MongoDB 4.0 uveo transakcije prošle godine, ali uz neka ograničenja. Zaključak iz članka ostaje isti: procijenite koliko dobro tehnologija zadovoljava vaše potrebe.
• Gubitak relacijskog integriteta (strani ključevi): Ako vaši podaci imaju odnose, morat ćete ih primijeniti u aplikaciji. Imati bazu podataka koja poštuje te odnose oduzet će mnogo posla aplikaciji, a time i vašim programerima.
• Nedostatak mogućnosti primjene strukture podataka: Stroge sheme ponekad mogu biti veliki problem, ali one su također moćan mehanizam za dobro strukturiranje podataka ako se koriste mudro. Baze podataka dokumenata kao što je MongoDB pružaju nevjerojatnu fleksibilnost sheme, ali ta fleksibilnost uklanja odgovornost za održavanje podataka čistima. Ako se ne pobrinete za njih, završit ćete tako što ćete napisati puno koda u svojoj aplikaciji za obračun podataka koji nisu pohranjeni u obliku koji očekujete. Kao što često kažemo u našoj tvrtki Simple Thread... aplikacija će jednog dana biti ponovno napisana, ali će podaci živjeti vječno. Napomena: MongoDB podržava provjeru sheme: korisna je, ali ne pruža ista jamstva kao u relacijskoj bazi podataka. Prije svega, dodavanje ili promjena provjere sheme ne utječe na postojeće podatke u zbirci. Na vama je da ažurirate podatke u skladu s novom shemom. Sami odlučite je li to dovoljno za vaše potrebe.
• Izvorni jezik upita / gubitak ekosustava alata: Pojava SQL-a bila je apsolutna revolucija i od tada se ništa nije promijenilo. To je nevjerojatno moćan jezik, ali i prilično složen. Potrebu za konstruiranjem upita baze podataka na novom jeziku koji se sastoji od JSON fragmenata ljudi koji imaju iskustva u radu sa SQL-om smatraju velikim korakom unatrag. Postoji cijeli svemir alata koji komuniciraju sa SQL bazama podataka, od IDE-a do alata za izvješćivanje. Prelazak na bazu podataka koja ne podržava SQL znači da ne možete koristiti većinu ovih alata ili morate prevesti podatke u SQL da biste ih koristili, što može biti teže nego što mislite.

Mnogi programeri koji su se okrenuli MongoDB-u nisu baš razumjeli kompromise i često su se bezglavo zaronili u njegovo instaliranje kao svoju primarnu pohranu podataka. Nakon toga često je bilo nevjerojatno teško vratiti se.

Što se moglo učiniti drugačije?

Nisu svi skočili na glavu i pogodili dno. Ali mnogi su projekti instalirali MongoDB na mjesta gdje jednostavno nije odgovarao - i morat će živjeti s njim još mnogo godina. Da su te organizacije provele neko vrijeme i metodično razmislile o svojim tehnološkim izborima, mnoge bi napravile drugačije izbore.

Kako odabrati pravu tehnologiju? Bilo je nekoliko pokušaja stvaranja sustavnog okvira za procjenu tehnologije, kao što je "Okvir za uvođenje tehnologija u softverske organizacije" и "Okvir za procjenu softverskih tehnologija", ali čini mi se da je to nepotrebno kompliciranje.

Mnoge tehnologije mogu se inteligentno procijeniti postavljanjem samo dva osnovna pitanja. Problem je pronaći ljude koji na njih mogu odgovoriti odgovorno, odvojiti vrijeme da pronađu odgovore i bez predrasuda.

Ako nemate problema, ne treba vam novi alat. Točka.

Pitanje 1: Koje probleme pokušavam riješiti?

Ako nemate problema, ne treba vam novi alat. Točka. Nema potrebe tražiti rješenje pa izmišljati problem. Osim ako ste naišli na problem koji nova tehnologija rješava značajno bolje od vaše postojeće tehnologije, ovdje nema o čemu raspravljati. Ako razmišljate o korištenju ove tehnologije jer ste vidjeli da je drugi koriste, razmislite s kakvim se problemima oni suočavaju i pitajte ih imate li vi. Lako je prihvatiti tehnologiju jer je drugi koriste, izazov je razumjeti suočavate li se s istim problemima.

Pitanje 2: Što mi nedostaje?

Ovo je definitivno teže pitanje jer ćete morati kopati i dobro razumjeti i staru i novu tehnologiju. Ponekad ne možete razumjeti nešto novo sve dok s njim ne izgradite nešto ili dok nemate nekoga s takvim iskustvom.

Ako nemate ni jedno ni drugo, onda ima smisla razmisliti o minimalnom mogućem ulaganju kako biste odredili vrijednost ovog instrumenta. I kada jednom uložite, koliko će biti teško poništiti odluku?

Ljudi uvijek sve pokvare

Dok pokušavate odgovoriti na ova pitanja što je moguće nepristranije, zapamtite jednu stvar: morat ćete se boriti protiv ljudske prirode. Postoji niz kognitivnih predrasuda koje je potrebno prevladati kako bi se tehnologija učinkovito ocijenila. Evo samo nekoliko:

• Učinak pridruživanja većini - svi znaju za njega, ali još uvijek je teško boriti se protiv njega. Samo se pobrinite da tehnologija doista odgovara vašim stvarnim potrebama.
• Učinak novosti — Mnogi programeri skloni su podcijeniti tehnologije s kojima su dugo radili i precijeniti prednosti nove tehnologije. Ne radi se samo o programerima, svi su podložni ovoj kognitivnoj pristranosti.
• Učinak pozitivnih karakteristika - Skloni smo vidjeti što postoji, a izgubiti iz vida ono što nedostaje. To može dovesti do kaosa u kombinaciji s učinkom novine, budući da ne samo da precijenjujete novu tehnologiju, već i zanemarujete njezine nedostatke.

Objektivna procjena nije laka, ali razumijevanje temeljnih kognitivnih predrasuda pomoći će vam da donesete racionalnije odluke.

Rezime

Kad god se pojavi neka inovacija, potrebno je pažljivo odgovoriti na dva pitanja:

• Rješava li ovaj alat pravi problem?
• Razumijemo li dobro kompromise?

Ako ne možete sa sigurnošću odgovoriti na ova dva pitanja, odmaknite se nekoliko koraka i razmislite.

Je li MongoDB uopće bio pravi izbor? Naravno da; Kao i kod većine inženjerskih tehnologija, ovo ovisi o mnogim čimbenicima. Među onima koji su odgovorili na ova dva pitanja, mnogi su imali koristi od MongoDB-a i nastavljaju to činiti. Za one koji nisu, nadam se da ste naučili vrijednu i ne previše bolnu lekciju o kretanju kroz hype ciklus.

Odricanje

Želim pojasniti da s MongoDB-om nemam ni ljubav ni mržnju. Jednostavno nismo imali probleme za koje je MongoDB najprikladniji. Znam da 10gen/MongoDB Inc. isprva je bio vrlo hrabar, postavljajući nesigurne zadane postavke i promovirajući MongoDB posvuda (osobito na hackathonima) kao univerzalno rješenje za rad s bilo kojim podacima. Vjerojatno je to bila loša odluka. Ali potvrđuje ovdje opisani pristup: ti se problemi mogu otkriti vrlo brzo čak i uz površnu procjenu tehnologije.

Izvor: www.habr.com