Apache Cassandra e MongoDB a confronto

Apache Cassandra e MongoDB sono database NoSQL ampiamente utilizzati, progettati per memorizzare e gestire grandi quantità di dati.

La popolarità di questi due sistemi di database è dovuta in parte alla loro elevata scalabilità e disponibilità. Entrambi sono in uso da oltre un decennio: Cassandra è stato rilasciato come progetto open source nel 2008, mentre il rilascio di MongoDB è avvenuto l'anno successivo.

Nonostante le somiglianze, Apache Cassandra e MongoDB differiscono in modo significativo a livello di modelli di dati, architettura e altri componenti. Queste differenze fondamentali hanno un impatto sulle loro prestazioni a livello di caratteristiche chiave e possono influenzare i casi d'uso della gestione dei dati che soddisfano meglio.

Prima di confrontare Apache Cassandra e MongoDB, è utile comprendere i database NoSQL.

I database NoSQL, noti anche come database "not only SQL" o "non-SQL", sono database distribuiti. Questo significa che le informazioni al loro interno vengono replicati su vari nodi (singoli server che memorizzano i dati). Questa architettura distribuita supporta un elevato livello di disponibilità e durata; se uno o più nodi vanno offline, il resto del database può continuare a funzionare.

Tuttavia, è importante notare che i database NoSQL sono progettati per memorizzare e interrogare i dati al di fuori delle strutture tradizionali presenti nei sistemi di gestione dei database relazionali (RDBMS). Anziché aderire a una rigida struttura tabellare insita nei database relazionali tradizionali, la progettazione di database non relazionali non richiede uno schema rigido. Ciò consente una rapida scalabilità per gestire set di dati di grandi dimensioni, inclusi set di dati strutturati, semistrutturati e dati non strutturati.

(È importante notare che la scalabilità apprezzata nei database NoSQL, inclusi Cassandra e MongoDB, è la scalabilità orizzontale o "scale out". Nella scalabilità orizzontale, i workload possono essere suddivisi tra i server, a differenza della scalabilità verticale o "scale up" associata agli SQL database, che richiede l'aggiunta di memoria all'hardware esistente).

Grazie ai loro livelli di prestazioni, scalabilità e flessibilità, i database NoSQL si sono affermati come la scelta ideale per supportare applicazioni di big data e workload in tempo reale. Oltre ad Apache Cassandra e MongoDB, altri database NoSQL popolari includono DynamoDB (fornito da AWS), Redis e CouchDB.

Sebbene entrambi siano nati solo pochi anni dopo l'inizio del millennio, Apache Cassandra e MongoDB hanno storie diverse.

Apache Cassandra risale all'epoca di Facebook, intorno al 2007, quando gli ingegneri cercavano un sistema in grado di memorizzare dati per la piattaforma di messaggistica in espansione dell'azienda. Combinando modelli di database NoSQL consolidati, hanno creato un sistema con strutture di dati efficienti ed eventual consistency, in cui gli aggiornamenti si propagano fino a quando tutte le repliche non corrispondono nel tempo. Gli ingegneri hanno rilasciato Cassandra come progetto open source nel 2008. Un anno dopo, la Apache Software Foundation ne assunse la gestione. 

MongoDB è iniziato come parte di un progetto platform-as-a-service della società 10Gen nel 2007. L'azienda si è concentrata su MongoDB (il cui nome è un gioco di parole con il termine "humongous", ovvero "enorme") e lo ha sviluppato come database orientato ai documenti che funzionava velocemente ed era facile da usare. ¹

10Gen, che alla fine ha cambiato nome in MongoDB Inc., ha rilasciato MongoDB come progetto open source nel 2009. Le versioni più recenti di MongoDB, tuttavia, sono pubblicate ai sensi della Server Side Public License v1.

Le differenze fondamentali tra Apache Cassandra e MongoDB influiscono sulle loro prestazioni e sui casi d'uso ideali. Gli elementi chiave includono:

• Modelli di dati
• Architettura e storage
• Query e altri linguaggi

I database NoSQL si basano su uno dei quattro tipi di modelli di dati:

• Modello di documento: i dati vengono archiviati come documenti strutturati, in genere in JSON (JavaScript Object Notation) o BSON (Binary JSON).
• Modello a colonne larghe: i dati vengono memorizzati in tabelle con colonne sparse, il che significa che ogni riga di una tabella può avere un numero diverso di colonne.
• Modello chiave-valore: i dati vengono memorizzati come coppie chiave-valore (identificatori o etichette abbinati a valori specifici).
• Modello grafico: i dati vengono memorizzati come nodi ed edge, che rappresentano entità e relazioni.

Il modello di dati di Cassandra è un modello a colonne larghe, o "wide-column store". Ogni riga di una tabella Cassandra ha un insieme di colonne e una chiave di partizione univoca, utilizzata per distribuire i dati tra nodi e data center. Le righe sono identificate da chiavi primarie, che possono essere costituite da chiavi di partizione e, facoltativamente, da chiavi di cluster (colonne che possono identificare in modo univoco le righe all'interno di una partizione o di un gruppo correlato).

Questo approccio è più flessibile di quello dei database relazionali, in cui lo spazio è assegnato a un numero definito di colonne. Attraverso il modello di dati di Cassandra, l'utilizzo delle colonne solo in base alle necessità si traduce in uno storage più efficiente e in query più veloci. ²

Al contrario, MongoDB utilizza un modello di documento. I dati vengono memorizzati principalmente come BSON, una rappresentazione binaria di JSON sviluppata da MongoDB.

BSON aiuta a superare gli ostacoli che il JSON standard presentava per i database: supporto di tipi di dati limitati, mancanza di lunghezza fissa per gli oggetti (che rallenta la velocità di attraversamento) e mancanza di metadati (che rallenta il recupero dei documenti). BSON è stato progettato per ottimizzare la velocità e l'efficienza, attraverso la codifica delle informazioni sul formato e sulla lunghezza. Supporta anche alcuni tipi di dati JSON non nativi, come le date e i dati binari. ³

Come database NoSQL, sia Apache Cassandra che MongoDB supportano sistemi distribuiti, con data storage su più risorse, per mitigare il tempo di inattività. Tuttavia, come per i loro modelli di dati, l'architettura alla base di questa distribuzione è fondamentalmente diversa.

Apache Cassandra si basa su un'architettura peer-to-peer. Ogni nodo di un cluster Cassandra è uguale, senza fare affidamento su un nodo master. Quando i dati vengono inseriti in un cluster, viene applicata una funzione hash alla chiave di partizione della riga e l'output è utilizzato per assegnare dati a nodi specifici. I dati vengono copiati anche in altri nodi.

Il fattore di replica di un database Cassandra descrive il numero di copie dei dati memorizzati nel database. Il motore di storage di Cassandra utilizza un flusso step-by-step (o percorso di scrittura) composto da un log di commit, una tabella di memoria (memtable) e file di tabelle di stringhe ordinate (SSTable).

A differenza di Cassandra, MongoDB utilizza un modello primario/secondario per la sua architettura distribuita. In MongoDB, un set di repliche (un gruppo di istanze) è costituito da un nodo primario che gestisce tutte le operazioni di scrittura (aggiunta o modifica dei dati) e da nodi secondari che riflettono i dati nel nodo primario.

I set di dati di grandi dimensioni in MongoDB possono anche essere distribuiti su più macchine attraverso un processo noto come sharding. Le informazioni sono suddivise in cluster frammentati (vari set di repliche e un router che trasmette le query dalle applicazioni ai set di repliche), per migliorare la capacità del sistema di gestire le richieste di dati.

I database utilizzano anche metodi di indicizzazione diversi. In Apache Cassandra, l'indice primario è la chiave di partizione, sebbene la documentazione di Cassandra citi l'indicizzazione storage-attached (che dispone di indici per colonne senza partizione) come appropriata per la maggior parte dei casi d'uso. ⁴ Cassandra dispone anche di indici secondari, ovvero di indici locali memorizzati in tabelle separate dai valori indicizzati. MongoDB supporta diversi tipi di indici per diversi casi d'uso, inclusi indici geospaziali, indici multichiave e indici di testo.

Per definizione, i database NoSQL non utilizzano Structured Query Language (SQL), ovvero il linguaggio di programmazione standardizzato per i database relazionali. Tuttavia, sia Apache Cassandra che MongoDB hanno i propri linguaggi di query.

Cassandra utilizza una versione personalizzata di SQL chiamata Cassandra Query Language (CQL). Sebbene CQL somigli in larga misura a SQL, ci sono differenze fondamentali tra i due. Ad esempio, SQL opera su tabelle normalizzate, mentre CQL è progettato per i dati Cassandra denormalizzati, allineati con le chiavi di partizione. Inoltre, SQL è ottimizzato per le transazioni, mentre CQL è progettato per le query in tempo reale e per le operazioni di scrittura con volumi elevati.

MongoDB utilizza MongoDB Query Language (MQL). Progettato per interrogare i modelli di documenti, MQL condivide la stessa sintassi dei documenti, indicando un maggiore allontanamento da SQL rispetto al Cassandra Query Language. MQL dovrebbe supportare una gamma di query e funzionalità di manipolazione dei dati, tra cui query complesse, pipeline di aggregazione e query di dati geospaziali ⁵

Oltre ai rispettivi linguaggi di query, i database differiscono per il supporto alla programmazione. MongoDB fornisce driver ufficiali per oltre una dozzina di linguaggi di programmazione, come Java, Python, Ruby e Node.js. Questi e altri linguaggi sono compatibili anche con Cassandra, tuttavia i driver sono in gran parte offerti da terze parti.

Le differenze fondamentali tra Apache Cassandra e MongoDB introducono alcune variazioni nelle caratteristiche associate alle loro prestazioni. Queste variazioni possono anche essere spiegate dal teorema CAP.

CAP è un'abbreviazione che rappresenta tre caratteristiche desiderate dei sistemi distribuiti: coerenza (tutti i client vedono gli stessi dati nello stesso momento), disponibilità (qualsiasi client che effettua una richiesta di dati riceve una risposta, anche se uno o più nodi sono inattivi) e tolleranza alla partizione (un cluster di nodi continua a funzionare anche in caso di interruzione delle comunicazioni tra due o più nodi).

Il teorema CAP impone che un sistema distribuito possa fornire solo due delle tre caratteristiche desiderate. Apache Cassandra è generalmente classificato come database "AP", in quanto offre elevate prestazioni principalmente in termini di disponibilità e tolleranza delle partizioni.

MongoDB è invece conosciuto come un database "CP", che eccelle a livello di tolleranza alle partizioni e coerenza. Tuttavia, per entrambi i database esistono anche delle misure per migliorare le prestazioni su caratteristiche apparentemente compromesse, ossia la coerenza per Cassandra e la disponibilità per MongoDB.

Diamo un'occhiata più da vicino alle tre caratteristiche desiderate.

Cassandra supporta l'alta disponibilità perché, in quanto sistema decentralizzato con dati replicati su più nodi, presenta caratteristiche di alta tolleranza agli errori e nessun singolo punto di errore. Se un nodo ha un tempo di inattività, altri nodi con copie degli stessi dati possono soddisfare una richiesta di dati. Inoltre, la replica dei dati nei data center di tutto il mondo consente una bassa latenza per gli utenti locali.

Poiché l'architettura di MongoDB è basata su un modello primario/secondario, può verificarsi un singolo punto di errore quando un nodo primario non funziona. Tuttavia, il failover di MongoDB è considerato robusto: durante le cosiddette elezioni dei set di repliche, i nodi appartenenti a un set di repliche selezionano un nuovo nodo primario per sostituire il nodo primario non disponibile. Questo processo consente a MongoDB di offrire anche un'elevata disponibilità, sebbene con un breve ritardo: le prestazioni riprendono solo dopo la scelta del nuovo nodo primario.

MongoDB offre intrinsecamente un'elevata coerenza, perché tutti i client scrivono su una singola fonte affidabile: ogni set di repliche può avere un solo nodo che riceve tutte le operazioni di scrittura. Al contrario, Apache Cassandra fornisce la eventual consistency: i client possono scrivere su qualsiasi nodo in qualsiasi momento e quindi le incongruenze vengono riconciliate il più rapidamente possibile.

Cassandra consente inoltre agli utenti di ottimizzare la coerenza (riducendo al contempo la priorità della disponibilità) attraverso la cosiddetta coerenza regolabile. Gli utenti possono selezionare un livello di coerenza che stabilisce quante repliche devono riconoscere una lettura o una scrittura prima di confermarla all'applicazione client. Livelli di coerenza più elevati richiedono che più repliche rispondano con i riconoscimenti, ma ciò aumenta anche la latenza e riduce la disponibilità.

Sia Apache Cassandra che MongoDB offrono la tolleranza alla partizione, perché ciascuno è progettato per continuare a funzionare anche quando si verifica un'interruzione delle comunicazioni in una parte del sistema.

In Apache Cassandra, i nodi rimangono disponibili in caso di problemi di comunicazione, tuttavia alcuni nodi potrebbero non fornire le versioni più aggiornate dei dati (in risposta alle richieste di dati) finché la partizione non viene risolta. In MongoDB, la disponibilità è limitata per garantire la coerenza dei dati durante l'indirizzamento della partizione.

Apache Cassandra è spesso consigliato per workload ad alto rendimento, distribuiti a livello globale e ad alto volume di scrittura, in cui la disponibilità e la scalabilità sono critiche, come lo streaming e l'intrattenimento. Ad esempio, i servizi di streaming come Netflix utilizzano Cassandra per gestire l'attività globale degli utenti.

MongoDB è ideale per i casi d'uso basati sui documenti e con schemi flessibili che traggono beneficio dall'agilità degli sviluppatori e dalla forte coerenza. Le aziende spesso si affidano a MongoDB per supportare i propri sistemi di gestione dei contenuti, perché MongoDB memorizza e serve una varietà di contenuti.

Nonostante le differenze tra i due database, i casi d'uso per Apache Cassandra e i casi d'uso per MongoDB possono sovrapporsi. I case study di ciascun database dimostrano la loro efficacia per le applicazioni Internet of Things (IoT), e-commerce e molto altro.