Nedavno sam to saznao Red Hat uklanja podršku za MongoDB sa Satellite-a (kažu zbog promjena licence). Ovo me je navelo na razmišljanje jer sam u posljednjih nekoliko godina vidio gomilu članaka o tome koliko je MongoDB užasan i kako ga niko nikada ne bi trebao koristiti. Ali tokom ovog vremena, MongoDB je postao mnogo zreliji proizvod. Šta se desilo? Je li sva mržnja zaista posljedica grešaka u ranom marketingu novog DBMS-a? Ili ljudi jednostavno koriste MongoDB na pogrešnim mjestima?

Ako se osjećate kao da branim MongoDB, pročitajte odricanje od odgovornosti na kraju članka.

Novi trend

Radim u softverskoj industriji više godina nego što mogu reći, ali sam još uvijek bio izložen samo malom dijelu trendova koji su pogodili našu industriju. Bio sam svjedok uspona 4GL, AOP, Agile, SOA, Web 2.0, AJAX, Blockchain... lista je beskonačna. Svake godine se pojavljuju novi trendovi. Neki brzo nestaju, dok drugi suštinski menjaju način na koji se softver razvija.

Svaki novi trend stvara opšte uzbuđenje: ljudi ili skaču na brod, ili vide buku koju stvaraju drugi i prate gomilu. Ovaj proces je kodificirao Gartner u hype ciklus. Iako kontroverzna, ova vremenska linija grubo opisuje šta se dešava sa tehnologijama pre nego što one na kraju postanu korisne.

Ali s vremena na vrijeme se pojavi nova inovacija (ili ima drugi dolazak, kao u ovom slučaju) vođena samo jednom specifičnom implementacijom. U slučaju NoSQL-a, hype je u velikoj mjeri vođen pojavom i brzim usponom MongoDB-a. MongoDB nije pokrenuo ovaj trend: u stvari, velike internet kompanije počele su da imaju problema sa obradom velikih količina podataka, što je dovelo do vraćanja nerelacionih baza podataka. Sveukupni pokret započeo je projektima kao što su Google Bigtable i Facebook Cassandra, 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 sa kolonskim bazama podataka, skladištima ključeva/vrijednosti ili bilo kojim od brojnih drugih tipova skladišta podataka koji potpadaju pod opću NoSQL definiciju. I u pravu si. Ali u to vrijeme je vladao haos. Svi su opsjednuti NoSQL-om, postao je svako apsolutno neophodno, iako mnogi ne vide razlike u različitim tehnologijama. Za mnoge je MongoDB postao sinonim za NoSQL.

I programeri su nasrnuli na to. Ideja o bazi podataka bez šeme koja se magično povećava kako bi riješila bilo koji problem bila je prilično primamljiva. Oko 2014. godine, činilo se da su svuda gdje je prije godinu dana koristila relaciona baza podataka kao što je MySQL, Postgres ili SQL Server počeli da postavljaju MongoDB baze podataka. Na pitanje zašto, mogli biste dobiti odgovor od banalnog "ovo je razmjer weba" do promišljenijeg "moji podaci su vrlo labavo strukturirani i dobro se uklapaju u bazu podataka bez šeme".

Važno je zapamtiti da MongoDB, i baze podataka dokumenata općenito, rješavaju brojne probleme s tradicionalnim relacijskim bazama podataka:

• Stroga shema: Sa relacijskom bazom podataka, ako imate dinamički generirane podatke, prisiljeni ste ili kreirati gomilu nasumičnih "raznih" stupaca podataka, ugurati mrvice podataka u njih ili koristiti konfiguraciju EAV...sve ovo ima značajne nedostatke.
• Poteškoće u skaliranju: Ako ima toliko podataka da ne stane na jedan server, MongoDB je ponudio mehanizme koji im omogućavaju da se skaliraju na više mašina.
• Kompleksne modifikacije kola: nema migracija! U relacijskoj bazi podataka, promjena strukture baze podataka može biti veliki problem (naročito kada ima puno podataka). MongoDB je bio u mogućnosti da uvelike pojednostavi proces. I to je to učinilo tako lakim da možete jednostavno ažurirati kolo dok idete i nastaviti vrlo brzo.
• Performanse snimanja: MongoDB performanse su bile dobre, posebno kada je pravilno konfigurisan. Čak je i MongoDB-ova gotova konfiguracija, zbog koje je često bio kritikovan, pokazala neke impresivne brojke performansi.

Svi rizici su na vama

Potencijalne prednosti MongoDB-a bile su ogromne, posebno za određene klase problema. Ako pročitate gornju listu bez razumijevanja konteksta i bez iskustva, možete steći utisak da je MongoDB zaista revolucionarni DBMS. Jedini problem je bio taj što su gore navedene prednosti dolazile sa nizom upozorenja, od kojih su neka navedena u nastavku.

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

• Izgubljene transakcije: Transakcije su osnovna karakteristika mnogih relacionih baza podataka (ne svih, ali većine). Transakcijsko znači da možete izvoditi više operacija atomski i možete osigurati da podaci ostanu konzistentni. Naravno, sa NoSQL bazom podataka, transakcija može biti unutar jednog dokumenta, ili možete koristiti dvofazna urezivanja da biste dobili transakcionu semantiku. Ali morat ćete sami implementirati ovu funkcionalnost... što može biti težak i dugotrajan zadatak. Često ne shvaćate da postoji problem sve dok ne vidite da podaci u bazi podataka završe u nevažećim stanjima jer se atomičnost operacija ne može garantirati. 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 relacionog integriteta (strani ključevi): Ako vaši podaci imaju veze, onda ćete ih morati primijeniti u aplikaciji. Posjedovanje baze podataka koja poštuje ove odnose će oduzeti dosta posla aplikaciji, a time i vašim programerima.
• Nedostatak mogućnosti primjene strukture podataka: Stroge šeme ponekad mogu biti veliki problem, ali su i moćan mehanizam za dobro strukturiranje podataka ako se koriste mudro. Baze podataka kao što je MongoDB pružaju nevjerovatnu fleksibilnost sheme, ali ova fleksibilnost uklanja odgovornost za održavanje podataka čistima. Ako ne vodite računa o njima, na kraju ćete napisati mnogo koda u svojoj aplikaciji kako biste uračunali podatke koji nisu pohranjeni u obliku koji očekujete. Kao što često kažemo u našoj kompaniji Simple Thread... aplikacija će jednog dana biti prepisana, ali podaci će živjeti zauvijek. Napomena: MongoDB podržava provjeru šeme: korisna je, ali ne pruža iste garancije kao u relacijskoj bazi podataka. Prije svega, dodavanje ili promjena provjere sheme ne utječe na postojeće podatke u kolekciji. Na vama je da osigurate da ažurirate podatke prema novoj šemi. Odlučite sami da li je ovo dovoljno za vaše potrebe.
• Izvorni jezik upita / gubitak ekosistema alata: Pojava SQL-a bila je apsolutna revolucija i od tada se ništa nije promijenilo. To je nevjerovatno moćan jezik, ali i prilično složen. Potrebu za konstruisanjem upita baze podataka na novom jeziku koji se sastoji od JSON fragmenata ljudi koji imaju iskustva u radu sa SQL-om smatraju velikim korakom unazad. Postoji čitav univerzum alata koji komuniciraju sa SQL bazama podataka, od IDE-a do alata za izvještavanje. 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, pa su često zaronili glavom u to da ga instaliraju kao svoju primarnu pohranu podataka. Nakon ovoga je često bilo neverovatno teško vratiti se.

Šta se moglo učiniti drugačije?

Nisu svi skočili glavom i udarili u dno. Ali mnogi projekti su instalirali MongoDB na mjestima gdje se jednostavno nije uklapao – i morat će živjeti s njim dugi niz godina. Da su ove organizacije provele neko vrijeme i metodično razmišljale o svojim tehnološkim izborima, mnoge bi donijele drugačije izbore.

Kako odabrati pravu tehnologiju? Bilo je nekoliko pokušaja da se stvori sistematski okvir za procjenu tehnologije, kao npr "Okvir za uvođenje tehnologija u softverske organizacije" и "Okvir za procjenu softverskih tehnologija", ali čini mi se da je to nepotrebna kompleksnost.

Mnoge tehnologije se mogu inteligentno procijeniti postavljanjem samo dva osnovna pitanja. Problem je pronaći ljude koji mogu odgovorno odgovoriti na njih, odvojiti vrijeme za pronalaženje odgovora i bez pristrasnosti.

Ako se ne suočavate s bilo kakvim problemom, ne treba vam novi alat. Dot.

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

Ako se ne suočavate s bilo kakvim problemom, ne treba vam novi alat. Dot. Nema potrebe tražiti rješenje, a zatim izmišljati problem. Osim ako niste naišli na problem koji nova tehnologija rješava znatno bolje od 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 kojim se problemima susreću i pitajte imate li te probleme. Lako je prihvatiti tehnologiju jer je drugi koriste, izazov je razumjeti da li se i vi suočavate s istim problemima.

Pitanje 2: Šta mi nedostaje?

Ovo je definitivno teže pitanje jer ćete morati da se udubite i dobro razumete i staru i novu tehnologiju. Ponekad ne možete zaista razumjeti novi dok ne izgradite nešto s njim ili imate nekoga s tim 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 uvek sve pokvare

Dok pokušavate što nepristrasnije odgovoriti na ova pitanja, zapamtite jednu stvar: morat ćete se boriti protiv ljudske prirode. Postoji niz kognitivnih predrasuda koje se moraju prevazići da bi se tehnologija efektivno procenila. Evo samo nekoliko:

• Efekat pridruživanja većini - svi znaju za njega, ali je i dalje teško boriti se protiv njega. Samo se pobrinite da tehnologija zaista odgovara vašim stvarnim potrebama.
• Efekat noviteta — Mnogi programeri imaju tendenciju da potcjenjuju tehnologije s kojima rade dugo vremena i precjenjuju prednosti nove tehnologije. Nisu samo programeri, svi su podložni ovoj kognitivnoj pristranosti.
• Utjecaj pozitivnih karakteristika - Skloni smo da vidimo šta ima i izgubimo iz vida ono što nedostaje. Ovo može dovesti do haosa kada se kombinuje sa efektom noviteta, jer ne samo da inherentno precenjujete novu tehnologiju, već i ignorišete njene nedostatke.

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

Rezime

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

• Da li ovaj alat rješava stvarni problem?
• Razumijemo li dobro kompromise?

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

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

Odricanje od odgovornosti

Želim da pojasnim da nemam ni ljubav ni odnos mržnje sa MongoDB-om. Jednostavno nismo imali probleme za koje bi MongoDB najbolje odgovarao. Znam da 10gen/MongoDB Inc. u početku je bio vrlo hrabar, postavljajući nesigurne zadane postavke i promovirajući MongoDB svuda (posebno na hakatonima) kao univerzalno rješenje za rad sa bilo kojim podacima. Vjerovatno je to bila loša odluka. Ali to potvrđuje pristup koji je ovdje opisan: ovi problemi mogu se vrlo brzo otkriti čak i uz površnu procjenu tehnologije.

izvor: www.habr.com