MongoDB vs. Cassandra [chiuso]

Sto valutando quale potrebbe essere la migliore opzione di migrazione.

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

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

• Molte letture in ogni query, scritture meno regolari
• Non preoccupato per la scalabilità "massiccia"
• Più preoccupato per la semplice configurazione, manutenzione e codice
• Ridurre al minimo i costi di hardware / server

Molte letture in ogni query, meno scritture regolari

Entrambi i database eseguono bene le letture in cui il set di dati attivi si adatta alla memoria. Entrambi enfatizzano anche i modelli di dati senza join (e incoraggiano invece la denormalizzazione) ed entrambi forniscono 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 multi-granularità che fa.

Per l'analisi, MongoDB fornisce una mappa personalizzata / riduce l'implementazione; Cassandra fornisce supporto nativo di Hadoop, incluso Hive (un data warehouse SQL basato sulla mappa / riduzione di Hadoop) e Pig (un linguaggio di analisi specifico di Hadoop che molti ritengono più adatto a mappare / ridurre i carichi di lavoro rispetto a SQL). Cassandra supporta anche l'uso di Spark .

Non preoccupato per la scalabilità "massiccia"

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

Più preoccupato per la semplice configurazione, manutenzione e codice

Entrambi sono banali da configurare, con impostazioni predefinite ragionevoli per un singolo server. Cassandra è più semplice da installare in una configurazione multi-server poiché non ci sono nodi con ruoli speciali di cui preoccuparsi.

Se attualmente stai utilizzando BLOB JSON, MongoDB è una corrispondenza follemente valida per il tuo caso d'uso, dato che utilizza BSON per archiviare i dati. Sarai in grado di avere dati più ricchi e più interrogabili di quelli che vorresti nel tuo database attuale. Questa sarebbe la vittoria più significativa per Mongo.

Ho usato MongoDB ampiamente (negli ultimi 6 mesi), costruendo un sistema gerarchico di gestione dei dati e posso garantire sia la facilità di installazione (installarlo, eseguirlo, usarlo!) Che la velocità. Fintanto che pensi attentamente agli indici, può assolutamente urlare, in termini di velocità.

Ho notato che Cassandra, grazie al suo utilizzo con progetti su larga scala come Twitter, ha una migliore funzionalità di ridimensionamento, sebbene il team MongoDB stia lavorando sulla parità lì. Dovrei 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 la query: Cassandra è fondamentalmente solo un gigantesco archivio di chiavi / valori e le query sono un po 'complicate (almeno rispetto a MongoDB), quindi per le prestazioni dovresti duplicare molti dati come una sorta di indice manuale. MongoDB, d'altra parte, usa un modello di "query per esempio".

Ad esempio, supponiamo di avere una raccolta (linguaggio 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 desideri trovare tutti gli utenti chiamati Smith con diritti di amministratore, devi semplicemente creare un nuovo documento (nella console di amministrazione utilizzando Javascript o in produzione utilizzando la lingua che preferisci):

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

... e quindi esegui la query. Questo è tutto. Ci sono operatori aggiunti per confronti, filtri RegEx ecc., Ma è tutto abbastanza 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 - esegui tutti gli aggiornamenti a MySQL e fai in modo che MySQL popoli un archivio dati NoSQL per le letture - beneficerai quindi dei punti di forza di ogni tecnologia. Ciò aggiunge maggiore complessità, ma hai già il lato MySQL: aggiungi MongoDB, Cassandra, ecc. Al mix.

I datastore NoSQL generalmente scalano molto 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 geek a farsi strada sulle nuove tecnologie.

Probabilmente sarò uno strano uomo, ma penso che devi stare con MySQL. Non hai descritto un vero problema che devi risolvere e MySQL / InnoDB è un eccellente back-end di archiviazione anche per i dati BLOB / JSON.

Esiste un trucco comune tra gli ingegneri Web per provare a utilizzare più NoSQL non appena viene realizzato che non vengono utilizzate tutte le funzionalità di un RDBMS. Questo da solo non è un buon motivo, poiché il più delle volte i database NoSQL hanno motori di dati piuttosto scadenti (ciò che MySQL chiama un motore di archiviazione).

Ora, se non sei di quel tipo, specifica 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 cluster che paga con un throughput di scrittura più elevato, ecc.).

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

Se stai cercando una semplice configurazione, eccola qui: basta estrarre MongoDB ed eseguire il demone mongod e il gioco è fatto ... è in esecuzione.

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

Ieri ho visto una presentazione su mongodb. Posso sicuramente dire che l'installazione era "semplice", semplice come decomprimerlo e accenderlo. Fatto.

Credo che sia mongodb che cassandra funzioneranno praticamente su qualsiasi normale hardware linux, quindi non dovresti trovare troppe barriere in quell'area.

Penso che in questo caso, alla fine, scenderà a quale persona ti senti più a tuo agio e con quale set di strumenti 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 strumenti (dicevano davvero) simili a quelli disponibili per MySQL. Questa è stata ovviamente la loro esperienza così YMMV. Una cosa che mi è piaciuta di mongodb è che sembrava esserci molto supporto linguistico (Python e .NET sono i due che utilizzo principalmente).

L'elenco dei siti che utilizzano mongodb è piuttosto impressionante e so che Twitter è appena passato all'utilizzo di cassandra.