Recentemente ho scoperto che (si dice a causa delle modifiche alla licenza). Questo mi ha fatto riflettere, perché negli ultimi anni ho visto un sacco di articoli su quanto sia brutta MongoDB e che nessuno dovrebbe mai usarla. Ma nel frattempo, MongoDB è diventata un prodotto molto più maturo. Cosa è veramente successo? È tutta questa avversione dovuta a errori commessi all'inizio del marketing di questo nuovo DBMS? Oppure le persone semplicemente non lo stanno utilizzando dove sarebbe necessario?
Se ti sembra che stia difendendo MongoDB, ti invito a leggere alla fine dell'articolo.
Una nuova tendenza
Lavoro nel settore del software da più anni di quanti possa dire, ma ho comunque vissuto solo una piccola parte delle tendenze che hanno colpito la nostra industria. Ho assistito alla crescita di 4GL, AOP, Agile, SOA, Web 2.0, AJAX, blockchain… l'elenco è infinito. Ogni anno emergono nuove tendenze. Alcune si esauriscono rapidamente, altre cambiano radicalmente i modi di sviluppo del software.
Attorno a ogni nuova tendenza si crea un certo fermento: le persone o saltano nella barca da sole, oppure vedono il clamore generato dagli altri e seguono la folla. Questo processo è stato codificato dalla società Gartner in . Sebbene controverso, questo grafico descrive grosso modo cosa succede alle tecnologie prima che diventino realmente utili.
Di tanto in tanto, emerge (o avviene una sorta di secondo avvento, come in questo caso) una nuova innovazione, guidata solo da una sua specifica realizzazione. Nel caso di NoSQL, l'hype è stato fortemente influenzato dall'emergere e dalla rapida ascesa di MongoDB. Non è MongoDB a determinare questa tendenza: in realtà, grandi aziende internet hanno iniziato a riscontrare problemi nella gestione di grandi volumi di dati, che hanno portato a una rinascita dei database non relazionali. Il movimento generale è iniziato con progetti come Bigtable di Google e Cassandra di Facebook, ma è MongoDB ad essere diventata la realizzazione di database NoSQL più conosciuta e accessibile, a cui la maggior parte degli sviluppatori ha potuto accedere.
Nota: potresti pensare che stia mescolando i database documentali con i database a colonne, gli store di chiavi/valori o qualsiasi altro tra i numerosi tipi di archiviazione dati che rientrano nella definizione generale di NoSQL. E hai ragione. Ma a quell'epoca regnava il caos. Tutti erano ossessionati dal NoSQL, era diventato assolutamente necessario, anche se molti non vedevano le differenze tra le diverse tecnologie. Per molti MongoDB era diventato il sinonimo di NoSQL.
E gli sviluppatori si sono fiondati su di essa. L'idea di un database senza schemi, che si scalava magicamente per risolvere qualsiasi problema, era piuttosto allettante. Intorno al 2014, sembrava che ovunque ci fosse stato un database relazionale come MySQL, Postgres o SQL Server, venissero distribuiti database MongoDB. Alla domanda del perché, si poteva ottenere una risposta che spaziava dal banale «è la scalabilità del web» a una più ponderata «i miei dati sono molto poco strutturati e si adattano bene a un database senza schemi».
È importante ricordare che MongoDB e i database documentali, in generale, risolvono una serie di problemi delle tradizionali basi di dati relazionali:
- Schema rigido: con un database relazionale, se hai dati dinamicamente generati, sei costretto a creare una serie di colonne di dati «diverse» casuali, a infilare blob di dati o a utilizzare una configurazione … tutto questo ha notevoli svantaggi.
- Difficoltà di scalabilità: se i dati sono così tanti da non poter essere contenuti su un singolo server, MongoDB ha proposto meccanismi per scalare su più macchine.
- Modifiche complesse dello schema: nessuna migrazione! In un database relazionale cambiare la struttura del DB può diventare un enorme problema (soprattutto quando ci sono tanti dati). MongoDB ha notevolmente semplificato il processo rendendolo così facile che puoi semplicemente aggiornare lo schema al volo e proseguire rapidamente.
- Prestazioni di scrittura: le prestazioni di MongoDB sono state buone, soprattutto con una corretta configurazione. Anche la configurazione di MongoDB out-of-the-box, per la quale è stata spesso criticata, ha dimostrato alcune prestazioni impressionanti.
Tutti i rischi ricadono su di te
I potenziali vantaggi di MongoDB sono stati enormi, specialmente per alcune classi di problemi. Leggendo l'elenco sopra senza comprendere il contesto e senza avere esperienza, si potrebbe avere l'impressione che MongoDB sia davvero un database di tipo rivoluzionario. L'unico problema era che i vantaggi elencati erano accompagnati da una serie di riserve, alcune delle quali sono indicate di seguito.
A dire il vero, nessuno in 10gen/MongoDB Inc. affermerà che quanto segue non è vero; sono semplicemente compromessi.
- Perdita di transazioni: le transazioni sono una caratteristica fondamentale di molti database relazionali (non di tutti, ma della maggior parte). La transazionalità significa che puoi eseguire più operazioni in modo atomico e puoi garantire che i dati rimangano coerenti. Certo, con un database NoSQL, la transazionalità può avvenire all'interno di un singolo documento oppure puoi utilizzare il commit a due fasi per ottenere la semantica transazionale. Tuttavia, dovrai implementare tu stesso questa funzionalità… 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 si trovano in stati non validi, perché non è possibile garantire l'atomicità delle operazioni. Nota: molte persone mi hanno riferito che l'anno scorso in MongoDB 4.0 sono state introdotte transazioni, ma con alcune limitazioni. La conclusione dell'articolo rimane invariata: valuta quanto la tecnologia soddisfi le tue esigenze.
- Perdita dell'integrità relazionale (chiavi esterne): se nei tuoi dati ci sono relazioni, dovrai applicarle nell'applicazione. Avere un database che rispetta queste relazioni semplificherà notevolmente il lavoro con le applicazioni e, di conseguenza, quello dei tuoi programmatori.
- Impossibilità di applicare la struttura dei dati: schemi rigidi possono a volte diventare un grande problema, ma rappresentano anche un potente strumento per una buona strutturazione dei dati, se utilizzati correttamente. I database documentali, come MongoDB, offrono incredibile flessibilità nello schema, ma questa flessibilità riduce la responsabilità di mantenere i dati puliti. Se non te ne prendi cura, alla fine dovrai scrivere molto codice nell'applicazione per gestire i dati che non sono conservati nella forma che ti aspetti. Come si dice spesso nella nostra azienda Simple Thread… l'applicazione sarà riscritta prima o poi, mentre i dati vivranno per sempre. Nota: MongoDB supporta la validazione degli schemi: è utile, ma non fornisce le stesse garanzie di un database relazionale. Prima di tutto, l'aggiunta o la modifica della validazione degli schemi non influisce sui dati esistenti nella collezione. Devi assicurarti di aggiornare i dati secondo il nuovo schema. Decidi tu se questo è sufficiente per le tue esigenze.
- Linguaggio di query proprietario / perdita dell'ecosistema di strumenti: La comparsa di SQL è stata una vera 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 fatto di frammenti JSON è vista come un grande passo indietro da chi ha esperienza con SQL. Esiste un'intera galassia di strumenti che interagiscono con database SQL: dagli 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 usarli, il che potrebbe rivelarsi più complicato di quanto tu possa pensare.
Molti sviluppatori che si sono avvicinati a MongoDB non comprendevano a fondo i compromessi e spesso si tuffavano a capofitto, installandola come principale sistema di archiviazione dei dati. Dopo un'esperienza del genere, tornare indietro era spesso incredibilmente difficile.
Cosa si sarebbe potuto fare diversamente?
Non tutti si sono lanciati a capofitto senza pensarci. Ma numerosi progetti hanno installato MongoDB in contesti dove semplicemente non era adatta, e dovranno convivere con essa per molti anni a venire. Se queste organizzazioni avessero dedicato del tempo a riflettere methodicamente sulla scelta delle tecnologie, molte avrebbero fatto scelte diverse.
Come scegliere la tecnologia giusta? Ci sono state varie tentativi di creare un framework sistematico per valutare le tecnologie, come e , ma mi sembra che sia un'eccessiva complessità.
Molte tecnologie possono essere valutate in modo ragionevole ponendo semplicemente due domande fondamentali. Il problema sta nel trovare persone che possano rispondere a queste domande con responsabilità, dedicando tempo per cercare 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 stai affrontando un problema, non hai bisogno di un nuovo strumento. Punto. Non hai bisogno di cercare una soluzione e poi inventare un problema. Se non hai incontrato un problema che la nuova tecnologia risolve significativamente meglio della tua tecnologia attuale, non c'è nulla da discutere. Se stai considerando l'uso di questa tecnologia solo perché l'hai vista usare da altri, considera quali problemi affrontano e chiediti se hai gli stessi problemi. È facile adottare una tecnologia solo perché è utilizzata da altri; la difficoltà sta nel capire se stai affrontando le stesse sfide.
Domanda 2: Cosa sto perdendo?
Questa è sicuramente una domanda più difficile, perché richiede di scavare e comprendere a fondo sia la tecnologia vecchia che quella nuova. A volte non puoi veramente comprendere la nuova tecnologia finché non costruisci qualcosa utilizzando essa o finché non hai un collaboratore con tale esperienza.
Se non hai né l'uno né l'altro, ha senso considerare investimenti minimi per valutare il valore di questo strumento. E se decidi di investire, quanto sarà difficile annullare la decisione?
Le persone rovinano sempre tutto.
Nel tentativo di rispondere a queste domande il più obiettivamente possibile, ricorda una cosa: dovrai combattere con la natura umana. Ci sono vari pregiudizi cognitivi da superare per valutare la tecnologia in modo efficace. Ecco solo alcuni di essi:
- — tutti sanno di cosa si tratta, ma è comunque difficile combatterlo. Assicurati solo che la tecnologia soddisfi davvero le tue esigenze reali.
- — molti sviluppatori tendono a sottovalutare le tecnologie con cui hanno lavorato a lungo e a sovrastimare i vantaggi delle nuove tecnologie. Non solo i programmatori, tutti sono soggetti a questo pregiudizio cognitivo.
- — tendiamo a vedere ciò che c'è e a trascurare ciò che manca. Questo può portare al caos insieme all'effetto novità, poiché non solo sovrastimate la nuova tecnologia, ma ignorate anche i suoi difetti..
Una valutazione oggettiva non è facile, ma comprendere i principali bias cognitivi aiuterà a prendere decisioni più razionali.
Riepilogo
Quando si presenta un'innovazione, è necessario rispondere con molta cautela a due domande:
- Questo strumento risolve un problema reale?
- Comprendiamo bene i compromessi?
Se non riuscite a rispondere con sicurezza a queste due domande, fate un passo indietro e riflettete.
MongoDB è stata davvero una scelta giusta? Certo che sì; come nella maggior parte delle tecnologie ingegneristiche, dipende da molti fattori. Tra coloro che hanno risposto a queste due domande, molti hanno tratto vantaggi da MongoDB e continuano a farlo. Speriamo che chi non lo ha fatto abbia imparato una lezione preziosa e non troppo dolorosa sul ciclo dell'hype.
Disclaimer
Vorrei chiarire che non ho né amore né odio per MongoDB. Semplicemente non abbiamo mai avuto problemi per i quali MongoDB fosse la soluzione migliore. So che 10gen/MongoDB Inc. ha inizialmente agito in modo molto audace, impostando valori predefiniti non sicuri e promuovendo MongoDB ovunque (soprattutto nei hackathon) come la soluzione universale per gestire qualsiasi tipo di dato. Probabilmente, è stata una cattiva decisione. Ma ciò conferma l'approccio descritto qui: questi problemi potevano essere identificati molto rapidamente anche con una valutazione superficiale della tecnologia.
Fonte: habr.com
