Nedavno sam saznao da (kažu, zbog promena u licenciranju). To me navelo na razmišljanje o tome da sam u poslednjih nekoliko godina video gomilu članaka o tome koliko je MongoDB strašna i da je niko nikada ne bi trebao koristiti. Ali tokom tog vremena, MongoDB je postala mnogo zreliji proizvod. Šta se zapravo dogodilo? Da li je sav taj mržnja posledica grešaka na početku marketinga nove DBMS? Ili ljudi jednostavno koriste MongoDB na pogrešnim mestima?
Ako vam se slučajno čini da branim MongoDB, molim vas da pročitate na kraju članka.
Novi trend
Radim u softverskoj industriji više godina nego što je prikladno reći, ali mi je i dalje pripala samo mala količina trendova koji su pogodili našu industriju. Bio sam svedok porasta 4GL, AOP, Agile, SOA, Web 2.0, AJAX, blockchaina... lista je beskrajna. Svake godine se pojavljuju nove tendencije. Neke brzo nestanu, dok druge suštinski menjaju načine razvoja softvera.
Oko svakog novog trenda stvara se neka vrsta opšteg uzbuđenja: ljudi ili sami skaču u čamac, ili vide buku koju generišu drugi — i prate masu. Ovaj proces je kodifikovan od strane kompanije Gartner u . Iako sporan, ovaj grafikon otprilike opisuje šta se zbiva s tehnologijama pre nego što konačno postanu korisne za upotrebu.
Ali s vremena na vreme pojavljuje se (ili se dešava drugo vraćanje, kao u ovom slučaju) nova inovacija, vođena samo jednom konkretnom njenom realizacijom. U slučaju NoSQL, hype je bio snažno uslovljen pojavom i brzim usponom MongoDB. Nije MongoDB pokrenula ovaj trend: zapravo, veliki internet kompanije su se suočavali sa problemima u obradi velikih količina podataka, što je dovelo do ponovnog pojavljivanja nerelacionih DB. Opšti pokret je započeo sa projektima kao što su Bigtable od Google-a i Cassandra od Facebook-a, ali je upravo MongoDB postala najpoznatija i najpristupačnija realizacija NoSQL baze podataka, kojoj su većina programera imala pristup.
Napomena: možete pomisliti da mešam dokumentne DB sa kolumnarnim DB, skladištima ključ/vrednost ili bilo kojim od mnogih drugih tipova skladišta podataka koji spadaju pod opštu definiciju NoSQL. I u pravu ste. Ali tada je vladala pometnja. Svi su se opsedali s NoSQL, svima je to postalo apsolutno je potrebno, iako mnogi nisu primijetili razlike među različitim tehnologijama. Za mnoge je MongoDB postala sinonim NoSQL.
I programeri su brzo počeli da je koriste. Ideja o bazi podataka bez šeme, koja se magično skalira za rješavanje bilo kojeg problema, bila je vrlo primamljiva. Oko 2014. godine činilo se da svuda gdje je prije godine korištena relacijska baza podataka, poput MySQL-a, Postgres-a ili SQL Server-a, postavljaju MongoDB baze. Na pitanje zašto, mogli ste dobiti odgovor od banalnog „to je skaliranje weba” do promišljenijeg „moji podaci su vrlo slabo strukturirani i dobro se uklapaju u bazu podataka bez šeme”.
Važno je imati na umu da MongoDB i baze podataka dokumenata u cjelini rješavaju niz problema s tradicionalnim relacijskim bazama podataka:
- Stroga šema: s relacijskom bazom podataka, ako imate dinamički proizvedene podatke, prisiljeni ste ili da kreirate gomilu nasumičnih „različitih” kolona podataka, ugurate blobove podataka ili upotrijebite konfiguraciju … sve to ima značajne nedostatke.
- Teškoće u skaliranju: ako je podataka toliko da ne staju na jedan server, MongoDB je pružala mehanizme koji su omogućili da ih skalirate na više mašina.
- Složene modifikacije šeme: nikakve migracije! U relacijskim bazama podataka, promjena strukture BDP-a može postati ogroman problem (posebno kada podataka postane vrlo mnogo). MongoDB je uspjela značajno pojednostaviti proces. I učinila ga toliko lakim da možete jednostavno ažurirati šemu u hodu i vrlo brzo ići dalje.
- Performanse pisanja: performanse MongoDB su bile dobre, posebno uz pravilnu konfiguraciju. Čak je i MongoDB konfiguracija iz kutije, za koju su je često kritikovali, pokazivala neke impresivne performanse.
Svi rizici su na vama
Potencijalne prednosti MongoDB-a bile su ogromne, posebno za određene klase problema. Ako pročitate gornji popis bez razumijevanja konteksta i nemajući iskustva, može se steći utisak da je MongoDB zaista revolucionarna SDB. Jedini problem je bio taj što su navedene prednosti bile praćene nizom rezervi, od kojih su neke navedene u nastavku.
Pošteno rečeno, niko u 10gen/MongoDB Inc. ne bi rekao da je ono što sledi neistina, to su jednostavno kompromisi.
- Gubitak transakcija: transakcije su osnovna karakteristika mnogih relacionih baza podataka (ne svih, ali većine). Transakcionost znači da možete izvršavati više operacija atomarno i možete garantovati da će podaci ostati dosledni. Naravno, u NoSQL bazi podataka transakcionost može biti unutar jednog dokumenta ili možete koristiti dvostruke faze commit-a da postignete transakcionu semantiku. Ali ćete morati sami implementirati ovu funkcionalnost… što može biti složen i zahtevan zadatak. Često ne shvatate problem dok ne vidite da podaci u bazi podataka upadaju u nedopustiva stanja, jer nije moguće garantovati atomarnost operacija. Napomena: mnogi su mi rekli da su u MongoDB 4.0 prošle godine uvedene transakcije, ali sa nizom ograničenja. Zaključak iz članka ostaje isti: procenite koliko tehnologija odgovara vašim potrebama.
- Gubitak relacionih integriteta (spoljni ključevi): ako u vašim podacima postoje odnosi, onda ćete ih morati primeniti u aplikaciji. Imati bazu podataka koja poštuje ove odnose će značajno smanjiti posao u aplikaciji i, samim tim, rad vaših programera.
- Nedostatak mogućnosti primene strukture podataka: stroge sheme ponekad predstavljaju veliki problem, ali to je takođe i moćan mehanizam za dobro strukturisanje podataka, ako se pravilno koriste. Dokumentne baze podataka, kao što je MongoDB, pružaju neverovatnu fleksibilnost sheme, ali ta fleksibilnost skida odgovornost za održavanje podataka u čistom stanju. Ako se ne pobrinete za njih, na kraju ćete morati da napišete mnogo koda u aplikaciji da uzmete u obzir podatke koji se čuvaju u formi koju ne očekujete. Kao što često kažu u našoj kompaniji Simple Thread… aplikaciju će jednom prepisati, a podaci će živeti zauvek. Opomba: MongoDB podpira preverjanje sheme: to je koristno, vendar ne zagotavlja enakih garancij kot relacijska baza podatkov. Predvsem dodajanje ali sprememba preverjanja sheme ne vpliva na obstoječe podatke v zbirki. Sami se morate prepričati, da posodabljate podatke v skladu z novo shemo. Odločite se, ali je to dovolj za vaše potrebe.
- Domači jezik poizvedb / izguba ekosistema orodij: pojav SQL-a je bil popolna revolucija, od takrat pa se ni spremenilo nič. To je izjemno močan jezik, a tudi precej zapleten. Potreba po oblikovanju poizvedb v bazi podatkov v novem jeziku, ki je sestavljen iz delov JSON, se smatra za velik korak nazaj s strani ljudi, ki imajo izkušnje s SQL. Obstaja cela vesoljska orodij, ki delujejo s SQL bazami podatkov: od IDE-jev do orodij za poročanje. Prehod na bazo podatkov, ki ne podpira SQL, pomeni, da ne morete uporabljati večine teh orodij ali pa morate prenesti podatke v SQL, da bi jih lahko uporabili, kar se lahko izkaže za bolj zapleteno, kot mislite.
Številni razvijalci, ki so se lotili MongoDB, niso prav dobro razumeli kompromisov in so pogosto skočili z glavo vanjo, jo namestili kot glavno podatkovno skladišče. Po tem je bilo izjemno težko vrniti se nazaj.
Kaj bi lahko naredili drugače?
Niso vsi skočili s polno glavo in prileteli na dno. Vendar je veliko projektov namestilo bazo MongoDB na mesto, kjer preprosto ni bila primerna – in s tem se bodo morali spoprijeti še dolgo. Če bi te organizacije namenile nekaj časa in premišljeno razmislile o izbiri tehnologij, bi marsikdo naredil drugačno izbiro.
Kako izbrati primerno tehnologijo? Bile so nekatere poskusi za ustvarjanje sistematičnega okvira za ocenjevanje tehnologij, kot so in , vendar se mi zdi, da je to odvečna kompleksnost.
Mnogo tehnologij je mogoče razumljivo oceniti, če postavimo le dva osnovna vprašanja. Težava je v iskanju ljudi, ki lahko nanju odgovorno odgovorijo, in so pripravljeni porabiti čas za iskanje odgovorov ter to storiti brez pristranskosti.
Če se ne soočate s kakršnokoli težavo, nimate potrebnega novega orodja. Pika.
Vprašanje 1: Katere težave poskušam rešiti?
Če se ne soočate s kakšno težavo, potem nova orodja ne potrebujete. Točka. Ni treba iskati rešitev in si nato izmisliti težave. Če niste naleteli na težavo, ki je nova tehnologija ne rešuje bistveno bolje od vaše obstoječe tehnologije, potem tu ni ničesar za razpravljanje. Če razmišljate o uporabi te tehnologije, ker ste videli, da jo uporabljajo drugi, se vprašajte, s katerimi težavami se srečujejo, in preverite, ali imate podobne težave. Enostavno je sprejeti tehnologijo, ker jo uporabljajo drugi, težava pa je razumeti, ali se soočate s podobnimi težavami.
Vprašanje 2: Česa sem prikrajšan?
To je zagotovo težje vprašanje, saj bo treba podrobno razmisliti in dobro razumeti tako staro kot novo tehnologijo. Včasih ne morete resnično razumeti nove, dokler ne zgradite nečesa z njo ali dokler ne zaposlite nekoga, ki ima takšne izkušnje.
Če nimate ne enega ne drugega, ima smisel razmisliti o minimalnih investicijah za oceno vrednosti tega orodja. In če se odločite za investicije, kako težko bo preklicati odločitev?
Ljudje vedno vse pokvarijo
Pri poskusu odgovarjanja na ta vprašanja kolikor je mogoče nepristransko, imejte v mislih eno stvar: borili se boste s človeško naravo. Obstaja vrsta kognitivnih pristranskosti, ki jih je treba premagati za učinkovito oceno tehnologije. Tukaj je le nekaj:
- — vsi vedo zanj, a se ga je vseeno težko znebiti. Prepričajte se, da tehnologija resnično ustreza vašim realnim potrebam.
- — mnogi razvijalci pogosto podcenjujejo tehnologije, s katerimi so delali dalj časa, in precenjujejo prednosti nove tehnologije. Ne le programerji, vsi smo podvrženi tej kognitivni pristranskosti.
- — nagnjeni smo, da vidimo tisto, kar je, in spregledamo tisto, česar ni. To lahko povzroči zmedo v kombinaciji z učinkom novosti, saj ne le da v osnovi precenjujete novo tehnologijo, temveč tudi ignorirate njene pomanjkljivosti..
Ob客ija ocena ni enostavna, vendar razumevanje osnovnih kognitivnih pristranskosti pomaga sprejemati bolj racionalne odločitve.
Резюме
Ko se pojavi neka inovacija, je treba z veliko previdnostjo odgovoriti na dve vprašanja:
- Ali ta instrument rešuje resnično težavo?
- Ali dobro razumemo kompromise?
Če na ti dve vprašanji ne morete samozavestno odgovoriti, naredite nekaj korakov nazaj in premislite.
Ali je bila MongoDB sploh pravilen izbor? Seveda, da; kot pri večini inženirskih tehnologij, je to odvisno od številnih dejavnikov. Med tistimi, ki so si odgovorili na ti dve vprašanji, jih je veliko pridobilo koristi iz MongoDB in jih še naprej pridobiva. Tisti, ki niso, upam, da so dobili dragoceno in ne preveč boleče lekcijo o gibanju po ciklu hipe.
Omejitev odgovornosti
Želim pojasniti, da nimam ne ljubezni ne sovraštva do MongoDB. Preprosto nismo imeli takšnih težav, za katere bi bila MongoDB najboljša izbira. Vem, da je 10gen/MongoDB Inc. sprva deloval zelo drzni, z nastavitvijo nesigurnih privzetih vrednosti in spodbujanjem MongoDB povsod (še posebej na hackathonih) kot univerzalne rešitve za delo z vsemi podatki. Verjetno je to bila slaba odločitev. Ampak to potrjuje opisani pristop: te težave je bilo mogoče zelo hitro odkriti tudi pri površinski oceni tehnologije.
Izvor: habr.com
