Am aflat recent că (spun ei din cauza modificărilor de licență). Acest lucru m-a pus pe gânduri, deoarece în ultimii ani am văzut o mulțime de articole despre cât de groaznic este MongoDB și despre cum nimeni nu ar trebui să-l folosească vreodată. Dar în acest timp, MongoDB a devenit un produs mult mai matur. Ce s-a întâmplat? Toată ura se datorează într-adevăr unor greșeli în comercializarea timpurie a unui nou SGBD? Sau oamenii folosesc doar MongoDB în locuri greșite?
Dacă simțiți că apăr MongoDB, vă rugăm să citiți la finalul articolului.
Noua moda
Lucrez în industria software de mai mulți ani decât pot spune, dar încă am fost expus doar la o mică parte din tendințele care au lovit industria noastră. Am asistat la creșterea 4GL, AOP, Agile, SOA, Web 2.0, AJAX, Blockchain... lista este nesfârșită. În fiecare an apar noi tendințe. Unele dispar rapid, în timp ce altele schimbă fundamental modul în care este dezvoltat software-ul.
Fiecare nouă tendință creează o emoție generală: oamenii fie sar la bord, fie văd zgomotul generat de alții și urmăresc mulțimea. Acest proces este codificat de Gartner în . Deși controversată, această cronologie descrie aproximativ ce se întâmplă cu tehnologiile înainte ca acestea să devină în cele din urmă utile.
Dar din când în când apare o nouă inovație (sau are o a doua venire, ca în acest caz) condusă de o singură implementare specifică. În cazul NoSQL, hype-ul a fost puternic determinat de apariția și creșterea fulgerătoare a MongoDB. MongoDB nu a început această tendință: de fapt, marile companii de internet au început să aibă probleme în procesarea unor cantități mari de date, ceea ce a dus la întoarcerea bazelor de date non-relaționale. Mișcarea generală a început cu proiecte precum Bigtable de la Google și Cassandra de la Facebook, dar MongoDB a devenit cea mai cunoscută și mai accesibilă implementare a bazei de date NoSQL la care au avut acces majoritatea dezvoltatorilor.
Notă: s-ar putea să credeți că confund bazele de date de documente cu bazele de date coloane, depozitele de chei/valoare sau oricare dintre numeroasele alte tipuri de depozite de date care se încadrează în definiția generală NoSQL. Și ai dreptate. Dar la vremea aceea domnea haosul. Toată lumea este obsedată de NoSQL, a devenit toată lumea absolut necesar, deși mulți nu au văzut diferențele dintre diferitele tehnologii. Pentru mulți, MongoDB a devenit sinonim NoSQL.
Și dezvoltatorii s-au aruncat asupra lui. Ideea unei baze de date fără schemă care se scalează magic pentru a rezolva orice problemă a fost destul de tentantă. În jurul anului 2014, se părea că peste tot în care în urmă cu un an se folosea o bază de date relațională precum MySQL, Postgres sau SQL Server a început să implementeze baze de date MongoDB. Când ați întrebat de ce, puteți obține un răspuns de la banalul „aceasta este scara web-ului” la cel mai atent „datele mele sunt foarte slab structurate și se potrivesc bine într-o bază de date fără o schemă”.
Este important să ne amintim că MongoDB și bazele de date de documente în general rezolvă o serie de probleme cu bazele de date relaționale tradiționale:
- Schema stricta: Cu o bază de date relațională, dacă ați generat dinamic date, sunteți forțat fie să creați o grămadă de coloane „diverse” aleatorii de date, fie să introduceți blocuri de date acolo, fie să utilizați configurația ... toate acestea au dezavantaje semnificative.
- Dificultate la scalare: Dacă există atât de multe date încât nu se potrivesc pe un singur server, MongoDB a oferit mecanisme care să îi permită scalarea pe mai multe mașini.
- Modificări complexe ale circuitului: fără migrații! Într-o bază de date relațională, schimbarea structurii bazei de date poate fi o problemă uriașă (mai ales când există o mulțime de date). MongoDB a reușit să simplifice foarte mult procesul. Și a făcut-o atât de ușor încât poți să actualizezi circuitul pe măsură ce mergi și să mergi mai departe foarte repede.
- Performanță de înregistrare: Performanța MongoDB a fost bună, mai ales când a fost configurată corect. Chiar și configurația out-of-the-box a MongoDB, pentru care a fost adesea criticată, a arătat niște cifre de performanță impresionante.
Toate riscurile sunt asupra ta
Beneficiile potențiale ale MongoDB erau enorme, în special pentru anumite clase de probleme. Dacă citiți lista de mai sus fără să înțelegeți contextul și fără experiență, puteți avea impresia că MongoDB este cu adevărat un DBMS revoluționar. Singura problemă a fost că beneficiile enumerate mai sus au venit cu o serie de avertismente, dintre care unele sunt enumerate mai jos.
Pentru a fi corect, nimeni de la 10gen/MongoDB Inc. nu va spune că următoarele nu sunt adevărate, acestea sunt doar compromisuri.
- Tranzacții pierdute: Tranzacțiile sunt o caracteristică de bază a multor baze de date relaționale (nu toate, dar majoritatea). Tranzacțional înseamnă că puteți efectua mai multe operațiuni atomic și vă puteți asigura că datele rămân consecvente. Desigur, cu o bază de date NoSQL, tranzacționalitatea poate fi într-un singur document sau puteți utiliza comiteri în două faze pentru a obține semantică tranzacțională. Dar va trebui să implementați singur această funcționalitate... ceea ce poate fi o sarcină dificilă și consumatoare de timp. Adesea nu vă dați seama că există o problemă până când nu vedeți că datele din baza de date ajung în stări invalide, deoarece atomicitatea operațiunilor nu poate fi garantată. Notă: Mulți oameni mi-au spus că MongoDB 4.0 a introdus tranzacții anul trecut, dar cu unele limitări. Dezbaterea din articol rămâne aceeași: evaluați cât de bine vă satisface tehnologia nevoilor.
- Pierderea integrității relaționale (chei străine): Dacă datele dumneavoastră au relații, atunci va trebui să le aplicați în aplicație. Având o bază de date care respectă aceste relații, o mare parte din munca aplicației și, prin urmare, a programatorilor tăi.
- Lipsa capacității de a aplica structura datelor: Schemele stricte pot fi uneori o mare problemă, dar sunt și un mecanism puternic pentru o bună structurare a datelor dacă sunt utilizate cu înțelepciune. Bazele de date de documente precum MongoDB oferă o flexibilitate incredibilă a schemei, dar această flexibilitate înlătură responsabilitatea de a păstra datele curate. Dacă nu aveți grijă de ele, veți ajunge să scrieți o mulțime de cod în aplicația dvs. pentru a ține cont de datele care nu sunt stocate în forma pe care o așteptați. După cum spunem adesea la compania noastră Simple Thread... aplicația va fi într-o zi rescrisă, dar datele vor trăi pentru totdeauna. Notă: MongoDB acceptă verificarea schemei: este utilă, dar nu oferă aceleași garanții ca într-o bază de date relațională. În primul rând, adăugarea sau modificarea unei verificări a schemei nu afectează datele existente în colecție. Depinde de dvs. să vă asigurați că actualizați datele în conformitate cu noua schemă. Decideți singur dacă acest lucru este suficient pentru nevoile dvs.
- Limbajul nativ de interogare/pierderea ecosistemului de instrumente: Apariția SQL a fost o revoluție absolută și nimic nu s-a schimbat de atunci. Este un limbaj incredibil de puternic, dar și destul de complex. Necesitatea de a construi interogări de baze de date într-un nou limbaj constând din fragmente JSON este considerată un mare pas înapoi de către persoanele care au experiență de lucru cu SQL. Există un întreg univers de instrumente care interacționează cu bazele de date SQL, de la IDE-uri la instrumente de raportare. Trecerea la o bază de date care nu acceptă SQL înseamnă că nu puteți folosi majoritatea acestor instrumente sau trebuie să traduceți datele în SQL pentru a le folosi, ceea ce poate fi mai dificil decât credeți.
Mulți dezvoltatori care au apelat la MongoDB nu au înțeles cu adevărat compromisurile și adesea s-au aruncat cu capul înainte în instalarea acestuia ca magazin de date principal. După aceasta, a fost adesea incredibil de greu să te întorci.
Ce s-ar fi putut face altfel?
Nu toată lumea a sărit cu capul înainte și a lovit fundul. Dar multe proiecte au instalat MongoDB în locuri în care pur și simplu nu se potrivea - și vor trebui să trăiască cu el pentru mulți ani de acum încolo. Dacă aceste organizații ar fi petrecut ceva timp și ar fi gândit metodic alegerile lor tehnologice, multe ar fi făcut alegeri diferite.
Cum să alegi tehnologia potrivită? Au existat mai multe încercări de a crea un cadru sistematic pentru evaluarea tehnologiei, cum ar fi и , dar mi se pare că aceasta este o complexitate inutilă.
Multe tehnologii pot fi evaluate în mod inteligent punând doar două întrebări de bază. Problema este să găsești oameni care să le răspundă în mod responsabil, făcându-și timp pentru a găsi răspunsurile și fără părtinire.
Dacă nu vă confruntați cu nicio problemă, nu aveți nevoie de un instrument nou. Punct.
Întrebarea 1: Ce probleme încerc să rezolv?
Dacă nu vă confruntați cu nicio problemă, nu aveți nevoie de un instrument nou. Punct. Nu este nevoie să cauți o soluție și apoi să inventezi o problemă. Dacă nu ați întâmpinat o problemă pe care noua tehnologie o rezolvă mult mai bine decât tehnologia dvs. existentă, nu este nimic de discutat aici. Dacă vă gândiți să utilizați această tehnologie pentru că ați văzut că alții o folosesc, gândiți-vă la ce probleme se confruntă și întrebați dacă aveți acele probleme. Este ușor să accepți o tehnologie pentru că alții o folosesc, provocarea este să înțelegi dacă te confrunți cu aceleași probleme.
Întrebarea 2: Ce îmi lipsește?
Aceasta este cu siguranță o întrebare mai dificilă, deoarece va trebui să aprofundați și să înțelegeți bine atât tehnologia veche, cât și cea nouă. Uneori nu poți înțelege cu adevărat unul nou până când nu construiești ceva cu el sau nu ai pe cineva cu acea experiență.
Dacă nu aveți niciunul, atunci este logic să vă gândiți la investiția minimă posibilă pentru a determina valoarea acestui instrument. Și odată ce faci investiția, cât de greu va fi să inversezi decizia?
Oamenii strică mereu totul
În timp ce încercați să răspundeți la aceste întrebări cât mai imparțial posibil, amintiți-vă un lucru: va trebui să luptați cu natura umană. Există o serie de părtiniri cognitive care trebuie depășite pentru a evalua eficient tehnologia. Iată doar câteva:
- - toată lumea știe despre el, dar este încă greu să te lupți cu el. Doar asigurați-vă că tehnologia corespunde cu adevărat nevoilor dvs. reale.
- — Mulți dezvoltatori tind să subestimeze tehnologiile cu care au lucrat de mult timp și să supraestimeze beneficiile noii tehnologii. Nu sunt doar programatori, toată lumea este susceptibilă la această părtinire cognitivă.
- - Tindem să vedem ce este acolo și să pierdem din vedere ceea ce lipsește. Acest lucru poate duce la haos atunci când este combinat cu efectul de noutate, deoarece nu numai că supraevaluezi în mod inerent noile tehnologii, ci și ignori deficiențele acesteia..
Evaluarea obiectivă nu este ușoară, dar înțelegerea distorsiunilor cognitive subiacente vă va ajuta să luați decizii mai raționale.
Rezumat
Ori de câte ori apare o inovație, la două întrebări trebuie să se răspundă cu mare grijă:
- Acest instrument rezolvă o problemă reală?
- Înțelegem bine compromisurile?
Dacă nu poți răspunde cu încredere la aceste două întrebări, fă câțiva pași înapoi și gândește-te.
Deci MongoDB a fost chiar alegerea potrivită? Desigur ca da; Ca și în cazul majorității tehnologiilor de inginerie, acest lucru depinde de mulți factori. Printre cei care au răspuns la aceste două întrebări, mulți au beneficiat de MongoDB și continuă să o facă. Pentru cei care nu au făcut-o, sper că ați învățat o lecție valoroasă și nu prea dureroasă despre trecerea prin ciclul hype.
Disclaimer
Vreau să clarific că nu am nici o relație de dragoste, nici de ură cu MongoDB. Pur și simplu nu am avut genul de probleme pe care MongoDB este cel mai potrivit să le rezolve. Știu că 10gen/MongoDB Inc. a fost foarte îndrăzneț la început, stabilind valori implicite nesigure și promovând MongoDB peste tot (în special la hackathon-uri) ca o soluție universală pentru lucrul cu orice date. Probabil a fost o decizie proastă. Dar confirmă abordarea descrisă aici: aceste probleme ar putea fi detectate foarte repede chiar și cu o evaluare superficială a tehnologiei.
Sursa: www.habr.com