NoSQL match rancore: MongoDB vs Couchbase Server

La scelta del database giusto per il lavoro può essere un compito arduo, in particolare se stai utilizzando l'intero spazio delle opzioni SQL e NoSQL. Se stai cercando un'opzione flessibile e generica che consenta schemi fluidi e complesse strutture di dati annidate, un database di documenti potrebbe essere giusto per te. MongoDB e Couchbase Server sono due scelte popolari. Come dovresti scegliere?

MongoDB combina i vantaggi di un'immensa popolarità, il supporto per semplici ricerche di grafici e la capacità di eseguire query SQL tramite un connettore BI. Couchbase ha una propria vasta comunità di utenti, un'architettura valore-chiave performante e un linguaggio di query simile a SQL in grado di navigare in strutture di documenti nidificate.

In breve, sia MongoDB che Couchbase sono database orientati ai documenti potenti e flessibili con molti extra. Detto questo, hanno differenze importanti che inclinano l'equilibrio in un modo o nell'altro, a seconda delle tue esigenze. Per aiutarti a decidere, guideremo questi database attraverso la sfida di considerazioni chiave, coprendo il modo in cui ognuno si comporta in termini di installazione e configurazione, amministrazione, facilità d'uso, scalabilità e documentazione.

Questa discussione è basata su MongoDB 3.4 e Couchbase Server 4.6. Potresti anche controllare le mie recensioni indipendenti di MongoDB 3.4 e Couchbase Server 4.0.

Installazione e configurazione

L'installazione e la configurazione possono essere viste da due prospettive: sviluppatori che lavorano su un'istanza locale e ingegneri dell'infrastruttura che configurano un cluster di produzione iniziale. Molti database NoSQL hanno storie forti sulla cordialità degli sviluppatori, aumentando le possibilità che uno sviluppatore provi il prodotto e lo introduca nei propri sistemi. Una semplice configurazione locale è un forte punto di forza. D'altra parte, il database alla fine dimostrerà il suo valore nella produzione, quindi l'impostazione della produzione è altrettanto importante per essere corretta.

Configurazione per sviluppatori

Piuttosto che utilizzare binari in esecuzione su bare metal, vedremo cosa serve per configurare questi due database in un ambiente Docker. La configurazione Docker sia per MongoDB che per Couchbase è piuttosto semplice. Couchbase richiede che alcune porte extra siano esposte, ma è una questione semplice da affrontare. Una volta che le immagini vengono estratte e i contenitori vengono avviati, c'è una notevole differenza nell'esperienza dello sviluppatore. Con MongoDB, hai finito. Puoi connetterti tramite un'applicazione o la shell Mongo e metterti subito al lavoro. Al contrario, Couchbase ti guida attraverso un processo di configurazione obbligatorio tramite l'interfaccia utente in cui ti trovi di fronte a una serie di opzioni di configurazione rivolte agli ingegneri dell'infrastruttura. In qualità di sviluppatore, puoi mantenere le opzioni selezionate e utilizzare un bucket predefinito, ma aggiunge attrito all'esperienza.

MongoDB vince questo, ma non senza un avvertimento. Solo perché la distribuzione locale è stata semplice, non significa che puoi fare la stessa cosa in produzione. Può sembrare ovvio che gli ambienti di produzione richiedano maggiore attenzione e configurazione, ma i diffusi attacchi di riscatto su istanze MongoDB non protette e pubblicamente accessibili all'inizio di quest'anno suggeriscono che molti negozi stanno prendendo scorciatoie pericolose.

Vincitore round: MongoDB.

Configurazione della produzione

L'implementazione di un database distribuito nella produzione tende a coinvolgere molti passaggi e un giusto grado di coordinamento; MongoDB e Couchbase non sono diversi. In entrambi i casi, la difficoltà di configurazione dipenderà dai requisiti della distribuzione, con diversi compromessi delle prestazioni che comportano diversi livelli di complessità.  

I cluster MongoDB saranno costituiti da un set di repliche o da un cluster partizionato. Un set di repliche è un gruppo di server MongoDB che contengono tutti gli stessi dati, mentre un cluster frammentato distribuisce i dati su un numero di set di repliche. I set di replica sono semplici da configurare, costituiti da un unico tipo di server da distribuire. I cluster frammentati sono più coinvolti, richiedendo la distribuzione di tre diversi tipi di server, dove ciascuno viene replicato. I cluster possono essere configurati tramite flag della riga di comando, file di configurazione e comandi di database.

I cluster Couchbase possono essere costituiti da un singolo tipo di server o più tipi di server, a seconda delle caratteristiche di prestazioni richieste dal cluster. L'architettura Couchbase è costituita da diversi servizi che possono essere abilitati o disabilitati in base al nodo. In uno scenario semplice, abiliti tutti i servizi su tutti i nodi. Tuttavia, se si desidera ottimizzare le esigenze di ciascun servizio o si desidera ridimensionare ciascun servizio in modo indipendente, sarà necessario iniziare a configurare diversi tipi di server, allocando hardware di base per il servizio dati, SSD per il servizio di indicizzazione, ottimizzato per CPU per il servizio di query e così via. I cluster possono essere configurati tramite l'interfaccia utente Web incorporata, l'interfaccia della riga di comando e l'API REST.

Per quanto riguarda la configurazione della produzione dell'infrastruttura dati, sia MongoDB che Couchbase sono abbastanza chiari. Certo, puoi immergerti nelle opzioni di configurazione e ottimizzazione e non uscire mai, ma nella maggior parte dei casi queste saranno più facili per gli ingegneri dell'infrastruttura.

Vincitore round: pareggio. 

Amministrazione

Una volta che il database è in esecuzione in produzione e accetta il traffico, l'amministrazione diventa una preoccupazione chiave. Per valutare la facilità di amministrazione, esaminerò il processo di backup, gli aggiornamenti del database e gli approcci di monitoraggio.

Backup

I backup sono una parte importante dell'igiene dei database di produzione e l'esecuzione di database in modo distribuito e altamente disponibile non cambia di un po '.

MongoDB offre diverse opzioni per il backup dei dati di un cluster in esecuzione. Se il sistema operativo sottostante supporta gli snapshot point-in-time, puoi fare affidamento su quella funzione per acquisire un backup in un momento preciso nel tempo. Questo diventa un po 'complicato per il backup di cluster frammentati perché dovrai eseguire lo snapshot di un secondario di ogni frammento e di un server di configurazione allo stesso tempo.

Strumenti a livello di sistema come cp o rsync possono essere utilizzati per copiare i file di database in un'altra posizione, ma le scritture devono essere sospese durante il processo a causa della natura di tali strumenti. Sebbene MongoDB venga fornito con strumenti a riga di comando per il backup e il ripristino dei database, questi strumenti non sono consigliati per cluster più grandi. In alternativa, puoi pagare per Cloud Manager o Ops Manager o distribuire tramite la piattaforma MongoDB Atlas DBaaS per ottenere strumenti basati sull'interfaccia utente che si occuperanno di backup e ripristini per te.

Couchbase viene fornito con strumenti della riga di comando per eseguire il backup dei dati dai vari servizi e questi possono essere configurati per eseguire backup completi o due tipi di backup incrementali. I backup incrementali possono essere incrementali dall'ultimo backup completo (cumulativo incrementale) o incrementali dall'ultimo backup di qualsiasi tipo (differenziale incrementale). Ciò consente strutture di backup complesse che richiedono diversi livelli di spazio di archiviazione e implicano diversi livelli di complessità di ripristino.

I clienti aziendali possono attingere all'utilità cbbackupmgr, che utilizza diverse strutture di dati sottostanti per ottenere prestazioni migliori durante il backup dei dati.

Vincitore del round: Couchbase, grazie alla sua maggiore flessibilità e al supporto per i backup incrementali.

Aggiornamento

Un cluster di lunga durata dovrebbe avere un percorso di aggiornamento chiaro e facile. Più difficile è l'aggiornamento, meno è probabile che venga mantenuto aggiornato. Ciò significa che sia gli sviluppatori che gli amministratori perderanno nuove funzionalità.

Gli aggiornamenti di MongoDB sono meglio compresi dal livello del set di repliche. Se esegui un cluster partizionato, segui principalmente i passaggi per l'aggiornamento dei set di repliche su ogni frammento. All'interno di un set di repliche, ogni secondario viene arrestato, aggiornato in posizione e avviato. Una volta che i secondari sono operativi e coerenti con il primario, viene indotto un failover e il primo primario può essere rimosso e aggiornato. Verrà riavviato come secondario e recupererà le scritture perse quando è offline. Pertanto, gli aggiornamenti sono principalmente un processo in linea, ma il failover principale risulterà probabilmente in 10-20 secondi di nessuna scrittura, quindi è necessaria una finestra di manutenzione con tempi di inattività accettabili.

Couchbase approccia gli aggiornamenti nello stesso modo in cui si aggiungere o rimuovere un nodo da un cluster. Tutti i dati del nodo di aggiornamento devono essere ribilanciati nel cluster, quindi ribilanciati di nuovo quando l'aggiornamento è completo e il nodo si ricongiunge al cluster. Questo processo di ribilanciamento deve avvenire per ogni nodo del cluster, uno dopo l'altro. Questo richiederà molto più tempo rispetto all'aggiornamento di un cluster MongoDB, a causa di tutti i dati che devono essere spostati. Un'altra opzione è portare offline l'intero cluster, aggiornare ogni nodo e riportarli tutti online.

Sebbene il percorso di aggiornamento di Couchbase non richieda tempi di inattività, il processo è lungo e richiede una notevole quantità di dati mescolati per funzionare.

Vincitore round: pareggio. Tiebreaker: se il tempo di inattività della manutenzione è accettabile, vince MongoDB. In caso contrario, Couchbase è l'unica scelta.

Monitoraggio

La visibilità in un cluster in esecuzione è ovviamente essenziale per una corretta amministrazione del database. Quando le cose vanno male, niente è peggio che avere una visione limitata della verità nel cluster.

MongoDB offre strumenti e comandi CLI all'interno della shell che forniscono metriche sull'attività e sulle prestazioni dell'istanza. Oltre a ciò, MongoDB ti indirizzerà utilmente a strumenti di terze parti o ai suoi prodotti aziendali (Cloud Manager, Ops Manager, Atlas).

Couchbase, d'altra parte, viene fornito con un'interfaccia utente Web che include statistiche e visualizzazioni per istanze, nodi, prestazioni delle query e altro ancora. Inoltre, Couchbase può essere configurato per inviare avvisi e-mail quando determinate statistiche non rientrano nell'intervallo.

Vincitore round: Couchbase, per visualizzazioni e avvisi preconfigurati.

Facilità di utilizzo

Dopo che il database è stato impostato e tutte le nostre esigenze amministrative sono state soddisfatte, la preoccupazione principale si sposta dalle operazioni all'utilizzo. Lo suddividerò in modellazione dei dati, progettazione degli indici, query di base e aggregazioni.

Modellazione dei dati

In quanto database di documenti, né MongoDB né Couchbase possono evitare la sfida di come trattare i dati relazionali. Entrambi offrono la possibilità di archiviare dati relazionali come dati annidati e denormalizzati, nonché sotto forma di riferimenti ad altri documenti di primo livello. Questo approccio all'archiviazione dei dati finisce per essere il principale punto di considerazione per la modellazione dei dati per entrambi i database, nonostante ciascuno supporti una gamma crescente di casi d'uso, funzionalità e modelli di query.

Vincitore round: pareggio.

Progettazione dell'indice

Gli indici svolgono la stessa funzione nei database dei documenti come nei database relazionali. Cioè, rappresentano determinati dati in modi più efficienti per migliorare le prestazioni delle query. MongoDB e Couchbase adottano approcci molto diversi per la progettazione e la creazione di indici.

MongoDB supporta la creazione di indici per uno o più campi all'interno di un documento, consentendo di specificare l'ordine e la direzione (ascendente o discendente) degli indici standard. È anche possibile includere indici geospaziali speciali e indici full-text come parte della stessa sintassi. Il motore di query utilizzerà tali indici, i prefissi di tali indici o una combinazione di diversi indici per accelerare le richieste.

Couchbase si basa su due diversi meccanismi per migliorare le prestazioni delle query: le visualizzazioni MapReduce e il Global Secondary Index (GSI). Le viste MapReduce sono costituite da codice JavaScript definito dall'utente che elabora i dati mentre passano attraverso il sistema, come una pre-aggregazione incrementale. Le viste MapReduce possono essere semplici come consentire ricerche di documenti su un campo interno oppure possono includere una logica più complessa che esegue calcoli e aggregazioni sui dati all'interno dei documenti.

Scrivere MapReduce in JavaScript per supportare le query è un po 'ingombrante, quindi in genere si consiglia di utilizzare il GSI ove possibile. Gli indici nel GSI sono descritti utilizzando N1QL (pronunciato "nickel"), un'implementazione SQL parziale sopra Couchbase. La sintassi N1QL è abbastanza chiara e le query N1QL sono di gran lunga migliori di MapReduce, ma è necessario posizionare l'indice su un nodo specifico. Se vuoi che un indice sia altamente disponibile, devi creare manualmente quell'indice su più di un nodo.

Vincitore del round: MongoDB, per la sua API di indicizzazione consolidata e la capacità di evitare del tutto MapReduce.

Domande di base

Dato un modello di dati appropriato, la maggior parte delle query al database tendono ad essere semplici. Al di là delle operazioni CRUD in cui è noto l'ID del documento in questione, è importante essere in grado di esprimere diversi modi di filtrare i documenti e scegliere quali campi ci interessano.

MongoDB descrive le query in JSON, fornendo una sintassi dichiarativa per specificare condizioni e filtri sui campi. Il documento di query può essere costituito da un numero qualsiasi di selettori di query che descrivono l'aspetto che dovrebbe avere il set di risultati. Intervalli, uguaglianza, ricerca di testo e query geospaziali possono essere definiti all'interno di questo documento di query. Il documento sostiene operatori booleani, in modo che più clausole di query possono essere logicamente uniti insieme AND, ORe così via. Il documento di query può rapidamente trasformarsi in un documento JSON fortemente annidato, che a volte può essere travolgente e richiede sicuramente un po 'di tempo per abituarsi. È anche possibile utilizzare le proiezioni nelle query, il che consente di restituire solo i campi che ti interessano e di ridurre la dimensione complessiva del risultato sul filo.