Pred kratkim sem ugotovil, da Red Hat odstrani podporo za MongoDB iz Satellita (pravijo zaradi sprememb licence). To mi je dalo misliti, ker sem v zadnjih nekaj letih videl ogromno člankov o tem, kako grozen je MongoDB in kako ga nihče nikoli ne bi smel uporabljati. Toda v tem času je MongoDB postal veliko bolj zrel izdelek. Kaj se je zgodilo? Je vse sovraštvo res posledica napak pri zgodnjem trženju novega DBMS? Ali pa ljudje preprosto uporabljajo MongoDB na napačnih mestih?

Če menite, da branim MongoDB, prosim preberite zavrnitev odgovornosti na koncu članka.

Nov trend

V industriji programske opreme delam več let, kot lahko rečem, vendar sem bil še vedno izpostavljen le majhnemu delu trendov, ki so prizadeli našo industrijo. Bil sem priča vzponu 4GL, AOP, Agile, SOA, Web 2.0, AJAX, Blockchain ... seznam je neskončen. Vsako leto se pojavijo novi trendi. Nekateri hitro izzvenijo, drugi pa bistveno spremenijo način razvoja programske opreme.

Vsak nov trend povzroči splošno navdušenje: ljudje bodisi skočijo na krov ali opazijo hrup, ki ga ustvarjajo drugi, in sledijo množici. Ta postopek je kodificiral Gartner v hype cikel. Čeprav je sporna, ta časovnica v grobem opisuje, kaj se zgodi s tehnologijami, preden postanejo uporabne.

Toda od časa do časa se pojavi nova inovacija (ali pride drugič, kot v tem primeru), ki jo poganja samo ena specifična izvedba. V primeru NoSQL je navdušenje močno spodbudil pojav in meteorski vzpon MongoDB. MongoDB ni začel tega trenda: velika internetna podjetja so namreč začela imeti težave z obdelavo velikih količin podatkov, kar je privedlo do vrnitve nerelacijskih baz podatkov. Splošno gibanje se je začelo s projekti, kot sta Googlova Bigtable in Facebookova Cassandra, vendar je bil MongoDB tisti, ki je postal najbolj znana in dostopna implementacija baze podatkov NoSQL, do katere je imela dostop večina razvijalcev.

Opomba: Morda mislite, da zamenjujem baze podatkov dokumentov s stolpčnimi bazami podatkov, shrambami ključev/vrednosti ali katero koli od številnih drugih vrst shramb podatkov, ki spadajo pod splošno definicijo NoSQL. In imaš prav. Toda takrat je vladal kaos. Vsi so obsedeni z NoSQL, postali so vsi absolutno potrebno, čeprav mnogi niso videli razlik v različnih tehnologijah. Za mnoge je MongoDB postal sinonim za NoSQL.

In razvijalci so se lotili tega. Zamisel o zbirki podatkov brez sheme, ki se čarobno prilagaja za rešitev katere koli težave, je bila precej mamljiva. Okoli leta 2014 se je zdelo, da so povsod, kjer so pred letom dni uporabljali relacijske baze podatkov, kot so MySQL, Postgres ali SQL Server, začeli uvajati baze podatkov MongoDB. Na vprašanje, zakaj, lahko dobite odgovor od banalnega "to je obseg spleta" do bolj premišljenega "moji podatki so zelo ohlapno strukturirani in se dobro prilegajo bazi podatkov brez sheme."

Pomembno si je zapomniti, da MongoDB in dokumentne baze podatkov na splošno rešujejo številne težave s tradicionalnimi relacijskimi bazami podatkov:

• Stroga shema: Če imate pri relacijski bazi podatkov dinamično ustvarjene podatke, ste prisiljeni bodisi ustvariti kup naključnih "raznih" stolpcev podatkov, tja potisniti blob podatkov ali uporabiti konfiguracijo EAV razširitev... vse to ima precejšnje pomanjkljivosti.
• Težava pri skaliranju: Če je podatkov toliko, da se ne prilegajo enemu strežniku, je MongoDB ponudil mehanizme, ki omogočajo prilagajanje na več strojih.
• Kompleksne spremembe vezja: brez selitev! V relacijski bazi podatkov je lahko spreminjanje strukture baze podatkov velik problem (še posebej, če je podatkov veliko). MongoDB je lahko močno poenostavil postopek. In postalo je tako enostavno, da lahko vezje preprosto posodobite sproti in nadaljujete zelo hitro.
• Snemanje uspešnosti: Zmogljivost MongoDB je bila dobra, zlasti če je bila pravilno konfigurirana. Celo že pripravljena konfiguracija MongoDB, zaradi katere je bil pogosto kritiziran, je pokazala nekaj impresivnih številk zmogljivosti.

Vsa tveganja so vaša

Možne koristi MongoDB so bile ogromne, zlasti za določene vrste težav. Če berete zgornji seznam brez razumevanja konteksta in izkušenj, boste morda dobili vtis, da je MongoDB resnično revolucionaren DBMS. Edina težava je bila v tem, da so bile zgoraj navedene prednosti povezane s številnimi opozorili, od katerih so nekatera navedena spodaj.

Po pravici povedano, nihče pri 10gen/MongoDB Inc. ne bom rekel, da naslednje ne drži, to so le kompromisi.

• Izgubljene transakcije: Transakcije so ključna značilnost številnih relacijskih baz podatkov (ne vseh, a večine). Transakcijsko pomeni, da lahko izvedete več operacij atomsko in zagotovite, da podatki ostanejo dosledni. Seveda je z bazo podatkov NoSQL lahko transakcija v enem samem dokumentu ali pa lahko uporabite dvofazne potrditve, da dobite transakcijsko semantiko. Toda to funkcionalnost boste morali implementirati sami ... kar je lahko težka in dolgotrajna naloga. Pogosto se ne zavedate, da obstaja težava, dokler ne vidite, da so podatki v zbirki podatkov v neveljavnih stanjih, ker atomičnosti operacij ni mogoče zagotoviti. Opomba: veliko ljudi mi je povedalo, da je MongoDB 4.0 lansko leto predstavil transakcije, vendar z nekaterimi omejitvami. Ugotovitev iz članka ostaja enaka: ocenite, kako dobro tehnologija ustreza vašim potrebam.
• Izguba relacijske celovitosti (tuji ključi): Če imajo vaši podatki razmerja, jih boste morali uporabiti v aplikaciji. Imeti bazo podatkov, ki spoštuje ta razmerja, bo aplikacija in s tem vaši programerji vzela veliko dela.
• Pomanjkanje zmožnosti uporabe strukture podatkov: Stroge sheme so včasih lahko velika težava, vendar so tudi močan mehanizem za dobro strukturiranje podatkov, če jih uporabljamo pametno. Podatkovne baze dokumentov, kot je MongoDB, zagotavljajo neverjetno prilagodljivost shem, vendar ta prilagodljivost odpravlja odgovornost za ohranjanje čistosti podatkov. Če ne boste poskrbeli zanje, boste na koncu napisali veliko kode v svojo aplikacijo, da bi upoštevali podatke, ki niso shranjeni v obliki, kot jo pričakujete. Kot pogosto rečemo v našem podjetju Simple Thread ... aplikacija bo nekoč prepisana, podatki pa bodo živeli večno. Opomba: MongoDB podpira preverjanje sheme: je uporabno, vendar ne zagotavlja enakih jamstev kot v relacijski bazi podatkov. Prvič, dodajanje ali spreminjanje preverjanja sheme ne vpliva na obstoječe podatke v zbirki. Na vas je, da zagotovite posodobitev podatkov v skladu z novo shemo. Sami se odločite, ali je to dovolj za vaše potrebe.
• Izvorni jezik poizvedb/izguba ekosistema orodij: Pojav SQL je bil absolutna revolucija in od takrat se ni nič spremenilo. To je neverjetno močan jezik, a tudi precej zapleten. Ljudje, ki imajo izkušnje z delom s SQL, menijo, da je potreba po izdelavi poizvedb baze podatkov v novem jeziku, sestavljenem iz fragmentov JSON, velik korak nazaj. Obstaja celo vesolje orodij, ki sodelujejo z bazami podatkov SQL, od IDE do orodij za poročanje. Prehod na zbirko podatkov, ki ne podpira SQL, pomeni, da ne morete uporabljati večine teh orodij ali pa morate podatke prevesti v SQL, da jih uporabite, kar je lahko težje, kot si mislite.

Številni razvijalci, ki so se obrnili na MongoDB, v resnici niso razumeli kompromisov in so se pogosto brezglavo lotili namestitve kot svoje primarne podatkovne shrambe. Po tem se je bilo pogosto neverjetno težko vrniti.

Kaj bi lahko naredili drugače?

Niso vsi skočili na glavo in udarili v dno. Toda številni projekti so MongoDB namestili na mesta, kjer preprosto ni ustrezal – in z njim bodo morali živeti še vrsto let. Če bi te organizacije porabile nekaj časa in metodično premislile o svojih tehnoloških odločitvah, bi se mnoge odločile drugače.

Kako izbrati pravo tehnologijo? Bilo je več poskusov oblikovanja sistematičnega okvira za ocenjevanje tehnologije, kot npr "Ogrodje za uvajanje tehnologij v organizacije programske opreme" и "Ogrodje za ocenjevanje tehnologij programske opreme", vendar se mi zdi, da je to nepotrebno kompliciranje.

Številne tehnologije je mogoče inteligentno oceniti s samo dvema osnovnima vprašanjema. Težava je najti ljudi, ki lahko nanje odgovorijo odgovorno, vzamejo si čas za iskanje odgovorov in nepristransko.

Če nimate težav, ne potrebujete novega orodja. Pika.

Vprašanje 1: Katere težave poskušam rešiti?

Če nimate težav, ne potrebujete novega orodja. Pika. Ni treba iskati rešitev in si nato izmisliti problema. Razen če ste naleteli na težavo, ki jo nova tehnologija rešuje bistveno bolje kot vaša obstoječa tehnologija, tukaj ni o čem razpravljati. Če razmišljate o uporabi te tehnologije, ker ste videli, da jo drugi uporabljajo, pomislite, s kakšnimi težavami se soočajo, in vprašajte, ali imate te težave. Enostavno je sprejeti tehnologijo, ker jo uporabljajo drugi, izziv je razumeti, ali se soočate z enakimi težavami.

Vprašanje 2: Kaj pogrešam?

To je zagotovo težje vprašanje, ker se boste morali poglobiti in dobro razumeti tako staro kot novo tehnologijo. Včasih ne morete zares razumeti novega, dokler z njim nečesa ne zgradite ali imate nekoga s to izkušnjo.

Če nimate ne enega ne drugega, potem je smiselno razmišljati o minimalnem možnem vložku za določitev vrednosti tega instrumenta. In kako težko bo razveljaviti odločitev, ko enkrat investirate?

Ljudje vedno vse uničijo

Ko poskušate na ta vprašanja odgovoriti čim bolj nepristransko, si zapomnite eno stvar: boriti se boste morali proti človeški naravi. Za učinkovito ovrednotenje tehnologije je treba premagati številne kognitivne pristranskosti. Tukaj je le nekaj:

• Učinek pridružitve večini - vsi vedo zanj, vendar se je še vedno težko boriti z njim. Samo poskrbite, da tehnologija dejansko ustreza vašim dejanskim potrebam.
• Učinek novosti — Številni razvijalci ponavadi podcenjujejo tehnologije, s katerimi že dolgo delajo, in precenjujejo prednosti nove tehnologije. Ne gre samo za programerje, vsi so dovzetni za to kognitivno pristranskost.
• Učinek pozitivnih lastnosti - Ponavadi vidimo, kaj je tam, in izgubimo izpred oči tisto, kar manjka. To lahko povzroči kaos v kombinaciji z učinkom novosti, saj ne samo, da precenjujete novo tehnologijo, ampak tudi ignorirate njene pomanjkljivosti..

Objektivno ocenjevanje ni lahko, vendar vam bo razumevanje temeljnih kognitivnih pristranskosti pomagalo pri sprejemanju bolj racionalnih odločitev.

Povzetek

Kadarkoli se pojavi inovacija, je treba skrbno odgovoriti na dve vprašanji:

• Ali to orodje rešuje resnično težavo?
• Ali dobro razumemo kompromise?

Če ne morete z gotovostjo odgovoriti na ti dve vprašanji, stopite nekaj korakov nazaj in razmislite.

Je bil MongoDB sploh prava izbira? Seveda ja; Kot pri večini inženirskih tehnologij je to odvisno od številnih dejavnikov. Med tistimi, ki so odgovorili na ti dve vprašanji, so številni imeli koristi od MongoDB in to še naprej počnejo. Za tiste, ki se niste, upam, da ste se naučili dragocene in ne preveč boleče lekcije o premikanju skozi cikel navdušenja.

Izjava o omejitvi odgovornosti

Želim pojasniti, da z MongoDB nimam niti ljubezenskega niti sovražnega odnosa. Enostavno nismo imeli težav, za katere je MongoDB najprimernejši. Vem, da 10gen/MongoDB Inc. je bil sprva zelo drzen, saj je nastavil nevarne privzete nastavitve in povsod promoviral MongoDB (zlasti na hackathonih) kot univerzalno rešitev za delo s kakršnimi koli podatki. Verjetno je bila to slaba odločitev. Vendar potrjuje tukaj opisani pristop: te težave bi lahko odkrili zelo hitro tudi s površno oceno tehnologije.

Vir: www.habr.com