L'ho scoperto di recente Red Hat rimuove il supporto MongoDB da Satellite (dicono a causa di modifiche alla licenza). Questo mi ha fatto riflettere perché negli ultimi anni ho visto un sacco di articoli su quanto sia terribile MongoDB e su come nessuno dovrebbe mai usarlo. Ma durante questo periodo MongoDB è diventato un prodotto molto più maturo. Quello che è successo? Tutto l'odio è davvero dovuto a errori nella commercializzazione iniziale di un nuovo DBMS? Oppure le persone stanno semplicemente usando MongoDB nei posti sbagliati?

Se ritieni che io stia difendendo MongoDB, leggi disclaimer alla fine dell'articolo.

Nuova tendenza

Lavoro nel settore del software da più anni di quanto possa dire, ma sono stato esposto solo a una piccola parte delle tendenze che hanno colpito il nostro settore. Ho assistito all'ascesa di 4GL, AOP, Agile, SOA, Web 2.0, AJAX, Blockchain... la lista è infinita. Ogni anno compaiono nuove tendenze. Alcuni svaniscono rapidamente, mentre altri cambiano radicalmente il modo in cui viene sviluppato il software.

Ogni nuova tendenza crea un'eccitazione generale: la gente o salta a bordo, oppure vede il rumore generato dagli altri e segue la folla. Questo processo è codificato da Gartner in ciclo pubblicitario. Sebbene controversa, questa sequenza temporale descrive approssimativamente cosa succede alle tecnologie prima che diventino utili.

Ma di tanto in tanto appare una nuova innovazione (o ha una seconda venuta, come in questo caso) guidata da una sola implementazione specifica. Nel caso di NoSQL, l’hype è stato fortemente guidato dall’emergere e dall’ascesa fulminea di MongoDB. MongoDB non ha dato il via a questa tendenza: infatti, le grandi aziende Internet hanno iniziato ad avere problemi nell’elaborazione di grandi quantità di dati, il che ha portato al ritorno di database non relazionali. Il movimento complessivo è iniziato con progetti come Bigtable di Google e Cassandra di Facebook, ma è stato MongoDB a diventare l'implementazione di database NoSQL più conosciuta e accessibile a cui la maggior parte degli sviluppatori aveva accesso.

Nota: potresti pensare che sto confondendo i database di documenti con database a colonne, archivi chiave/valore o uno qualsiasi dei numerosi altri tipi di archivi dati che rientrano nella definizione generale NoSQL. E hai ragione. Ma in quel momento regnava il caos. Tutti sono ossessionati da NoSQL, lo sono diventati tutti абсолютно necessario, anche se molti non hanno visto le differenze tra le diverse tecnologie. Per molti, MongoDB è diventato sinonimo di NoSQL.

E gli sviluppatori ci si sono lanciati sopra. L’idea di un database senza schema che si ridimensiona magicamente per risolvere qualsiasi problema era piuttosto allettante. Intorno al 2014, sembrava che ovunque un anno prima utilizzassero database relazionali come MySQL, Postgres o SQL Server, avessero iniziato a implementare database MongoDB. Alla domanda sul perché, potresti ottenere una risposta dal banale "questa è la scala del web" al più ponderato "i miei dati sono strutturati in modo molto approssimativo e si adattano bene a un database senza uno schema".

È importante ricordare che MongoDB, e i database di documenti in generale, risolvono una serie di problemi con i database relazionali tradizionali:

• Schema rigoroso: Con un database relazionale, se hai dati generati dinamicamente, sei costretto a creare un gruppo di colonne di dati "varie" casuali, inserire BLOB di dati o utilizzare la configurazione EAV...tutto ciò presenta notevoli inconvenienti.
• Scalabilità della difficoltà: Se ci sono così tanti dati che non possono stare su un server, MongoDB offre meccanismi per consentirne la scalabilità su più macchine.
• Modifiche circuitali complesse: nessuna migrazione! In un database relazionale, modificare la struttura del database può rappresentare un grosso problema (soprattutto quando sono presenti molti dati). MongoDB è stato in grado di semplificare notevolmente il processo. E lo ha reso così semplice che puoi semplicemente aggiornare il circuito mentre procedi e andare avanti molto rapidamente.
• Prestazioni di registrazione: le prestazioni di MongoDB erano buone, soprattutto se configurato correttamente. Anche la configurazione pronta all'uso di MongoDB, per la quale è stata spesso criticata, ha mostrato numeri di prestazioni impressionanti.

Tutti i rischi sono su di te

I potenziali vantaggi di MongoDB erano enormi, soprattutto per alcune classi di problemi. Se leggi l'elenco sopra senza comprendere il contesto e senza esperienza, potresti avere l'impressione che MongoDB sia davvero un DBMS rivoluzionario. L'unico problema era che i vantaggi sopra elencati comportavano una serie di avvertenze, alcune delle quali sono elencate di seguito.

Per essere onesti, nessuno alla 10gen/MongoDB Inc. non dirò che quanto segue non è vero, questi sono solo compromessi.

• Transazioni perse: Le transazioni sono una caratteristica fondamentale di molti database relazionali (non tutti, ma la maggior parte). Transazionale significa che è possibile eseguire più operazioni in modo atomico e garantire che i dati rimangano coerenti. Naturalmente, con un database NoSQL, la transazionalità può essere all'interno di un singolo documento oppure è possibile utilizzare commit in due fasi per ottenere la semantica transazionale. Ma dovrai implementare questa funzionalità da solo... il che può essere un compito difficile e dispendioso in termini di tempo. Spesso non ci si rende conto che c'è un problema finché non si vedono i dati nel database finire in stati non validi perché l'atomicità delle operazioni non può essere garantita. Nota: molte persone mi hanno detto che MongoDB 4.0 ha introdotto le transazioni lo scorso anno, ma con alcune limitazioni. Il punto dell’articolo rimane lo stesso: valuta quanto bene la tecnologia soddisfa le tue esigenze.
• Perdita di integrità relazionale (chiavi esterne): Se i tuoi dati hanno relazioni, dovrai applicarli nell'applicazione. Avere un database che rispetti queste relazioni toglierà molto lavoro all'applicazione e quindi ai tuoi programmatori.
• Mancanza di capacità di applicare la struttura dei dati: Gli schemi rigidi a volte possono essere un grosso problema, ma sono anche un potente meccanismo per una buona strutturazione dei dati se usati con saggezza. I database di documenti come MongoDB offrono un'incredibile flessibilità dello schema, ma questa flessibilità elimina la responsabilità di mantenere puliti i dati. Se non ti prendi cura di loro, finirai per scrivere molto codice nella tua applicazione per tenere conto dei dati che non sono archiviati nella forma prevista. Come diciamo spesso nella nostra azienda Simple Thread... un giorno l'applicazione verrà riscritta, ma i dati vivranno per sempre. Nota: MongoDB supporta il controllo dello schema: è utile, ma non fornisce le stesse garanzie di un database relazionale. Innanzitutto, l'aggiunta o la modifica di un controllo dello schema non influisce sui dati esistenti nella raccolta. Spetta a te assicurarti di aggiornare i dati secondo il nuovo schema. Decidi tu stesso se questo è sufficiente per le tue esigenze.
• Linguaggio di query nativo/perdita dell'ecosistema di strumenti: L'avvento di SQL è stata una rivoluzione assoluta e da allora nulla è cambiato. È un linguaggio incredibilmente potente, ma anche piuttosto complesso. La necessità di costruire query di database in un nuovo linguaggio composto da frammenti JSON è considerata un grande passo indietro dalle persone che hanno esperienza di lavoro con SQL. Esiste un intero universo di strumenti che interagiscono con i database SQL, dagli IDE agli strumenti di reporting. Passare a un database che non supporta SQL significa che non puoi utilizzare la maggior parte di questi strumenti o che devi tradurre i dati in SQL per usarli, il che può essere più difficile di quanto pensi.

Molti sviluppatori che si sono rivolti a MongoDB non hanno realmente compreso i compromessi e spesso si sono tuffati a capofitto nell'installarlo come archivio dati principale. Dopo questo, spesso era incredibilmente difficile tornare indietro.

Cosa si sarebbe potuto fare diversamente?

Non tutti si sono buttati a capofitto e hanno toccato il fondo. Ma molti progetti hanno installato MongoDB in luoghi in cui semplicemente non si adattava e dovranno conviverci per molti anni a venire. Se queste organizzazioni avessero dedicato del tempo e riflettuto metodicamente sulle loro scelte tecnologiche, molte avrebbero fatto scelte diverse.

Come scegliere la tecnologia giusta? Ci sono stati diversi tentativi di creare un quadro sistematico per la valutazione della tecnologia, come ad esempio "Quadro per l'introduzione delle tecnologie nelle organizzazioni software" и "Quadro per la valutazione delle tecnologie software", ma mi sembra che questa sia una complessità inutile.

Molte tecnologie possono essere valutate in modo intelligente ponendo solo due domande fondamentali. Il problema è trovare persone che possano rispondere in modo responsabile, prendendosi il tempo necessario per trovare le risposte e senza pregiudizi.

Se non riscontri alcun problema, non hai bisogno di un nuovo strumento. Punto.

Domanda 1: quali problemi sto cercando di risolvere?

Se non riscontri alcun problema, non hai bisogno di un nuovo strumento. Punto. Non è necessario cercare una soluzione e poi inventare un problema. A meno che tu non abbia riscontrato un problema che la nuova tecnologia risolve significativamente meglio di quella esistente, non c'è nulla di cui discutere qui. Se stai pensando di utilizzare questa tecnologia perché hai visto altri usarla, pensa ai problemi che devono affrontare e chiedi se anche tu ne hai. È facile accettare una tecnologia perché altri la usano, la sfida è capire se si affrontano gli stessi problemi.

Domanda 2: cosa mi manca?

Questa è sicuramente una domanda più difficile perché dovrai approfondire e avere una buona conoscenza sia della vecchia che della nuova tecnologia. A volte non puoi davvero capirne uno nuovo finché non hai costruito qualcosa con esso o hai qualcuno con quell'esperienza.

Se non hai nessuno dei due, allora ha senso pensare all’investimento minimo possibile per determinare il valore di questo strumento. E una volta effettuato l’investimento, quanto sarà difficile invertire la decisione?

Le persone rovinano sempre tutto

Mentre cerchi di rispondere a queste domande nel modo più imparziale possibile, ricorda una cosa: dovrai combattere la natura umana. Esistono numerosi pregiudizi cognitivi che devono essere superati per valutare efficacemente la tecnologia. Qui ci sono solo alcune:

• L’effetto dell’adesione alla maggioranza - Tutti lo conoscono, ma è ancora difficile combatterlo. Assicurati solo che la tecnologia corrisponda effettivamente alle tue reali esigenze.
• effetto novità — Molti sviluppatori tendono a sottovalutare le tecnologie con cui hanno lavorato a lungo e a sopravvalutare i vantaggi delle nuove tecnologie. Non sono solo i programmatori, tutti sono suscettibili a questo pregiudizio cognitivo.
• Effetto delle caratteristiche positive - Tendiamo a vedere cosa c'è e a perdere di vista ciò che manca. Ciò può portare al caos se combinato con l’effetto novità, poiché non solo si sopravvaluta intrinsecamente la nuova tecnologia, ma si ignorano anche i suoi difetti.

La valutazione oggettiva non è facile, ma comprendere i pregiudizi cognitivi sottostanti ti aiuterà a prendere decisioni più razionali.

Riassunto

Ogni volta che appare un’innovazione, è necessario rispondere con grande attenzione a due domande:

• Questo strumento risolve un problema reale?
• Comprendiamo bene i compromessi?

Se non riesci a rispondere con sicurezza a queste due domande, fai qualche passo indietro e pensa.

Quindi MongoDB è stata addirittura la scelta giusta? Certo che si; Come per la maggior parte delle tecnologie ingegneristiche, ciò dipende da molti fattori. Tra coloro che hanno risposto a queste due domande, molti hanno beneficiato di MongoDB e continuano a farlo. Per coloro che non l'hanno fatto, spero che tu abbia imparato una lezione preziosa e non troppo dolorosa su come superare il ciclo dell'hype.

Disclaimer

Ci tengo a precisare che non ho né un rapporto di amore né di odio con MongoDB. Semplicemente non abbiamo avuto il tipo di problemi che MongoDB è più adatto a risolvere. So che 10gen/MongoDB Inc. all'inizio è stato molto audace, impostando impostazioni predefinite non sicure e promuovendo MongoDB ovunque (specialmente negli hackathon) come soluzione universale per lavorare con qualsiasi dato. Probabilmente è stata una decisione sbagliata. Ma ciò conferma l'approccio qui descritto: questi problemi potrebbero essere rilevati molto rapidamente anche con una valutazione superficiale della tecnologia.

Fonte: habr.com