MongoDB vs. Cassandra

Sto valutando quale potrebbe essere la migliore opzione di migrazione.

Attualmente, sono su MySQL (partizione orizzontale), con la maggior parte dei miei dati memorizzati in BLOB JSON. Non ho query SQL complesse (già migrate dopo aver partizionato il mio db).

In questo momento, sembra che sia MongoDB che Cassandra sarebbero probabilmente delle opzioni. La mia situazione:

  • Un sacco di letture in ogni query, scritture meno regolari
  • Non preoccupato per la “massiccia” scalabilità
  • Più preoccupati per la configurazione, la manutenzione e il codice semplici
  • Riduci al minimo il costo dell’hardware / server

Un sacco di letture in ogni query, meno scritture regolari

Entrambi i database funzionano bene su letture in cui il set di dati caldo si adatta alla memoria. Entrambi enfatizzano anche i modelli di dati senza join (e incoraggiano invece la denormalizzazione) e forniscono entrambi indici su documenti o righe , sebbene gli indici di MongoDB siano attualmente più flessibili.

Il motore di archiviazione di Cassandra fornisce scritture a tempo costante indipendentemente dalla dimensione del set di dati. Le scritture sono più problematiche in MongoDB, in parte a causa del motore di archiviazione basato su b-tree, ma più a causa del blocco di scrittura per database .

Per l’analisi, MongoDB fornisce una mappa personalizzata / riduce l’implementazione; Cassandra fornisce supporto Hadoop nativo, incluso Hive (un data warehouse SQL basato su Hadoop map / reduce) e Pig (un linguaggio di analisi specifico per Hadoop che molti ritengono sia più adatto per mappare / ridurre i carichi di lavoro di SQL).

Non preoccupato per la “massiccia” scalabilità

Se stai guardando un singolo server, MongoDB è probabilmente una soluzione migliore. Per coloro che sono più preoccupati del ridimensionamento, l’architettura di non-punto di errore di Cassandra sarà più semplice da configurare e più affidabile. (Anche il blocco di scrittura globale di MongoDB tende a diventare più doloroso.) Cassandra offre anche un maggiore controllo sul funzionamento della replica, incluso il supporto per più data center.

Più preoccupati per la configurazione, la manutenzione e il codice semplici

Entrambi sono semplici da configurare, con impostazioni predefinite predefinite per un singolo server. Cassandra è più semplice da configurare in una configurazione multi-server poiché non ci sono nodes di ruolo speciali di cui preoccuparsi; ecco uno screencast che dimostra la creazione di un cluster Cassandra a 4 nodes in due minuti .

Se attualmente utilizzi BLOB JSON, MongoDB è una corrispondenza follemente buona per il tuo caso d’uso, dato che utilizza BSON per archiviare i dati. Sarai in grado di avere dati più ricchi e più ricercabili di quelli che faresti nel tuo attuale database. Questa sarebbe la vittoria più significativa per Mongo.

Ho usato MongoDB estensivamente (negli ultimi 6 mesi), costruendo un sistema gerarchico di gestione dei dati, e posso garantire sia la facilità di installazione (installarlo, eseguirlo, usarlo!) E la velocità. Finché pensi attentamente agli indici, puoi assolutamente urlare, in termini di velocità.

Considero che Cassandra, grazie al suo utilizzo con progetti su larga scala come Twitter, ha una migliore funzionalità di ridimensionamento, sebbene il team di MongoDB stia lavorando sulla parità. Vorrei sottolineare che non ho usato Cassandra oltre la fase di prova, quindi non posso parlare per i dettagli.

Il vero swinger per me, quando stavamo valutando i database NoSQL, era l’interrogazione – Cassandra è fondamentalmente solo un gigantesco archivio di chiavi / valori, e l’interrogazione è un po ‘approssimativa (almeno rispetto a MongoDB), quindi per le prestazioni dovresti duplicare un bel po ‘di dati come una sorta di indice manuale. MongoDB, d’altra parte, utilizza un modello “query per esempio”.

Ad esempio, supponiamo di avere una raccolta (parlance MongoDB per l’equivalente di una tabella RDMS) contenente utenti. MongoDB memorizza i record come documenti, che sono fondamentalmente oggetti JSON binari. per esempio:

{ FirstName: "John", LastName: "Smith", Email: "john@smith.com", Groups: ["Admin", "User", "SuperUser"] } 

Se si desidera trovare tutti gli utenti chiamati Smith che dispongono dei diritti di amministratore, è sufficiente creare un nuovo documento (nella console di amministrazione utilizzando Javascript o in produzione utilizzando la lingua desiderata):

 { LastName: "Smith", Groups: "Admin" } 

… e poi esegui la query. Questo è tutto. Ci sono operatori aggiunti per confronti, filtri RegEx ecc., Ma è tutto piuttosto semplice, e la documentazione basata su Wiki è piuttosto buona.

Perché scegliere tra un database tradizionale e un archivio dati NoSQL? Usali entrambi! Il problema con le soluzioni NoSQL (oltre la curva di apprendimento iniziale) è la mancanza di transazioni: si eseguono tutti gli aggiornamenti su MySQL e MySQL popola un data store NoSQL per le letture, quindi si beneficiano dei punti di forza di ciascuna tecnologia. Questo aggiunge più complessità, ma hai già il lato MySQL – aggiungi semplicemente MongoDB, Cassandra, ecc. Al mix.

I datastore NoSQL generalmente scalano meglio di un DB tradizionale per le stesse specifiche altrimenti – c’è un motivo per cui Facebook, Twitter, Google e la maggior parte delle start-up utilizzano soluzioni NoSQL. Non sono solo i fan sfegatati che si innamorano della nuova tecnologia.

Probabilmente sarò un tipo strano, ma penso che tu debba stare con MySQL. Non hai descritto un problema reale che devi risolvere e MySQL / InnoDB è un eccellente back-end di archiviazione anche per i dati blob / json.

C’è un trucco comune tra gli ingegneri Web per provare a usare più NoSQL non appena viene la consapevolezza che non tutte le funzionalità di un RDBMS sono utilizzate. Questo da solo non è una buona ragione, dal momento che la maggior parte dei database NoSQL ha motori di dati piuttosto scadenti (ciò che MySQL chiama un motore di archiviazione).

Ora, se non sei di quel tipo, allora ti preghiamo di specificare cosa manca in MySQL e stai cercando in un database diverso (come, auto-sharding, failover automatico, replica multi-master, una garanzia di coerenza dei dati più debole in il cluster si ripaga nel throughput di scrittura più elevato, ecc.).

Non ho usato Cassandra, ma ho usato MongoDB e penso sia fantastico.

Se dopo la tua semplice installazione, è questo. Basta decomprimere MongoDB ed eseguire il demone mongod e il gioco è fatto.

Ovviamente questo è solo un antipasto, ma per iniziare è facile.

Ieri ho visto una presentazione su mongodb. Posso sicuramente dire che la configurazione era “semplice”, semplice come spacchettarla e accenderla. Fatto.

Credo che sia mongodb che cassandra funzioneranno praticamente su qualsiasi normale hardware Linux, quindi non dovresti trovare molta barriera in quella zona.

Penso che in questo caso, alla fine della giornata, arriverà a quale ti senti più a tuo agio e che ha un set di strumenti che preferisci. Per quanto riguarda la presentazione su mongodb, il presentatore ha indicato che il set di strumenti per mongodb era piuttosto leggero e che non c’erano molti (hanno detto davvero nessuno) strumenti simili a quelli disponibili per MySQL. Questa è stata ovviamente la loro esperienza così YMMV. Una cosa che mi è piaciuta di mongodb è che sembrava esserci un sacco di supporto per la lingua (Python e .NET sono i due che uso principalmente).

L’elenco dei siti che usano mongodb è piuttosto impressionante , e so che Twitter è appena passato a usare cassandra.