Passaggio da MySQL a Cassandra - Pro/Contro?

Question

Per un po 'di background - questa domanda riguarda un progetto eseguito su una singola piccola istanza EC2 e sta per migrare a una media. I componenti principali sono Django, MySQL e un gran numero di strumenti di analisi personalizzati scritti in python e java, che fanno il pesante sollevamento . Lo stesso computer sta eseguendo anche Apache.

Il modello di dati è simile al seguente - una grande quantità di dati in tempo reale è disponibile in streaming da vari sensori collegati in rete, e, idealmente, mi piacerebbe stabilire un approccio a lungo sondaggio, piuttosto che il sondaggio in corso ogni approccio 15 minuti (una limitazione delle statistiche di calcolo e scrittura nel database stesso). Una volta che i dati arrivano, memorizzo la versione grezza in MySQL, lascio perdere gli strumenti di analisi su questi dati e memorizzo le statistiche in altre tabelle. Tutto questo è reso utilizzando Django.

caratteristiche relazionali avrei bisogno -

• Ordina per [SliceRange nella API di Cassandra sembra satisy questo]
• Gruppo per
• rapporti ManyToMany tra più tabelle [Cassandra SuperColumns sembrano fare bene per uno a molti]
• La sfinge su questo mi dà un bel motore di testo completo, quindi è anche una necessità. [On Cassandra, il progetto Lucandra sembra soddisfare questa esigenza]

Il mio problema principale è che i dati si legge sono estremamente lento (e le scritture non sono così caldo o). Non voglio buttare un sacco di soldi e hardware in questo momento, e preferirei qualcosa che possa scalare facilmente con il tempo. Scalare verticalmente MySQL non è banale in questo senso (o economico).

Quindi, in sostanza, dopo aver letto molto su NoSQL e sperimentato con le cose come MongoDB, Cassandra e Voldemort, le mie domande sono,

• In un'istanza EC2 media, dovrei ottenere alcun beneficio in legge/scrive passando a qualcosa come Cassandra? This article (pdf) sembra decisamente suggerirlo. Attualmente, direi che alcune centinaia di scritture al minuto sarebbero la norma. Per le letture, poiché i dati cambiano ogni 5 minuti circa, l'invalidazione della cache deve avvenire abbastanza rapidamente. A un certo punto, dovrebbe essere in grado di gestire anche un numero elevato di utenti simultanei. La performance dell'app viene attualmente uccisa su MySQL facendo alcuni join su tabelle di grandi dimensioni, anche se vengono creati degli indici - qualcosa per l'ordine di 32k righe richiede più di un minuto per il rendering. (Potrebbe trattarsi anche di un artefatto di I/O virtualizzati EC2). La dimensione delle tabelle è di circa 4-5 milioni di righe e ci sono circa 5 di queste tabelle.

• Tutti parlano dell'utilizzo di Cassandra su più nodi, dato il teorema CAP e la consistenza finale. Ma, per un progetto che sta appena iniziando a crescere, ha senso distribuire un server cassandra a un nodo? Ci sono dei avvertimenti? Ad esempio, può sostituire MySQL come backend per Django? [È raccomandato?]

• Se faccio shift, sto indovinando che dovrò riscrivere parti dell'app per fare molto più "administrivia" dato che dovrei fare più ricerche per recuperare le righe .

• sarebbe alcun senso utilizzare solo MySQL come un negozio di valore chiave piuttosto che un motore relazionale, e andare con quella? In questo modo potrei utilizzare un gran numero di API stabili disponibili, oltre a un motore stabile (e diventare relazionale se necessario). (Post di Brett Taylor da Friendfeed su questo - http://bret.appspot.com/entry/how-friendfeed-uses-mysql)

eventuali approfondimenti da parte di persone che hanno fatto un cambiamento sarebbe molto apprezzato!

Grazie.

Answer 1

Cassandra e gli altri database distribuiti disponibili oggi non forniscono il tipo di supporto di query ad hoc a cui sei abituato da sql. Questo perché non è possibile distribuire query con join in modo performante, quindi l'enfasi è sulla denormalizzazione.

Tuttavia, Cassandra 0.6 (beta ufficialmente in uscita domani, ma puoi costruire dal ramo 0.6 te stesso se sei impaziente) supporta la mappa Hadoop/riduci per l'analisi, che in realtà suona come una buona soluzione per te.

Cassandra fornisce un eccellente supporto per aggiungere nuovi nodi in modo indolore, anche a un gruppo iniziale di uno.

Detto questo, a poche centinaia di scritture/minuto starai bene su mysql per molto, molto tempo. Cassandra è molto più bravo a essere un archivio di chiavi/valori (ancora meglio, chiave/famiglia di colonne), ma MySQL è molto più bravo nell'essere un database relazionale. :)

Non esiste ancora il supporto per django per Cassandra (o altro database nosql). Stanno parlando di fare qualcosa per la prossima versione dopo la 1.2, ma basandosi sul parlare con gli sviluppatori di Django su Pycon, nessuno è veramente sicuro di come sarà.

Answer 2

Se sei uno sviluppatore di database relazionale (come me), io suggerirei/precisare:

• ottenere una certa esperienza di lavoro con Cassandra prima di impegnarsi per il suo utilizzo in un sistema di produzione .. specialmente se quel sistema di produzione ha una dura scadenza per il completamento. Forse usarlo come back-end per qualcosa di poco importante prima.
• Si sta dimostrando più difficile di quanto mi aspettassi di fare cose semplici che diamo per scontato sulla manipolazione dei dati utilizzando motori SQL. In particolare, i dati di indicizzazione e le serie di risultati di ordinamento non sono banali.
• Anche la modellazione dei dati si è dimostrata difficile. Come sviluppatore di database relazionale, vieni al tavolo con un sacco di bagagli ... devi essere disposto a imparare come modellare i dati in modo molto diverso.

Queste cose dicono, consiglio vivamente di costruire qualcosa in a Cassandra. Se sei come me, fare ciò metterà alla prova la tua comprensione dell'archiviazione dei dati e ti indurrà a riconsiderare una prospettiva relazionale-database-adatta a tutte le situazioni che non avevo nemmeno realizzato.

Alcune buone risorse che ho trovato sono:

• Dominic Williams' Cassandra blog posts
• Secondary Indexes in Cassandra
• More from Ed Anuff on indexing
• Cassandra book (not fantastic, but a good start)
• "WTF is a SuperColumn" pdf

Answer 3

Il Django-cassandra è una modalità beta precoce. Inoltre Django non ha realizzato database no-sql. La chiave di Django ORM è basata su SQL (Django consiglia di utilizzare PostgreSQL). Se è necessario utilizzare SOLO no-sql (è possibile combinare sql e no-sql nella stessa app) è necessario utilizzare rischiosamente l'ORM no-sql (molto più lento del tradizionale SQL orm o l'uso diretto della memoria No-SQL). O avrai bisogno di riscrivere completamente il django ORM. Ma in questo caso non posso presumere, perché hai bisogno di Django. Forse puoi usare qualcos'altro, come Tornado?