Aghju scupertu recentemente chì Red Hat elimina u supportu MongoDB da Satellite (dicenu per via di cambiamenti di licenza). Questu m'hà fattu pensà perchè in l'ultimi anni aghju vistu una tonna di articuli nantu à quantu terribili hè MongoDB è cumu nimu ùn deve mai aduprà. Ma in questu tempu, MongoDB hè diventatu un pruduttu assai più maturu. Chi hè successu? Hè tuttu l'odiu veramente dovutu à i sbagli in u primu marketing di un novu DBMS? O sò e persone chì utilizanu MongoDB in i posti sbagliati?

Sè avete l'impressione di difende MongoDB, leghjite per piacè disclaimer à a fine di l'articulu.

Nova tendenza

Aghju travagliatu in l'industria di u software per più anni di ciò ch'e possu dì, ma sò sempre statu espostu solu à una piccula parte di e tendenze chì anu colpitu a nostra industria. Aghju vistu l'ascesa di 4GL, AOP, Agile, SOA, Web 2.0, AJAX, Blockchain ... a lista hè infinita. Ogni annu appariscenu novi tendenzi. Certi svanisce rapidamente, mentre chì altri cambianu fundamentalmente u modu di sviluppu di u software.

Ogni nova tendenza crea una eccitazione generale: a ghjente o salta à bordu, o vede u rumore generatu da l'altri è seguitanu a folla. Stu prucessu hè codificatu da Gartner in ciclu di hype. Ancu s'ellu hè cuntruversu, sta cronologia descrive à pocu pressu ciò chì succede à e tecnulugia prima ch'elli diventenu eventualmente utili.

Ma da u tempu à u tempu una nova innuvazione appare (o hà una seconda venuta, cum'è in questu casu) guidata da una sola implementazione specifica. In u casu di NoSQL, l'hype hè stata assai guidata da l'emergenza è l'aumentu meteoricu di MongoDB. MongoDB ùn hà micca principiatu sta tendenza: in fattu, e grande cumpagnie di Internet cuminciaru à avè prublemi à processà una grande quantità di dati, chì hà purtatu à u ritornu di basa di dati non-relazionale. U muvimentu generale hà iniziatu cù prughjetti cum'è Bigtable di Google è Cassandra di Facebook, ma era MongoDB chì diventò l'implementazione di basa di dati NoSQL più cunnisciuta è accessibile chì a maiò parte di i sviluppatori avianu accessu.

Nota: Puderete pensà chì sò cunfundendu e basa di dati di documentu cù basa di dati di colonna, magazzini chjave / valore, o qualsiasi di i numerosi altri tipi di magazzini di dati chì cadenu sottu a definizione generale NoSQL. È avete ragione. Ma à quellu tempu regnava u caosu. Tutti sò obsesionati cù NoSQL, hè diventatu tutti assolutamente necessariu, ancu s'è parechji ùn anu vistu e sferenze in e diverse tecnulugia. Per parechji, MongoDB hè diventatu sinonimu NoSQL.

È i sviluppatori si sò sbulicati. L'idea di una basa di dati senza schema chì scala magicamente per risolve ogni prublema era assai tentatore. Circa 2014, pareva chì in ogni locu chì un annu fà hà utilizatu una basa di dati relazionale cum'è MySQL, Postgres o SQL Server hà cuminciatu à implementà e basa di dati MongoDB. Quandu vi dumandate perchè, pudete avè una risposta da u banale "questu hè a scala di u web" à u più pensativu "i mo dati sò strutturati assai lasciamente è si mette bè in una basa di dati senza schema".

Hè impurtante di ricurdà chì MongoDB, è e basa di dati di documenti in generale, risolve una quantità di prublemi cù e basa di dati relazionale tradiziunali:

• Schema strettu: Cù una basa di dati relazionale, se avete dati generati dinamicamente, site custrettu à creà una mansa di culonni di dati "varie" aleatorii, inserisce blobs di dati quì, o aduprà a cunfigurazione. EAV...tuttu questu hà svantaghji significativi.
• Difficultà a scala: S'ellu ci hè una quantità di dati chì ùn si mette micca in un servitore, MongoDB offre miccanismi chì permettenu di scala in parechje macchine.
• Modifiche cumplessi di circuiti: senza migrazioni ! In una basa di dati relazionale, cambià a struttura di a basa di dati pò esse un prublema enormu (in particulare quandu ci sò assai dati). MongoDB hà sappiutu simplificà assai u prucessu. È hà fattu cusì faciule chì pudete solu aghjurnà u circuitu mentre andate è andate assai rapidamente.
• Prestazione di registrazione: U rendiment di MongoDB era bonu, soprattuttu quandu cunfiguratu bè. Ancu a cunfigurazione out-of-the-box di MongoDB, per quale hè stata spessu criticata, hà dimustratu alcuni numeri di rendiment impressiunanti.

Tutti i risichi sò nantu à voi

I benefici potenziali di MongoDB eranu enormi, soprattuttu per certi classi di prublemi. Se leghjite a lista sopra senza capisce u cuntestu è senza sperienza, pudete avè l'impressione chì MongoDB hè veramente un DBMS rivoluzionariu. L'unicu prublema era chì i benefici elencati sopra venenu cù una quantità di caveats, alcuni di i quali sò elencati quì sottu.

Per esse ghjustu, nimu à 10gen / MongoDB Inc. ùn dicerà micca chì i seguenti ùn hè micca veru, questi sò solu cumprumessi.

• Transazzione persa: E transazzione sò una funzione core di parechje basa di dati relazionale (micca tutte, ma a maiò parte). Transazzione significa chì pudete fà parechje operazioni atomicu è pò assicurà chì e dati restanu coherente. Di sicuru, cù una basa di dati NoSQL, a transazzione pò esse in un unicu documentu, o pudete aduprà commits in dui fasi per ottene a semantica transazionale. Ma vi tuccherà à implementà sta funziunalità sè stessu... chì pò esse un compitu difficiule è tempu. Spessu ùn avete micca capitu chì ci hè un prublema finu à vede chì e dati in a basa di dati finiscinu in stati invalidi perchè l'atomicità di l'operazioni ùn pò micca esse garantita. Nota: Parechje persone m'hà dettu chì MongoDB 4.0 hà introduttu transazzione l'annu passatu, ma cù alcune limitazioni. U takeaway da l'articulu ferma u listessu: evaluate quantu a tecnulugia risponde à i vostri bisogni.
• Perdita di integrità relazionale (chjavi stranieri): Se i vostri dati anu rilazioni, allora vi tuccherà à applicà in l'applicazione. Avè una basa di dati chì rispettu sti rilazioni piglià assai di u travagliu fora di l'applicazione è dunque i vostri programatori.
• Mancanza di capacità per applicà a struttura di dati: I schemi stretti pò esse qualchì volta un prublema maiò, ma sò ancu un mecanismu putente per una bona strutturazione di dati, s'ellu si usa cun prudenza. I basa di dati di documentu cum'è MongoDB furnisce una flessibilità di schema incredibile, ma sta flessibilità elimina a rispunsabilità di mantene e dati puliti. Se ùn avete micca cura di elli, finirete per scrive assai codice in a vostra applicazione per cuntà e dati chì ùn sò micca guardati in a forma chì aspetta. Cum'è spessu dicemu à a nostra cumpagnia Simple Thread... l'applicazione serà un ghjornu riscritta, ma i dati camparanu per sempre. Nota: MongoDB supporta a verificazione di schema: hè utile, ma ùn furnisce micca e stesse garanzie cum'è in una basa di dati relazionale. Prima di tuttu, l'aghjunghje o cambià un cuntrollu di schema ùn affetta micca e dati esistenti in a cullizzioni. Hè à voi per assicurà chì aghjurnà e dati secondu u novu schema. Decide per sè stessu se questu hè abbastanza per i vostri bisogni.
• Lingua nativa di dumanda / perdita di l'ecosistema di l'uttene: L'avventu di SQL hè statu una rivoluzione assoluta è nunda hà cambiatu da tandu. Hè una lingua incredibbilmente putente, ma ancu abbastanza cumplessa. A necessità di custruisce e dumande di basa di dati in una nova lingua composta da frammenti JSON hè cunsideratu cum'è un grande passu in daretu da e persone chì anu sperienza di travaglià cù SQL. Ci hè un universu sanu di arnesi chì interagiscenu cù e basa di dati SQL, da l'IDE à i strumenti di rapportu. Trascendendu à una basa di dati chì ùn sustene micca SQL significa chì ùn pudete micca aduprà a maiò parte di sti strumenti o avete da traduce i dati in SQL per aduprà, chì pò esse più difficiuli di ciò chì pensate.

Parechji sviluppatori chì anu vultatu à MongoDB ùn anu micca veramente capitu i scambii, è spessu immersi prima in l'installazione cum'è u so magazzinu di dati primariu. Dopu questu, era spessu incredibbilmente difficiule di vultà.

Chì puderia esse fattu di manera diversa ?

Micca tutti hà saltatu u capu è toccu u fondu. Ma parechji prughjetti anu stallatu MongoDB in i posti induve ùn hè micca ghjustu - è anu da campà cun ellu per parechji anni à vene. Sì sti urganisazioni avianu passatu un pocu di tempu è pensanu metodicamente à traversu e so scelte tecnologiche, assai avianu fattu scelte diverse.

Cumu sceglie a tecnulugia ghjusta? Ci sò stati parechji tentativi di creà un quadru sistematicu per a valutazione di a tecnulugia, cum'è "Quadru per l'introduzione di tecnulugia in l'urganisazioni di software" и "Quadru per a valutazione di e tecnulugia di u software", ma mi pari chì questu hè una cumplessità inutile.

Parechje tecnulugii ponu esse valutati in modu intelligente, dumandendu solu duie dumande basi. U prublema hè di truvà e persone chì ponu risponde à elli in modu rispunsevuli, piglià u tempu per truvà e risposte è senza preghjudiziu.

Se ùn avete micca affruntà ogni prublema, ùn avete micca bisognu di un novu strumentu. Dot.

Quistione 1: Chì prublemi aghju pruvatu à risolve?

Se ùn avete micca affruntà ogni prublema, ùn avete micca bisognu di un novu strumentu. Dot. Ùn ci hè bisognu di circà una suluzione è poi inventà un prublema. A menu chì ùn avete scontru un prublema chì a nova tecnulugia risolve significativamente megliu cà a vostra tecnulugia esistente, ùn ci hè nunda di discutiri quì. Sè vo site cunsiderà aduprà sta tecnulugia perchè avete vistu chì l'altri l'utilizanu, pensate à i prublemi chì affruntà è dumandate s'ellu avete questi prublemi. Hè faciule d'accettà una tecnulugia perchè l'altri l'utilizanu, a sfida hè di capisce s'ellu face i stessi prublemi.

Quistione 2 : Chì mi manca ?

Questa hè certamente una quistione più difficiule perchè duverete scavà è avè una bona cunniscenza di a tecnulugia antica è nova. A volte ùn pudete micca veramente capisce un novu finu à chì avete custruitu qualcosa cun ellu o avete qualchissia cù quella sperienza.

Se ùn avete nè, allora hè sensu di pensà à l'investimentu minimu pussibule per determinà u valore di stu strumentu. È una volta chì fate l'investimentu, quantu serà difficiule di annunzià a decisione?

A ghjente arruvina sempre tuttu

Cum'è vo circate di risponde à queste dumande cum'è imparzialmente pussibule, ricordate una cosa: avete da cumbatte a natura umana. Ci hè una quantità di preghjudizii cognitivi chì deve esse superatu per valutà in modu efficace a tecnulugia. Eccu solu uni pochi:

• L'effettu di unisce à a maiurità - ognunu sapi di ellu, ma hè sempre difficiule di cummattiri. Solu assicuratevi chì a tecnulugia currisponde à i vostri bisogni reali.
• Effettu di novità - Parechji sviluppatori tendenu à sottovalutà e tecnulugia chì anu travagliatu per un bellu pezzu è sopravvalutà i benefici di a nova tecnulugia. Ùn sò micca solu i programatori, tutti sò suscettibili à stu preghjudiziu cognitivu.
• Effettu di e caratteristiche pusitivi - Tendemu à vede ciò chì ci hè è perde di vista ciò chì manca. Questu pò guidà à u caosu quandu hè cumminatu cù l'effettu di novità, cum'è ùn solu ùn sopravalutà in modu intrinsecamente a nova tecnulugia, ma ancu ignora i so difetti..

A valutazione obiettiva ùn hè micca faciule, ma capisce i preghjudizii cognitivi sottostanti vi aiuterà à piglià decisioni più raziunali.

Resumen

Ogni volta chì una innovazione appare, duie dumande deve esse rispostu cun grande cura:

• Stu strumentu risolve un veru prublema?
• Capemu bè i scambii ?

Se ùn pudete micca risponde à queste duie dumande, fate un pocu di passi in daretu è pensate.

Allora MongoDB era ancu a scelta bona? Di sicuru sì; Cum'è cù a maiò parte di e tecnulugia ingegneria, questu dipende di parechji fatturi. Trà quelli chì anu rispostu sti dui dumande, assai anu benefiziu di MongoDB è cuntinueghjanu à fà. Per quelli chì ùn anu micca, spergu chì avete amparatu una lezione preziosa è micca troppu dulurosa nantu à u muvimentu in u ciculu di l'hype.

Disclaimer

Vogliu fà chjaru chì ùn aghju nè una relazione d'amore nè d'odiu cù MongoDB. Solu ùn avemu micca avutu u tipu di prublemi chì MongoDB hè più adattatu per risolve. Sò chì 10gen/MongoDB Inc. era assai audace à u principiu, stabilisce predefiniti insicuri è prumove MongoDB in ogni locu (in particulare à i pirate) cum'è una suluzione universale per travaglià cù qualsiasi dati. Probabilmente era una mala decisione. Ma cunfirma l'approcciu descrittu quì: sti prublemi puderanu esse rilevati assai rapidamente ancu cù una valutazione superficiale di a tecnulugia.

Source: www.habr.com