Nedavno sam saznao da (kažu, zbog promjena licence). To me natjeralo na razmišljanje jer sam u posljednjih nekoliko godina vidio mnoge članke kako je MongoDB užasna i da je nitko nikada ne bi trebao koristiti. No, tijekom tog vremena, MongoDB je postala mnogo zreliji proizvod. Što se dogodilo? Je li sva ta mržnja uzrokovana greškama u početnom marketingu nove DBMS? Ili ljudi jednostavno koriste MongoDB na krivim mjestima?
Ako vam se ikada učinilo da branim MongoDB, molim vas pročitajte na kraju članka.
Novi trend
Radim u softverskoj industriji više godina nego što je pristojno reći, ali je svejedno samo mali dio trendova prošao kroz našu industriju. Bio sam svjedok rasta 4GL, AOP, Agile, SOA, Web 2.0, AJAX, blockchaina… popis je beskrajan. Svake godine se pojavljuju nove tendencije. Neki brzo nestaju, dok drugi bitno mijenjaju načine razvoja softvera.
Oko svakog novog trenda stvara se neko opće uzbuđenje: ljudi ili sami skaču u čamac ili vide buku koju generiraju drugi — i idu za masom. Ovaj proces je kodificiran od strane tvrtke Gartner u . Iako je sporan, ovaj graf otprilike opisuje što se događa s tehnologijama prije nego što na kraju postanu korisne.
Ali s vremena na vrijeme pojavljuje se (ili doživljava drugo dolazak, kao u ovom slučaju) nova inovacija, vođena samo jednom određenom njenom implementacijom. U slučaju NoSQL, hype je bio jako uvjetovan pojavom i brzim rastom MongoDB-a. Ne MongoDB je započela ovaj trend: zapravo, velike internetske tvrtke su započele imati problema s obradom velikih količina podataka, što je dovelo do povratka nerelacijskih baza podataka. Opći pokret započeo je s takvim projektima kao što su Bigtable od Googlea i Cassandra od Facebooka, no upravo je MongoDB postala najpoznatija i najpristupačnija NoSQL baza podataka kojoj su većina programera imala pristup.
Napomena: možete pomisliti da miješam dokumentne baze podataka s kolonama, skladištima ključ/vrijednost ili bilo kojim od mnogih drugih vrsta skladišta podataka koje spadaju pod opću definiciju NoSQL. I u pravu ste. No, tada je vladala zbrka. Svi su bili opsjednuti NoSQL-om, svima je postalo apsolutno bilo je potrebno, iako mnogi nisu primijetili razlike među različitim tehnologijama. Za mnoge, MongoDB je postala sinonim NoSQL.
A programeri su se bacili na nju. 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 se svugdje gdje je prije godinu dana korištena relacionalna baza podataka, poput MySQL-a, Postgres-a ili SQL Server-a, implementiraju MongoDB baze. Na pitanje zašto, mogli ste dobiti odgovor od banalne 'to je skaliranje weba' do promišljenijeg 'moji podaci su vrlo slabo strukturirani i dobro se uklapaju u bazu podataka bez sheme.'
Važno je zapamtiti da MongoDB i baze podataka dokumenata u cjelini rješavaju niz problema s tradicionalnim relacionalnim bazama podataka:
- Stroga shema: s relacionalnom bazom podataka, ako imate dinamički generirane podatke, prisiljeni ste ili stvoriti hrpu nasumičnih 'različitih' stupaca podataka, ugurati blobove podataka ili koristiti konfiguraciju … sve to ima značajne nedostatke.
- Težina skaliranja: ako je podataka toliko da ne stanu na jedan poslužitelj, MongoDB je nudila mehanizme koji omogućuju njihovo skaliranje na više mašina.
- Kompleksne izmjene sheme: nema migracija! U relacionalnoj bazi podataka, promjena strukture baze podataka može postati ogroman problem (osobito kada podaci postanu jako veliki). MongoDB je uspjela značajno pojednostaviti taj proces. I učinila ga toliko lakim da možete jednostavno ažurirati shemu u hodu i vrlo brzo napredovati.
- Performanse pisanja: performanse MongoDB bile su dobre, posebno uz pravilnu konfiguraciju. Čak je i konfiguracija MongoDB iz kutije, koju su često kritizirali, pokazivala neka impresivna mjerila performansi.
Sav rizik je na vama
Potencijalne prednosti MongoDB-a bile su ogromne, posebno za određene klase problema. Ako se pročita gornji popis bez razumijevanja konteksta i bez iskustva, mogla bi se steći dojam da je MongoDB zaista revolucionarna DBMS. Jedini problem bio je u tome što su navedene prednosti bile praćene nizom uvjetovanja, od kojih su neka navedena u nastavku.
Iskreno govoreći, nitko u 10gen/MongoDB Inc. neće reći da je ono što slijedi neistina, to su samo kompromisi.
- Gubitak transakcija: transakcije su osnovna značajka mnogih relacijskih baza podataka (ne svih, ali većine). Transakcionost znači da možete izvršavati više operacija atomarno i možete osigurati da će podaci ostati dosljedni. Naravno, u NoSQL bazi podataka, transakcionost može biti unutar jednog dokumenta ili možete koristiti dvofazne potvrde za postizanje transakcijske semantike. No, morat ćete sami implementirati tu funkcionalnost... što može biti složen i dugotrajan zadatak. Često niste svjesni problema dok ne vidite da podaci u bazi podataka dolaze u nedopuštena stanja jer nije moguće osigurati atomarnost operacija. Napomena: mnogi su mi rekli da su u MongoDB 4.0 prošle godine uvedene transakcije, ali s brojnim ograničenjima. Zaključak članka ostaje isti: procijenite koliko tehnologija odgovara vašim potrebama.
- Gubitak relacijske cjelovitosti (vanjski ključevi): ako vaši podaci imaju odnose, morat ćete ih primijeniti u aplikaciji. Imati bazu podataka koja poštuje te odnose uklanja značajan dio posla iz aplikacije, a time i s vaših programera.
- Nedostatak mogućnosti primjene strukture podataka: stroge sheme ponekad postaju veliki problem, ali to je također moćan mehanizam za dobro strukturiranje podataka ako se pravilno koristi. Dokumentne baze podataka kao što je MongoDB pružaju nevjerojatnu fleksibilnost sheme, ali ta fleksibilnost skida odgovornost za održavanje podataka u čistom obliku. Ako se ne brinete o njima, na kraju ćete morati napisati puno koda u aplikaciji kako biste uzeli u obzir podatke koji se čuvaju u obliku koji ne očekujete. Kao što često kažemo u našoj tvrtki Simple Thread… aplikaciju će nekad ponovno napisati, a podaci će živjeti vječno. Napomena: MongoDB podržava provjeru sheme: korisna je, ali ne pruža iste garancije kao relacijska baza podataka. Prije svega, dodavanje ili promjena provjere sheme ne utječe na postojeće podatke u kolekciji. Morate osigurati da ažurirate podatke u skladu s novom shemom. Odlučite sami je li to dovoljno za vaše potrebe.
- Vlastiti 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. Potreba za konstruiranjem upita za bazu podataka na novom jeziku, koji se sastoji od dijelova JSON-a, smatra se velikim korakom unazad za ljude koji imaju iskustva s SQL-om. Postoji cijeli svemir alata koji surađuju s SQL bazama podataka: od IDE-a do alata za izvještavanje. Prijelaz na bazu podataka koja ne podržava SQL znači da ne možete koristiti većinu tih alata ili morate prevesti podatke u SQL kako biste ih koristili, a to bi moglo biti teže nego što mislite.
Mnogi programeri koji su prešli na MongoDB nisu potpuno razumjeli kompromise i često su se u nju upletali s glavom, postavljajući je kao glavno skladište podataka. Nakon toga je često bilo nevjerojatno teško vratiti se nazad.
Što se moglo učiniti drugačije?
Ne skoči svi s glavom naprijed i ne udaraju u dno. No mnogi projekti postavili su MongoDB na mjesta gdje jednostavno nije odgovarala - i morat će s njom živjeti još mnogo godina. Da su te organizacije potrošile neko vrijeme i sustavno razmislile o izboru tehnologija, mnogi bi napravili drugačiji izbor.
Kako odabrati odgovarajuću tehnologiju? Bilo je nekoliko pokušaja da se stvori sustavni okvir za procjenu tehnologija, poput i , ali mislim da je to suvišna složenost.
Mnoge tehnologije se mogu razumno procijeniti postavljanjem samo dva osnovna pitanja. Problem leži u pronalaženju ljudi koji mogu odgovorno odgovoriti na njih, trošeći vrijeme na traženje odgovora i bez pristranosti.
Ako se ne suočavate s nekim problemom, ne treba vam novi alat. Točka.
Pitanje 1: Koje probleme pokušavam riješiti?
Ako se ne suočavate s nekim problemom, ne trebate novi alat. Točka. Nema potrebe tražiti rješenje, a zatim smišljati problem. Ako se ne suočavate s problemom koji nova tehnologija ne rješava znatno bolje od vaše postojeće tehnologije, onda ovdje nemamo o čemu razgovarati. Ako razmišljate o korištenju ove tehnologije jer ste vidjeli kako je koriste drugi, razmislite o problemima s kojima se oni suočavaju i pitajte se imate li takve probleme. Lako je prihvatiti tehnologiju samo zato što je koriste drugi, ali pravi izazov je razumjeti imate li iste probleme.
Pitanje 2: Čega se odričem?
Ovo je zasigurno teže pitanje jer ćete morati dublje zaroniti i dobro razumjeti kako staru, tako i novu tehnologiju. Ponekad ne možete doista razumjeti novu tehnologiju dok ne izgradite nešto pomoću nje ili dok ne dobijete zaposlenika s tim iskustvom.
Ako nemate ni jedno ni drugo, ima smisla razmisliti o minimalnim mogućim ulaganjima kako biste odredili vrijednost ovog alata. I ako napravite ulaganje, koliko će biti teško povući odluku?
Ljudi uvijek sve pokvare
Pokušavajući odgovoriti na ova pitanja što je moguće nepristranije, imajte na umu jednu stvar: morat ćete se boriti protiv ljudske prirode. Postoji niz kognitivnih predrasuda koje treba prevazići kako biste učinkovito procijenili tehnologiju. Evo samo nekih od njih:
- — svi znaju za to, ali se s njim i dalje teško boriti. Samo se uvjerite da tehnologija doista odgovara vašim stvarnim potrebama.
- — mnogi programeri imaju tendenciju da podcjenjuju tehnologije s kojima su dugo radili, a precjenjuju prednosti nove tehnologije. Ne samo programeri, svi su podložni ovom kognitivnom deformitetu.
- — imamo tendenciju vidjeti ono što postoji i zanemariti ono što nedostaje. To može dovesti do haosa u kombinaciji s efektom novosti, jer ne samo da naturalno precjenjujete novu tehnologiju, već i ignorirate njezine nedostatke..
Objektivna ocjena nije jednostavna, ali razumijevanje osnovnih kognitivnih zabluda može pomoći pri donošenju razumnijih odluka.
Sažetak
Kada se pojavljuje neka inovacija, važno je s velikim oprezom odgovoriti na dva pitanja:
- Rješava li ovaj alat stvarni problem?
- Dobro li razumijemo kompromis?
Ako ne možete sigurno odgovoriti na ova dva pitanja, napravite nekoliko koraka unatrag i promislite.
Je li MongoDB bio pravi izbor? Naravno da jest; kao i kod većine inženjerskih tehnologija, to ovisi o mnogim faktorima. Mnogi koji su odgovorili na ova dva pitanja imali su koristi od MongoDB i nastavljaju imati. Tko nije, nadam se da je stekao vrijednu i ne previše bolnu lekciju o ciklusu hype-a.
Odricanje
Želim naglasiti da nemam ljubavi ni mržnje prema MongoDB-u. Jednostavno nismo imali problema za koje bi MongoDB najbolje rješenje. Znam da je 10gen/MongoDB Inc. u početku djelovala vrlo hrabro, postavljajući nesigurne zadane vrijednosti i promovirajući MongoDB svugdje (osobito na hackathonima) kao univerzalno rješenje za rad s bilo kojim podacima. Vjerojatno je to bila loša odluka. No, to potvrđuje pristup opisan ovdje: ovi problemi mogli su se otkriti vrlo brzo čak i uz površnu procjenu tehnologije.
Izvor: habr.com
