Recentemente ho scoperto che (dicono a causa delle modifiche alla licenza). Questo mi ha fatto riflettere sul fatto che negli ultimi anni ho visto un sacco di articoli su quanto sia terribile MongoDB e che nessuno dovrebbe mai usarla. Ma nel frattempo MongoDB è diventata un prodotto molto più maturo. Cosa è successo? Tutta questa avversione è davvero spiegata da errori nel marketing della nuova DBMS? O la gente usa semplicemente MongoDB nei posti sbagliati?
Se vi sembra che stia difendendo MongoDB, vi prego di leggere alla fine dell'articolo.
Nuova tendenza
Lavoro nell'industria del software da più anni di quanti ne voglia dire, ma ho comunque assistito a solo una piccola parte delle tendenze che hanno colpito il nostro settore. Ho visto la crescita di 4GL, AOP, Agile, SOA, Web 2.0, AJAX, blockchain… la lista è infinita. Ogni anno emergono nuove tendenze. Alcune svaniscono rapidamente, mentre altre cambiano radicalmente i modi di sviluppare software.
Intorno a ogni nuova tendenza si crea una sorta di eccitazione collettiva: le persone saltano a bordo da sole o sentono il rumore generato da altri e seguono la folla. Questo processo è stato codificato dalla società Gartner nel . Sebbene sia controverso, questo grafico descrive abbastanza bene cosa succede alle tecnologie prima che diventino utili.
Ma di tanto in tanto emerge (o avviene una seconda venuta, come in questo caso) una nuova innovazione, alimentata solo da una sua specifica attuazione. Nel caso di NoSQL, l'hype è stato molto influenzato dall'emergere e dalla rapida ascesa di MongoDB. Non è stata MongoDB ad avviare questa tendenza: in realtà, le grandi aziende internet hanno iniziato ad avere problemi nell'elaborazione di grandi volumi di dati, che hanno portato a un ritorno ai database non relazionali. Il movimento generale è iniziato con progetti come Bigtable di Google e Cassandra di Facebook, ma è stata MongoDB a diventare l'implementazione di database NoSQL più conosciuta e accessibile per la maggior parte degli sviluppatori.
Nota: potreste pensare che stia mescolando i database documentali con i database colonnari, i magazzini chiave/valore o qualsiasi altro dei numerosi altri tipi di magazzini dati che rientrano nella definizione generale di NoSQL. E avete ragione. Ma all'epoca regnava il caos. Tutti erano ossessionati da NoSQL, era diventato assolutamente è necessario, anche se molti non hanno notato differenze nelle diverse tecnologie. Per molti, MongoDB è diventato un sinonimo di NoSQL.
E i programmatori si sono gettati su di esso. L'idea di un database senza schema, che si scala magicamente per risolvere qualsiasi problema, era piuttosto allettante. Intorno al 2014, sembrava che ovunque ci fosse prima un database relazionale, come MySQL, Postgres o SQL Server, si stessero implementando database MongoDB. Alla domanda sul perché, si poteva ottenere una risposta che variava dal banale «è la scala del web» a una più riflessiva «i miei dati sono molto debolmente strutturati e si adattano bene a un database senza schema».
È importante ricordare che MongoDB e i database a documenti in generale risolvono diversi problemi con i tradizionali database relazionali:
- Schema rigido: con un database relazionale, se hai dati generati dinamicamente, sei costretto a creare un mucchio di «colonne» di dati «diverse», a infilare blob di dati o a usare una configurazione … tutto questo ha notevoli svantaggi.
- Difficoltà di scalabilità: se ci sono così tanti dati che non possono stare su un solo server, MongoDB offriva meccanismi che consentivano di scalare su più macchine.
- Modifiche complesse allo schema: nessuna migrazione! In un database relazionale, cambiare la struttura del DB può diventare un enorme problema (soprattutto quando i dati diventano moltissimi). MongoDB è riuscita a semplificare notevolmente il processo. E lo ha reso così facile che puoi semplicemente aggiornare lo schema al volo e procedere molto rapidamente.
- Prestazioni di scrittura: le prestazioni di MongoDB erano buone, specialmente con una configurazione adeguata. Anche la configurazione di MongoDB di default, per cui spesso è stata criticata, mostrava alcuni risultati prestazionali impressionanti.
Tutti i rischi ricadono su di te
I potenziali vantaggi di MongoDB erano enormi, soprattutto per determinate classi di problemi. Se leggi la lista sopra senza capire il contesto e senza esperienza, potresti avere l'impressione che MongoDB sia davvero un DBMS rivoluzionario. L'unico problema è che i vantaggi elencati sopra erano accompagnati da una serie di avvertenze, alcune delle quali sono indicate di seguito.
A fini giustizia, nessuno in 10gen/MongoDB Inc. dirà che quanto segue è falso, è solo compromessi.
- Perdita di transazioni: le transazioni sono una caratteristica fondamentale di molti database relazionali (non tutti, ma la maggior parte). La transazionalità significa che puoi eseguire diverse operazioni in modo atomico e puoi garantire che i dati rimangano coerenti. Certamente, con un database NoSQL la transazionalità può essere a livello di un singolo documento oppure puoi utilizzare commit in due fasi per ottenere una semantica transazionale. Ma dovrai implementare questa funzionalità da solo... il che può essere un compito complesso e laborioso. Spesso non ti rendi conto dei problemi fino a quando non vedi che i dati nel database entrano in stati non validi, perché non è possibile garantire l'atomicità delle operazioni. Nota: molti mi hanno riferito che lo scorso anno sono state introdotte le transazioni in MongoDB 4.0, ma con diverse limitazioni. La conclusione dell'articolo rimane la stessa: valuta quanto la tecnologia soddisfa le tue esigenze.
- Perdita di integrità relazionale (chiavi esterne): se nei tuoi dati ci sono relazioni, dovrai gestirle nell'applicazione. Avere un database che rispetti queste relazioni ridurrà significativamente il lavoro nell'applicativo e, di conseguenza, per i tuoi programmatori.
- Assenza della possibilità di applicare una struttura dati: schemi rigidi a volte possono diventare un grande problema, ma sono anche un potente meccanismo per una buona strutturazione dei dati, se utilizzati correttamente. I database documentali, come MongoDB, offrono una flessibilità schema incredibile, ma questa flessibilità elimina la responsabilità di mantenere i dati puliti. Se non te ne prendi cura, dovrai alla fine scrivere molto codice nell'applicazione per tener conto dei dati che sono memorizzati in forme non previste. Come spesso si dice nella nostra azienda Simple Thread... l'applicazione un giorno verrà riscritta, ma i dati vivranno per sempre. Nota: MongoDB supporta la verifica dello schema: è utile, ma non offre le stesse garanzie di un database relazionale. Prima di tutto, l'aggiunta o la modifica della verifica dello schema non influisce sui dati esistenti nella raccolta. Devi assicurarti che i dati siano aggiornati secondo il nuovo schema. Decidi tu stesso se questo è sufficiente per le tue esigenze.
- Linguaggio di query proprietario / perdita dell'ecosistema degli strumenti: l'emergere di SQL è stata una vera e propria rivoluzione, e da allora nulla è cambiato. È un linguaggio incredibilmente potente, ma anche piuttosto complesso. La necessità di costruire query per il database in un nuovo linguaggio, composto da frammenti JSON, è considerata da persone con esperienza in SQL come un grande passo indietro. Esiste un'intera galassia di strumenti che interagiscono con i database SQL: dai IDE agli strumenti di reportistica. Passare a un database che non supporta SQL significa che non puoi utilizzare la maggior parte di questi strumenti o che devi convertire i dati in SQL per utilizzarli, il che può rivelarsi più complicato di quanto pensi.
Molti sviluppatori che hanno adoperato MongoDB non comprendevano a fondo i compromessi e spesso si immergevano alla cieca, installandolo come principale sistema di archiviazione dei dati. Dopo aver fatto ciò, tornare indietro può risultare incredibilmente difficile.
Cosa si poteva fare in modo diverso?
Non tutti si sono tuffati a capofitto e si sono scontrati con il fondo. Ma molti progetti hanno installato MongoDB in contesti in cui semplicemente non si adattava — e dovranno convivere con essa ancora per molti anni. Se queste organizzazioni avessero speso un po' di tempo a riflettere e pianificare metodicamente la scelta delle tecnologie, molte avrebbero fatto una scelta differente.
Come scegliere la tecnologia giusta? Ci sono stati alcuni tentativi di creare un framework sistematico per la valutazione delle tecnologie, come e , ma credo che sia un'eccessiva complessità.
Molte tecnologie possono essere valutate razionalmente ponendo solo due domande fondamentali. Il problema sta nel trovare persone che possano rispondere responsabilmente a queste domande, dedicando tempo alla ricerca delle risposte e senza pregiudizi.
Se non stai affrontando un problema, non hai bisogno di un nuovo strumento. Punto.
Domanda 1: Quali problemi sto cercando di risolvere?
Se non ti imbatti in alcun problema, non hai bisogno di un nuovo strumento. Punto. Non cercare una soluzione e poi inventare un problema. Se non hai riscontrato un problema che la nuova tecnologia risolva significativamente meglio della tua tecnologia attuale, allora non c'è nulla di cui discutere. Se stai considerando di utilizzare questa tecnologia perché hai visto come altri la utilizzano, rifletti sui problemi che affrontano e chiediti se tu abbia gli stessi problemi. È facile adottare una tecnologia solo perché altri la utilizzano; la difficoltà sta nel capire se stai affrontando gli stessi problemi.
Domanda 2: Cosa sto perdendo?
Questa è senza dubbio una domanda più difficile, perché dovrai scavare a fondo e capire bene sia la tecnologia vecchia che quella nuova. A volte non puoi veramente comprendere la nuova finché non costruisci qualcosa con essa o non hai un collaboratore che ha esperienza in tal senso.
Se non possiedi nessuna delle due cose, ha senso riflettere sugli investimenti minimi necessari per determinare il valore di questo strumento. E se fai investimenti, quanto sarà difficile annullare la decisione?
Le persone rovinano sempre tutto
Cercando di rispondere a queste domande nel modo più obiettivo possibile, ricorda una cosa: dovrai lottare contro la natura umana. Ci sono una serie di distorsioni cognitive che devono essere superate per valutare efficacemente la tecnologia. Ecco solo alcune di esse:
- — tutti ne sono a conoscenza, ma è comunque difficile affrontarlo. Assicurati solo che la tecnologia soddisfi davvero le tue esigenze reali.
- — molti sviluppatori tendono a sottovalutare le tecnologie con cui hanno lavorato per lungo tempo e sopravvalutare i vantaggi della nuova tecnologia. Non solo i programmatori, tutti sono soggetti a questa distorsione cognitiva.
- — tendiamo a vedere ciò che c'è e a trascurare ciò che manca. Questo può portare al caos insieme all'effetto novità, poiché non solo si tende a sovrastimare la nuova tecnologia, ma si ignorano anche i suoi difetti..
La valutazione obiettiva non è semplice, ma comprendere i principali bias cognitivi aiuta a prendere decisioni più razionali.
Riepilogo
Quando emerge un'innovazione, è necessario rispondere con grande cautela a due domande:
- Questo strumento risolve un problema reale?
- Comprendiamo bene i compromessi?
Se non riuscite a rispondere con certezza a queste due domande, fate qualche passo indietro e riflettete.
Quindi, è stata davvero la scelta giusta MongoDB? Certo, sì; come nella maggior parte delle tecnologie ingegneristiche, dipende da molti fattori. Tra coloro che hanno risposto a queste due domande, molti hanno tratto beneficio da MongoDB e continuano a farlo. Chi non lo ha fatto, spero abbia ricevuto una lezione preziosa e non troppo dolorosa sul ciclo dell'hype.
Disclaimer
Voglio chiarire che non nutro né amore né odio per MongoDB. Semplicemente non abbiamo avuto problemi per i quali MongoDB sarebbe stata la soluzione migliore. So che 10gen/MongoDB Inc. inizialmente ha agito con grande audacia, impostando valori di default non sicuri e promuovendo MongoDB ovunque (soprattutto nei hackathon) come soluzione universale per la gestione di qualsiasi dato. Probabilmente è stata una cattiva decisione. Ma conferma l'approccio descritto qui: questi problemi potevano essere identificati molto rapidamente anche con una valutazione superficiale della tecnologia.
Fonte: habr.com
