ProHoster > Blogs > Administrācija > Vai MongoDB kopumā bija pareizā izvēle?

Vai MongoDB kopumā bija pareizā izvēle?

Es nesen to uzzināju Red Hat noņem MongoDB atbalstu no satelÄ«ta (viņi saka, ka licences maiņas dēļ). Tas man lika aizdomāties, jo pēdējos gados esmu redzējis daudz rakstu par to, cik MongoDB ir briesmÄ«gs un kā neviens to nedrÄ«kst izmantot. Bet Å”ajā laikā MongoDB ir kļuvis par daudz nobrieduŔāku produktu. Kas notika? Vai tieŔām viss naids ir saistÄ«ts ar kļūdām jaunas DBVS agrÄ«nā mārketingā? Vai arÄ« cilvēki vienkārÅ”i izmanto MongoDB nepareizās vietās?

Ja jums Ŕķiet, ka es aizstāvu MongoDB, lūdzu, izlasiet atruna raksta beigās.

Jauna tendence

Es strādāju programmatÅ«ras nozarē vairāk gadu, nekā bÅ«tu godÄ«gi teikt, taču joprojām esmu bijis pakļauts tikai nelielai daļai no tendencēm, kas ir skāruÅ”as mÅ«su nozari. Esmu bijis liecinieks 4GL, AOP, Agile, SOA, Web 2.0, AJAX, Blockchain pieaugumam... saraksts ir bezgalÄ«gs. Katru gadu parādās jaunas tendences. Daži ātri izzÅ«d, bet citi bÅ«tiski maina programmatÅ«ras izstrādes veidu.

Katra jauna tendence rada vispārēju sajÅ«smu: cilvēki vai nu uzlec uz klāja, vai redz citu radÄ«to troksni un seko pÅ«lim. Å o procesu ir kodificējis Gartner in hype cikls. Lai gan Å”is laika grafiks ir pretrunÄ«gs, tas aptuveni apraksta, kas notiek ar tehnoloÄ£ijām, pirms tās beidzot kļūst noderÄ«gas.

Taču ik pa laikam parādās kāds jauns jauninājums (vai tam ir otrā atnākÅ”ana, kā Å”ajā gadÄ«jumā), ko virza tikai viena konkrēta ievieÅ”ana. NoSQL gadÄ«jumā ažiotāžu lielā mērā izraisÄ«ja MongoDB parādÄ«Å”anās un straujÅ” pieaugums. MongoDB neuzsāka Å”o tendenci: patiesÄ«bā lielajiem interneta uzņēmumiem sāka rasties problēmas ar lielu datu apjomu apstrādi, kā rezultātā tika atgrieztas nerelāciju datu bāzes. Kopējā kustÄ«ba sākās ar tādiem projektiem kā Google Bigtable un Facebook Cassandra, taču tieÅ”i MongoDB kļuva par vispazÄ«stamāko un pieejamāko NoSQL datu bāzes ievieÅ”anu, kurai bija piekļuve lielākajai daļai izstrādātāju.

PiezÄ«me. Jums var Ŕķist, ka es jaucu dokumentu datu bāzes ar kolonnu datu bāzēm, atslēgu/vērtÄ«bu krātuvēm vai kādu no daudzajiem citiem datu krātuvju veidiem, kas ietilpst vispārējā NoSQL definÄ«cijā. Un tev ir taisnÄ«ba. Taču tajā laikā valdÄ«ja haoss. Visi ir apsēsti ar NoSQL, tas ir kļuvis par visiem absolÅ«ti nepiecieÅ”ams, lai gan daudzi nesaskatÄ«ja atŔķirÄ«bas dažādās tehnoloÄ£ijās. Daudziem MongoDB ir kļuvis sinonÄ«ms ar NoSQL.

Un izstrādātāji to metās uz priekÅ”u. Ideja par bezshēmu datubāzi, kas maÄ£iski mērogojas, lai atrisinātu jebkuru problēmu, bija diezgan vilinoÅ”a. Ap 2014. gadu Ŕķita, ka visur, kur pirms gada tika izmantota relāciju datubāze, piemēram, MySQL, Postgres vai SQL Server, sāka izvietot MongoDB datu bāzes. Uz jautājumu, kāpēc, jÅ«s varētu saņemt atbildi no banāla ā€œÅ”Ä« ir tÄ«mekļa mērogsā€ lÄ«dz pārdomātākajam ā€œmani dati ir ļoti brÄ«vi strukturēti un labi iekļaujas datu bāzē bez shēmasā€.

Ir svarīgi atcerēties, ka MongoDB un dokumentu datu bāzes kopumā atrisina vairākas problēmas ar tradicionālajām relāciju datu bāzēm:

  • Stingra shēma: izmantojot relāciju datu bāzi, ja jums ir dinamiski Ä£enerēti dati, jums ir vai nu jāizveido Ä·ekars nejauÅ”as "dažādas" datu kolonnas, jāievieto tajā datu lāses vai jāizmanto konfigurācija. EAV...tam visam ir bÅ«tiski trÅ«kumi.
  • MērogoÅ”anas grÅ«tÄ«bas: Ja ir tik daudz datu, ka tie neietilpst vienā serverÄ«, MongoDB piedāvāja mehānismus, kas ļauj to mērogot vairākās iekārtās.
  • Sarežģītas ķēdes modifikācijas: bez migrācijas! Relāciju datu bāzē datu bāzes struktÅ«ras maiņa var bÅ«t milzÄ«ga problēma (Ä«paÅ”i, ja datu ir daudz). MongoDB spēja ievērojami vienkārÅ”ot procesu. Un tas padarÄ«ja to tik vienkārÅ”u, ka jÅ«s varat vienkārÅ”i atjaunināt ķēdi, kad dodaties, un ļoti ātri turpināt darbu.
  • Ieraksta sniegums: MongoDB veiktspēja bija laba, it Ä«paÅ”i, ja tā bija pareizi konfigurēta. Pat MongoDB sākotnējā konfigurācija, par kuru tas bieži tika kritizēts, parādÄ«ja dažus iespaidÄ«gus veiktspējas rādÄ«tājus.

Visi riski ir uz jums

MongoDB potenciālie ieguvumi bija milzÄ«gi, Ä«paÅ”i attiecÄ«bā uz noteiktām problēmu klasēm. Ja lasāt iepriekÅ” minēto sarakstu, nesaprotot kontekstu un bez pieredzes, jums var rasties iespaids, ka MongoDB patieŔām ir revolucionāra DBVS. VienÄ«gā problēma bija tā, ka iepriekÅ” uzskaitÄ«tie ieguvumi bija saistÄ«ti ar vairākiem brÄ«dinājumiem, no kuriem daži ir uzskaitÄ«ti zemāk.

Godīgi sakot, neviens no 10gen/MongoDB Inc. neteikŔu, ka sekojoŔais nav patiesība, tie ir tikai kompromisi.

  • Zaudēti darÄ«jumi: DarÄ«jumi ir daudzu relāciju datu bāzu galvenā iezÄ«me (ne visās, bet lielākajā daļā). DarÄ«jums nozÄ«mē, ka varat veikt vairākas darbÄ«bas atomiski un nodroÅ”ināt datu konsekvenci. Protams, izmantojot NoSQL datu bāzi, transakcija var bÅ«t vienā dokumentā, vai arÄ« varat izmantot divfāžu apņemÅ”anos, lai iegÅ«tu darÄ«jumu semantiku. Bet Ŕī funkcionalitāte jums bÅ«s jāievieÅ” paÅ”am... kas var bÅ«t grÅ«ts un laikietilpÄ«gs uzdevums. Bieži vien jÅ«s neapzināties, ka pastāv problēma, lÄ«dz redzat, ka dati datu bāzē nonāk nederÄ«gos stāvokļos, jo nevar garantēt darbÄ«bu atomitāti. PiezÄ«me. Daudzi cilvēki man teica, ka MongoDB 4.0 pagājuÅ”ajā gadā ieviesa darÄ«jumus, taču ar dažiem ierobežojumiem. Rakstā sniegtā informācija paliek nemainÄ«ga: novērtējiet, cik labi tehnoloÄ£ija atbilst jÅ«su vajadzÄ«bām.
  • Relāciju integritātes zudums (sveÅ”as atslēgas): ja jÅ«su datiem ir attiecÄ«bas, jums tās bÅ«s jāpiemēro lietojumprogrammā. Izmantojot datu bāzi, kas respektē Ŕīs attiecÄ«bas, lietojumprogramma un lÄ«dz ar to arÄ« programmētāji noņems lielu darbu.
  • Datu struktÅ«ras pielietoÅ”anas iespējas trÅ«kums: Stingras shēmas dažkārt var bÅ«t liela problēma, taču tās ir arÄ« spēcÄ«gs mehānisms labai datu strukturÄ“Å”anai, ja to izmanto saprātÄ«gi. Dokumentu datu bāzes, piemēram, MongoDB, nodroÅ”ina neticamu shēmas elastÄ«bu, taču Ŕī elastÄ«ba novērÅ” atbildÄ«bu par datu tÄ«rÄ«bu. Ja jÅ«s par tiem nerÅ«pēsities, jÅ«s savā lietojumprogrammā ierakstÄ«sit daudz koda, lai ņemtu vērā datus, kas nav saglabāti paredzētajā formā. Kā mēs bieži sakām mÅ«su uzņēmumā Simple Thread... aplikācija kādreiz tiks pārrakstÄ«ta, bet dati dzÄ«vos mūžīgi. PiezÄ«me: MongoDB atbalsta shēmas pārbaudi: tā ir noderÄ«ga, taču nesniedz tādas paÅ”as garantijas kā relāciju datu bāzē. Pirmkārt, shēmas pārbaudes pievienoÅ”ana vai mainÄ«Å”ana neietekmē kolekcijā esoÅ”os datus. JÅ«su ziņā ir nodroÅ”ināt datu atjaunināŔanu atbilstoÅ”i jaunajai shēmai. Izlemiet paÅ”i, vai ar to pietiek jÅ«su vajadzÄ«bām.
  • Vietējā vaicājuma valoda/rÄ«ka ekosistēmas zudums: SQL parādÄ«Å”anās bija absolÅ«ta revolÅ«cija, un kopÅ” tā laika nekas nav mainÄ«jies. Tā ir neticami spēcÄ«ga valoda, taču arÄ« diezgan sarežģīta. NepiecieÅ”amÄ«bu veidot datu bāzes vaicājumus jaunā valodā, kas sastāv no JSON fragmentiem, cilvēki, kuriem ir pieredze darbā ar SQL, uzskata par lielu soli atpakaļ. Ir daudz rÄ«ku, kas mijiedarbojas ar SQL datu bāzēm, sākot no IDE lÄ«dz atskaites rÄ«kiem. Pāreja uz datu bāzi, kas neatbalsta SQL, nozÄ«mē, ka nevarat izmantot lielāko daļu Å”o rÄ«ku vai arÄ« jums ir jātulko dati SQL, lai tos izmantotu, kas var bÅ«t grÅ«tāk, nekā jÅ«s domājat.

Daudzi izstrādātāji, kas vērsās pie MongoDB, īsti nesaprata kompromisus un bieži vien ar galvu sāka to instalēt kā primāro datu krātuvi. Pēc tam atgriezties bieži bija neticami grūti.

Ko varēja darīt savādāk?

Ne visi lēca ar galvu un trāpÄ«ja apakŔā. Taču daudzi projekti ir instalējuÅ”i MongoDB vietās, kur tas vienkārÅ”i neiederas, un viņiem ar to bÅ«s jāsadzÄ«vo vēl daudzus gadus. Ja Ŕīs organizācijas bÅ«tu pavadÄ«juÅ”as kādu laiku un metodiski pārdomājuÅ”as savu tehnoloÄ£iju izvēli, daudzas bÅ«tu izdarÄ«juÅ”as dažādas izvēles.

Kā izvēlēties pareizo tehnoloÄ£iju? Ir bijuÅ”i vairāki mēģinājumi izveidot sistemātisku sistēmu tehnoloÄ£iju novērtÄ“Å”anai, piemēram "Ietvars tehnoloÄ£iju ievieÅ”anai programmatÅ«ras organizācijās" Šø "ProgrammatÅ«ras tehnoloÄ£iju novērtÄ“Å”anas sistēma", bet man Ŕķiet, ka tā ir lieka sarežģītÄ«ba.

Daudzas tehnoloÄ£ijas var saprātÄ«gi novērtēt, uzdodot tikai divus pamatjautājumus. Problēma ir atrast cilvēkus, kuri var atbildēt uz tiem atbildÄ«gi, veltot laiku atbilžu atraÅ”anai un bez aizspriedumiem.

Ja jums nav problēmu, jums nav nepiecieÅ”ams jauns rÄ«ks. Punkts.

1. jautājums: kādas problēmas es cenÅ”os atrisināt?

Ja jums nav problēmu, jums nav nepiecieÅ”ams jauns rÄ«ks. Punkts. Nav nepiecieÅ”ams meklēt risinājumu un pēc tam izdomāt problēmu. Ja vien neesat saskāries ar problēmu, ko jaunā tehnoloÄ£ija atrisina ievērojami labāk nekā esoŔā tehnoloÄ£ija, Å”eit nav par ko apspriest. Ja apsverat Ŕīs tehnoloÄ£ijas izmantoÅ”anu, jo esat redzējis, ka citi to izmanto, padomājiet par problēmām, ar kurām viņi saskaras, un jautājiet, vai jums ir Ŕīs problēmas. Ir viegli pieņemt tehnoloÄ£iju, jo citi to izmanto, izaicinājums ir saprast, vai jÅ«s saskaraties ar tām paŔām problēmām.

2. jautājums: kas man trūkst?

Tas noteikti ir grÅ«tāks jautājums, jo jums bÅ«s jāiedziļinās un labi jāizprot gan vecā, gan jaunā tehnoloÄ£ija. Dažreiz jÅ«s nevarat Ä«sti saprast jaunu, kamēr neesat ar to kaut ko izveidojis vai kāds nav ar Å”o pieredzi.

Ja jums nav neviena, tad ir jēga padomāt par minimālo iespējamo ieguldÄ«jumu, lai noteiktu Ŕī instrumenta vērtÄ«bu. Un, tiklÄ«dz veiksit ieguldÄ«jumu, cik grÅ«ti bÅ«s atcelt lēmumu?

Cilvēki vienmēr visu sabojā

Mēģinot atbildēt uz Å”iem jautājumiem pēc iespējas objektÄ«vāk, atcerieties vienu lietu: jums bÅ«s jācÄ«nās pret cilvēka dabu. Ir vairākas kognitÄ«vās novirzes, kas jāpārvar, lai efektÄ«vi novērtētu tehnoloÄ£iju. Å eit ir tikai daži:

  • Ietekme, pievienojoties vairākumam - visi par viņu zina, taču joprojām ir grÅ«ti ar viņu cÄ«nÄ«ties. VienkārÅ”i pārliecinieties, vai tehnoloÄ£ija patieŔām atbilst jÅ«su faktiskajām vajadzÄ«bām.
  • Jaunuma efekts ā€” Daudzi izstrādātāji mēdz par zemu novērtēt tehnoloÄ£ijas, ar kurām viņi ir strādājuÅ”i ilgu laiku, un pārvērtēt jauno tehnoloÄ£iju priekÅ”rocÄ«bas. Tas nav tikai programmētāji, visi ir uzņēmÄ«gi pret Å”o kognitÄ«vo aizspriedumu.
  • PozitÄ«vo Ä«paŔību ietekme - Mums ir tendence redzēt, kas tur ir, un aizmirst, kas trÅ«kst. Tas var izraisÄ«t haosu, ja to apvieno ar novitātes efektu, jo jÅ«s ne tikai pēc savas bÅ«tÄ«bas pārvērtējat jauno tehnoloÄ£iju, bet arÄ« ignorējat tās trÅ«kumus..

ObjektÄ«vs novērtējums nav viegls, taču izpratne par pamatā esoÅ”ajām kognitÄ«vajām novirzēm palÄ«dzēs jums pieņemt racionālākus lēmumus.

Kopsavilkums

Ikreiz, kad parādās jauninājums, ļoti rūpīgi jāatbild uz diviem jautājumiem:

  • Vai Å”is rÄ«ks atrisina reālu problēmu?
  • Vai mēs labi saprotam kompromisus?

Ja nevarat pārliecinoÅ”i atbildēt uz Å”iem diviem jautājumiem, speriet dažus soļus atpakaļ un padomājiet.

Tātad, vai MongoDB bija pat pareizā izvēle? Protams, jā; Tāpat kā lielākā daļa inženiertehnoloÄ£iju, tas ir atkarÄ«gs no daudziem faktoriem. Starp tiem, kas atbildēja uz Å”iem diviem jautājumiem, daudzi ir guvuÅ”i labumu no MongoDB un turpina to darÄ«t. Tiem, kas to nedarÄ«ja, es ceru, ka esat guvuÅ”i vērtÄ«gu un ne pārāk sāpÄ«gu mācÄ«bu par pārvietoÅ”anos ažiotāža ciklā.

Atruna

Es vēlos precizēt, ka man ar MongoDB nav ne mÄ«lestÄ«bas, ne naida attiecÄ«bu. Mums vienkārÅ”i nav bijuÅ”as tādas problēmas, kuru risināŔanai vislabāk atbilst MongoDB. Es zinu, ka 10gen/MongoDB Inc. sākumā bija ļoti drosmÄ«gs, iestatot nedroÅ”us noklusējuma iestatÄ«jumus un visur (Ä«paÅ”i hakatonos) reklamējot MongoDB kā universālu risinājumu darbam ar jebkuriem datiem. DroÅ”i vien tas bija slikts lēmums. Bet tas apstiprina Å”eit aprakstÄ«to pieeju: Ŕīs problēmas var atklāt ļoti ātri, pat virspusēji novērtējot tehnoloÄ£iju.

Avots: www.habr.com

Pievieno komentāru