Recent am aflat că (se spune că din cauza schimbărilor de licență). Acest lucru m-a făcut să reflectez la faptul că în ultimii ani am văzut o mulțime de articole despre cât de teribilă este MongoDB și că nimeni nu ar trebui să o folosească vreodată. Dar în acest timp, MongoDB a devenit un produs mult mai matur. Ce s-a întâmplat? Oare toată antipatia provine din greșelile din prima etapă de marketing a acestei noi baze de date?
Dacă cumva credeți că apăr MongoDB, vă rog să citiți de la sfârșitul articolului.
O nouă tendință
Lucrez în industria software de mai mulți ani decât e frumos să spun, dar totuși mi-a revenit doar o mică parte din tendințele care au lovit industria noastră. Am fost martor la creșterea 4GL, AOP, Agile, SOA, Web 2.0, AJAX, blockchain… lista este nesfârșită. Fiecare an aduce noi tendințe. Unele se sting rapid, în timp ce altele schimbă în mod fundamental metodele de dezvoltare software.
În jurul fiecărei noi tendințe se creează o anumită agitație: oamenii sau sar singuri în barcă, sau observă zgomotul generat de alții – și se alătură mulțimii. Acest proces a fost codificat de compania Gartner în . Deși controversat, acest grafic descrie în mare parte ce se întâmplă cu tehnologiile înainte de a deveni în cele din urmă utile.
Dar din când în când apare (sau are loc a doua venire, ca în acest caz) o nouă inovație, determinată doar de o singură implementare specifică. În cazul NoSQL, hype-ul a fost profund influențat de apariția și ascensiunea rapidă a MongoDB. Nu MongoDB a creat această tendință: de fapt, problemele de procesare a unor cantități mari de date au apărut inițial în companii mari de internet, ceea ce a dus la revenirea bazelor de date nerelaționale. Mișcarea a început cu proiecte precum Bigtable de la Google și Cassandra de la Facebook, dar MongoDB a devenit cea mai cunoscută și accesibilă implementare a unei baze de date NoSQL, la care au avut acces majoritatea dezvoltatorilor.
Notă: ați putea crede că amestec documentele Baze de Date cu Baze de Date coloane, stocări cheie/valoare sau oricare dintre numeroasele alte tipuri de stocări de date care se încadrează în definiția generală NoSQL. Și aveți dreptate. Dar în acel moment exista haos. Toată lumea era obsedată de NoSQL, toată lumea o dorea. absolut necesar, deși mulți nu au observat diferențele dintre diferitele tehnologii. Pentru mulți, MongoDB a devenit sindromul NoSQL.
Și dezvoltatorii s-au avântat spre ea. Ideea unei baze de date fără schemă, care se scalează magic pentru a rezolva orice problemă, era destul de atrăgătoare. Aproape în 2014, părea că peste tot unde cu un an înainte era utilizată o bază de date relațională, precum MySQL, Postgres sau SQL Server, s-au început desfășurări de baze MongoDB. La întrebarea de ce, puteai obține un răspuns de la banalul „este scalarea web-ului” până la cel mai bine gândit „datele mele sunt foarte slab structurate și se potrivesc bine într-o bază de date fără schemă”.
Este important să ne amintim că MongoDB și bazele de date documente, în general, rezolvă o serie de probleme asociate cu bazele de date relaționale tradiționale:
- Schema strictă: cu o bază de date relațională, dacă ai date generate dinamic, ești nevoit fie să creezi o mulțime de coloane de date „diferite” întâmplătoare, să stochezi date blob acolo sau să folosești o configurație … toate acestea au dezavantaje semnificative.
- Dificultatea scalării: dacă datele sunt atât de multe încât nu încap pe un singur server, MongoDB oferea mecanisme care permiteau scalarea lor pe mai multe mașini.
- Modificări complicate ale schemei: fără migrații! Într-o bază de date relațională, schimbarea structurii bazei de date poate deveni o problemă uriașă (mai ales când datele devin foarte multe). MongoDB a reușit să simplifice semnificativ procesul. A făcut-o atât de ușor, încât poți actualiza schema în mișcare și să avansezi foarte repede.
- Performanța în scriere: performanța MongoDB a fost bună, în special cu o configurare adecvată. Chiar și configurația MongoDB din fabrică, pentru care a fost adesea criticată, a arătat unele rezultate impresionante de performanță.
Toate riscurile pe tine
Beneficiile potențiale ale MongoDB au fost uriașe, în special pentru anumite categorii de probleme. Dacă citești lista de mai sus fără a înțelege contextul și fără experiență, s-ar putea să ai impresia că MongoDB este cu adevărat o SGBD revoluționară. Singura problemă era că avantajele enumerate mai sus erau însoțite de o serie de avertismente, dintre care unele sunt menționate mai jos.
Pentru a fi corect, nimeni de la 10gen/MongoDB Inc. nu va spune că cele ce urmează sunt neadevărate, acestea sunt doar compromisuri.
- Pierderea tranzacțiilor: tranzacțiile sunt o caracteristică principală a multor baze de date relaționale (nu a tuturor, dar a majorității). Tranzacționalitatea înseamnă că poți efectua mai multe operațiuni atomic și poți garanta că datele vor rămâne consistente. Desigur, în cazul unei baze de date NoSQL, tranzacționalitatea poate fi pe un singur document sau poți utiliza commituri în două faze pentru a obține semantică tranzacțională. Dar va trebui să implementezi tu această funcționalitate... ceea ce poate fi o sarcină complexă și consumatoare de timp. Adesea nu realizezi problemele până nu vezi că datele din baza de date ajung în stări invalide, deoarece nu poți garanta atomicitatea operațiunilor. Notă: mulți mi-au spus că anul trecut, în MongoDB 4.0, au apărut tranzacții, dar cu o serie de restricții. Concluzia articolului rămâne aceeași: evaluează cât de bine se potrivește tehnologia nevoilor tale.
- Pierderea integrității relaționale (chei externe): dacă datele tale au relații, va trebui să le aplici în aplicație. O bază de date care respectă aceste relații va reduce semnificativ din munca în aplicație și, prin urmare, din sarcinile programatorilor tăi.
- Lipsa posibilității de a aplica structura de date: schemele stricte pot deveni uneori o problemă mare, dar sunt, de asemenea, un mecanism puternic pentru structurarea corectă a datelor, dacă sunt folosite bine. Bazele de date documentare, precum MongoDB, oferă o flexibilitate incredibilă a schemei, dar această flexibilitate elimină responsabilitatea de a menține datele curate. Dacă nu ai grijă de acestea, în cele din urmă va trebui să scrii mult cod în aplicație pentru a ține cont de datele care sunt stocate într-o formă diferită de cea pe care o aștepți. Așa cum spunem adesea în compania noastră Simple Thread… aplicația va fi rescrisă cândva, dar datele vor trăi veșnic. Notă: MongoDB suportă verificarea schemei: este utilă, dar nu oferă aceleași garanții ca o bază de date relațională. În primul rând, adăugarea sau modificarea verificării schemei nu afectează datele existente în colecție. Trebuie să te asiguri că actualizezi datele conform noii scheme. Decide singur dacă este suficient pentru nevoile tale.
- Limbaj de interogare propriu / pierdere a ecosistemului de instrumente: apariția SQL a fost o revoluție absolută, și de atunci nimic nu s-a schimbat. Este un limbaj incredibil de puternic, dar destul de complex. Necesitatea de a construi interogări la baze de date într-un nou limbaj, format din fragmente JSON, este considerată un mare pas înapoi de persoanele cu experiență în SQL. Există o întreagă 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 suportă SQL înseamnă că nu poți folosi majoritatea acestor instrumente sau trebuie să convertești datele în SQL pentru a le folosi, ceea ce poate fi mai complicat decât crezi.
Mulți dezvoltatori care s-au îndreptat spre MongoDB nu înțelegeau foarte bine compromisurile și, adesea, s-au aruncat cu capul înainte, stabilind-o ca principală soluție de stocare a datelor. După aceea, a fost de obicei incredibil de greu să te întorci înapoi.
Ce s-ar fi putut face diferit?
Nu toată lumea a sărit cu capul înainte și a lovit fundul. Dar multe proiecte au instalat baza MongoDB acolo unde pur și simplu nu era potrivită - și vor trebui să trăiască cu ea mulți ani de acum înainte. Dacă aceste organizații ar fi petrecut puțin timp și ar fi gândit metodic alegerea tehnologiilor, multe ar fi făcut o alegere diferită.
Cum să alegi tehnologia potrivită? Au fost câteva încercări de a crea un cadru sistematic pentru evaluarea tehnologiilor, cum ar fi și , dar mi se pare că este o complexitate excesivă.
Multe tehnologii pot fi evalutate în mod rațional, punând doar două întrebări de bază. Problema constă în găsirea oamenilor care pot răspunde responsabil la ele, dedicând timp pentru a căuta răspunsuri fără prejudecăți.
Dacă nu te confrunți cu o problemă, nu ai nevoie de un nou instrument. Punct.
Întrebare 1: Ce probleme încerc să rezolv?
Dacă nu te confrunți cu o problemă, nu ai nevoie de un nou instrument. Atât. Nu trebuie să cauți o soluție și apoi să inventezi o problemă. Dacă nu te-ai lovit de o problemă pe care noua tehnologie nu o rezolvă semnificativ mai bine decât tehnologia ta existentă, atunci nu este cazul să discutăm aici. Dacă te gândești să folosești această tehnologie pentru că ai văzut că altora le folosește, gândește-te la ce probleme se confruntă și întreabă-te dacă ai aceleași probleme. E ușor să adopți tehnologia pentru că o folosesc alții, dificultatea constă în a înțelege dacă te confrunți cu aceleași provocări.
Întrebare 2: Ce pierd?
Aceasta este, fără îndoială, o întrebare mai dificilă, deoarece va trebui să te aventurezi în detalii și să înțelegi bine atât tehnologia veche, cât și pe cea nouă. Uneori nu poți înțelege cu adevărat noua tehnologie până nu construiești ceva cu ajutorul ei sau până nu ai un coleg care are astfel de experiență.
Dacă nu ai nici asta, nici cealaltă, are sens să te gândești la investițiile minime posibile pentru a determina valoarea acestui instrument. Și dacă vei face investiții, cât de greu va fi să anulezi decizia?
Oamenii strică întotdeauna totul
Încercând să răspunzi la aceste întrebări cât mai obiectiv, amintește-ți un lucru: va trebui să te lupți cu natura umană. Există o serie de prejudecăți cognitive care trebuie depășite pentru a evalua eficient tehnologia. Iată doar câteva:
- — toată lumea știe despre el, dar este totuși greu de combătut. Asigură-te doar că tehnologia se potrivește cu nevoile tale reale.
- — mulți dezvoltatori au tendința de a subestima tehnologiile cu care au lucrat mult timp și de a supraestima avantajele noii tehnologii. Nu doar programatorii, toată lumea este predispusă la această prejudecată cognitivă.
- — avem tendința de a vedea ceea ce există și de a ignora ceea ce lipsește. Acest lucru poate duce la haos în combinație cu efectul de noutate, deoarece nu doar că supraestimezi noua tehnologie, dar ignori și dezavantajele acesteia..
Evaluarea obiectivă nu este ușor de realizat, dar înțelegerea principalelor distorsiuni cognitive poate ajuta la luarea unor decizii mai raționale.
Rezumat
Când apare o inovație, trebuie să răspundem cu mare atenție la două întrebări:
- Această unealtă rezolvă o problemă reală?
- Înțelegem bine compromisurile?
Dacă nu puteți răspunde cu încredere la aceste două întrebări, faceți câțiva pași înapoi și gândiți-vă.
A fost MongoDB cu adevărat o alegere corectă? Cu siguranță da; la fel ca în majoritatea tehnologiilor inginerești, depinde de o mulțime de factori. Dintre cei care au răspuns la aceste două întrebări, mulți au beneficiat de MongoDB și continuă să o facă. Cei care nu au făcut-o, sper să fi obținut o lecție valoroasă și nu prea dureroasă despre modul de funcționare în cadrul buclei de hype.
Declinarea responsabilității
Vreau să subliniez că nu simt nici dragoste, nici ură față de MongoDB. Pur și simplu nu am avut probleme pentru care MongoDB ar fi fost soluția optimă. Știu că 10gen/MongoDB Inc. a acționat inițial foarte curajos, stabilind valori nesigure ca setări implicite și promovând MongoDB peste tot (în special la hackathoane) ca o soluție universală pentru orice tip de date. Probabil că a fost o decizie proastă. Dar aceasta susține abordarea descrisă aici: aceste probleme puteau fi descoperite foarte rapid, chiar și printr-o evaluare superficială a tehnologiei.
Sursa: habr.com
