Cassandra contro MongoDB
Stai considerando Cassandra o MongoDB come archivio dati per il tuo prossimo progetto? Vuoi confrontare i due database? Cassandra e MongoDB sono entrambi database "NoSQL", ma la realtà è che sono molto diversi. Hanno punti di forza e proposte di valore molto diversi, quindi qualsiasi confronto deve essere sfumato. Cominciamo con i requisiti iniziali... Nessuno di questi database sostituisce RDBMS, né sono database "ACID". Pertanto, se disponi di un carico di lavoro transazionale in cui normalizzazione e coerenza sono i requisiti principali, nessuno di questi database funzionerà per te. È meglio attenersi ai database relazionali tradizionali come MySQL, PostgreSQL, Oracle, ecc. Ora che abbiamo i database relazionali fuori mano, consideriamo le principali differenze tra Cassandra e MongoDB che ti aiuteranno a prendere la decisione. In questo post, non discuterò funzioni specifiche, ma evidenzierò alcune differenze strategiche di alto livello per aiutarti a fare la tua scelta.
1. Modello a oggetti espressivo
MongoDB supporta un modello a oggetti ricco ed espressivo. Gli oggetti possono avere proprietà e gli oggetti possono essere nidificati l'uno nell'altro (per più livelli). Questo modello è molto "orientato agli oggetti" e può rappresentare facilmente qualsiasi struttura di oggetti nel tuo dominio. Puoi anche indicizzare la proprietà di qualsiasi oggetto a qualsiasi livello della gerarchia:questo è straordinariamente potente! Cassandra, invece, propone una struttura tabellare abbastanza tradizionale con righe e colonne. I dati sono più strutturati e ogni colonna ha un tipo specifico che può essere specificato in fase di creazione.
Verdetto:se il tuo dominio problematico ha bisogno di un modello di dati avanzato, l'hosting MongoDB è più adatto a te.
2. Indici secondari
Gli indici secondari sono un costrutto di prima classe in MongoDB. Ciò semplifica l'indicizzazione di qualsiasi proprietà di un oggetto archiviato in MongoDB anche se è nidificato. Ciò rende davvero facile eseguire query in base a questi indici secondari. Cassandra ha solo un supporto superficiale per gli indici secondari. Anche gli indici secondari sono limitati a singole colonne e confronti di uguaglianza. Se esegui principalmente query tramite la chiave primaria, Cassandra funzionerà bene per te.
Verdetto: se la tua applicazione ha bisogno di indici secondari e ha bisogno di flessibilità nel modello di query, MongoDB è più adatto a te.
3. Alta disponibilità
MongoDB supporta un modello "master singolo". Ciò significa che hai un nodo master e un certo numero di nodi slave. In caso di caduta del padrone, uno degli schiavi viene eletto padrone. Questo processo avviene automaticamente ma richiede tempo, in genere 10-40 secondi. Durante questo periodo di elezione del nuovo leader, il tuo set di repliche è inattivo e non può accettare scritture. Funziona per la maggior parte delle applicazioni, ma alla fine dipende dalle tue esigenze. Cassandra supporta un modello "multiplo master". La perdita di un singolo nodo non influisce sulla capacità del cluster di eseguire scritture, quindi puoi ottenere il 100% di uptime per le scritture.
Verdetto:se hai bisogno del 100% di disponibilità, Cassandra è la soluzione migliore per te.
4. Scrivere scalabilità
MongoDB con il suo modello "master singolo" può eseguire scritture solo sul primario. I server secondari possono essere utilizzati solo per le letture. Quindi, essenzialmente, se si dispone di tre repliche di nodi impostate, solo il master esegue le scritture e gli altri due nodi vengono utilizzati solo per le letture. Ciò limita notevolmente la scalabilità in scrittura. Puoi distribuire più shard ma essenzialmente solo 1/3 dei tuoi nodi di dati può accettare scritture. Cassandra con il suo modello "multiplo master" può eseguire scritture su qualsiasi server. In sostanza, la tua scalabilità in scrittura è limitata dal numero di server che hai nel cluster. Più server hai nel cluster, migliore sarà la scalabilità.
Verdetto:se la scalabilità in scrittura fa per te, Cassandra è la soluzione migliore per te.
5. Supporto del linguaggio di query
Cassandra supporta il linguaggio di query CQL che è molto simile a SQL. Se disponi già di un team di analisti di dati, questi saranno in grado di trasferire la maggior parte delle loro competenze SQL, il che è molto importante per le grandi organizzazioni. Tuttavia, CQL non è ANSI SQL completo - Ha diverse limitazioni (nessun supporto per il join, nessuna clausola OR) ecc. MongoDB a questo punto non ha supporto per un linguaggio di query. Le query sono strutturate come frammenti JSON.
Verdict:se hai bisogno del supporto del linguaggio di query, Cassandra è la soluzione migliore per te.
6. Benchmark delle prestazioni
Parliamo di prestazioni. A questo punto, probabilmente ti stai aspettando un confronto del benchmark delle prestazioni dei database. Non ho deliberatamente incluso i benchmark delle prestazioni nel confronto. In ogni confronto, dobbiamo assicurarci di fare un confronto mele-mele.
1. Modello di database - Il modello/schema del database dell'applicazione testata fa una grande differenza. Alcuni schemi sono adatti per MongoDB e altri per Cassandra. Pertanto, quando si confrontano i database è importante utilizzare un modello che funzioni ragionevolmente bene per entrambi i database.
2. Caratteristiche del carico – Le caratteristiche del carico di riferimento sono molto importanti. Per esempio. In benchmark pesanti in scrittura, mi aspetto che Cassandra fumi MongoDB. Tuttavia, nei benchmark ad alta lettura, MongoDB e Cassandra dovrebbero avere prestazioni simili.
3. Requisiti di coerenza - Questo è difficile. È necessario assicurarsi che i requisiti di coerenza di lettura/scrittura specificati siano identici in entrambi i database e non siano distorti nei confronti di un partecipante. Molto spesso in molti benchmark di "Marketing", le manopole sono sintonizzate per svantaggiare l'altro lato. Quindi, presta molta attenzione alle impostazioni di coerenza.
Un'ultima cosa da tenere a mente è che il carico del benchmark può riflettere o meno le prestazioni dell'applicazione. Quindi, affinché i benchmark siano utili, è molto importante trovare un carico di benchmark che rifletta le caratteristiche prestazionali dell'applicazione. Ecco alcuni benchmark che potresti voler esaminare:
- NoSQL Performance Benchmarks
- Cassandra vs. MongoDB vs. Couchbase vs. HBase
7. Facilità d'uso
Se avessi posto questa domanda un paio di anni fa MongoDB sarebbe il vincitore senza dubbio. È un compito abbastanza semplice far funzionare MongoDB. Negli ultimi due anni, tuttavia, Cassandra ha fatto passi da gigante in questo aspetto del prodotto. Con l'adozione di CQL come interfaccia principale per Cassandra, questo ha fatto un ulteriore passo avanti:hanno reso molto semplice per legioni di programmatori SQL utilizzare Cassandra molto facilmente.
Verdetto:entrambi sono abbastanza facili da usare e si potenziano.
8. Aggregazione nativa
MongoDB ha un framework di aggregazione integrato per eseguire una pipeline ETL per trasformare i dati archiviati nel database. Questo è ottimo per lavori di piccole e medie dimensioni, ma poiché le tue esigenze di elaborazione dei dati diventano più complicate, diventa difficile eseguire il debug del framework di aggregazione. Cassandra non dispone di un framework di aggregazione integrato. Per questo vengono utilizzati strumenti esterni come Hadoop, Spark.
9. Modelli senza schema
In MongoDB, puoi scegliere di non applicare alcuno schema ai tuoi documenti. Sebbene questa fosse l'impostazione predefinita nelle versioni precedenti, nella versione più recente hai la possibilità di applicare uno schema per i tuoi documenti. Ogni documento in MongoDB può essere una struttura diversa e spetta alla tua applicazione interpretare i dati. Sebbene ciò non sia rilevante per la maggior parte delle applicazioni, in alcuni casi è importante la flessibilità aggiuntiva. Cassandra nelle versioni più recenti (con CQL come lingua predefinita) fornisce la digitazione statica. Devi definire il tipo di colonna molto in anticipo.
Per riassumere, ecco le differenze importanti nella forma della tabella: 
Se desideri visualizzare l'infografica completa, puoi visitare la nostra pagina di confronto Cassandra vs MongoDB.
