Il passaggio da MySQL a Cassandra - pro / contro?

StackOverflow https://stackoverflow.com/questions/2332113

Domanda

Per un po 'di background - questa domanda riguarda un progetto in esecuzione su un singolo piccolo istanza EC2, e sta per migrare verso un mezzo uno. I componenti principali sono Django, MySQL e un gran numero di strumenti di analisi personalizzati scritto in Python e Java, che fare il pesante sollevamento. La stessa macchina è in esecuzione Apache pure.

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 di calcolare le statistiche e la scrittura nel database stesso). Una volta che i dati provengono in, devo conservare la versione grezza in MySQL, lasciare che gli strumenti di analisi sciolto su questi dati, e le statistiche di negozi in un altro paio di tavoli. Tutto questo è reso con Django.

caratteristiche relazionali avrei bisogno -

  • Ordina per [SliceRange in API di Cassandra sembra satisy questo]
  • Raggruppa per
  • Relazioni ManyToMany tra più tabelle [Cassandra SuperColumns sembrano fare bene per uno a molti]
  • Sphinx su questo mi dà un bel motore di testo completo, in modo da questo è una necessità troppo. [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 l'hardware su di esso in questo momento, ed io preferirei qualcosa in grado di scalare facilmente con il tempo. Verticalmente scalando 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 medio, dovrei ottenere alcun beneficio in lettura / scrittura passando a qualcosa come Cassandra ? Questo articolo (pdf) sembra decisamente suggerire che. Attualmente, direi che a poche centinaia di operazioni di scrittura al minuto sarebbe la norma. Per legge - in quanto i dati cambia ogni 5 minuti o giù di lì, invalidazione della cache deve accadere abbastanza rapidamente. Ad un certo punto, dovrebbe essere in grado di gestire un elevato numero di utenti simultanei pure. Le prestazioni applicazione attualmente viene ucciso su MySQL fare un po 'si unisce a tabelle di grandi dimensioni, anche se vengono creati gli indici - qualcosa per l'ordine di 32K file richiede più di un minuto per il rendering. (Questo può essere un artefatto di EC2 I virtualizzato / O pure). Dimensioni di tabelle è circa 4-5 milioni di righe, e ci sono circa 5 tali tabelle.

  • Tutti ne parlano usando Cassandra su più nodi, dato il teorema della PAC e la consistenza finale. Ma, per un progetto che sta appena iniziando a crescere, ha senso per distribuire un server cassandra un nodo ? Ci sono avvertimenti? Per esempio, può sostituire il MySQL come backend per Django? [È questo raccomandato?]

  • Se io sposto, sto cercando di indovinare dovrò riscrivere parti del app per fare molto di più "administrivia", in quanto avrei dovuto fare più ricerche per recuperare le righe.

  • Avrebbe alcun senso utilizzare solo MySQL come un archivio chiavi valore , piuttosto che un motore relazionale, e andare con quello? In questo modo ho potuto utilizzare un gran numero di API stabili disponibili, così come un motore stabile (e andare relazionale, se necessario). (Post di Brett Taylor da Friendfeed su questo - http://bret.appspot.com/ ingresso / how-FriendFeed utilizzi-mysql )

Tutte le comprensioni da parte di persone che hanno fatto un cambiamento sarebbe molto apprezzato!

Grazie.

È stato utile?

Soluzione

Cassandra e gli altri database distribuiti oggi disponibili non forniscono il tipo di supporto di query ad-hoc a cui siete abituati da SQL. Questo perché non è possibile distribuire le query con join performantly, quindi l'enfasi è sulla denormalizzazione invece.

Tuttavia, Cassandra 0.6 (beta ufficialmente domani, ma è possibile costruire dal ramo 0.6 da soli se siete impazienti) supporta Hadoop Map / Reduce per l'analisi, che in realtà suona come una buona misura per voi.

Cassandra fornisce un eccellente supporto per l'aggiunta di nuovi nodi senza dolore, anche ad un gruppo iniziale di uno.

Detto questo, a poche centinaia scrive / minuto si sta andando ad essere bene su MySQL per un lungo, lungo tempo. Cassandra è molto meglio di essere un negozio chiave / valore (meglio ancora, chiave / columnfamily), ma MySQL è molto meglio a essere un database relazionale. :)

Non v'è alcun supporto Django per Cassandra (o di altri database NoSQL) ancora. Stanno parlando di fare qualcosa per la prossima versione 1.2 dopo, ma sulla base di parlare con Django sviluppatori a PyCon, nessuno è davvero sicuro di quello che sarà simile ancora.

Altri suggerimenti

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

  • Ottenere qualche esperienza di lavoro con Cassandra prima di impegnarsi per il suo utilizzo in un sistema di produzione ... soprattutto se tale sistema di produzione ha una scadenza difficile per il completamento. Forse usarlo come backend per qualcosa di poco importante prima.
  • Si sta dimostrando più difficile di quanto mi aspettassi a fare le cose semplici che prendo per scontato circa la manipolazione dei dati utilizzando i motori di SQL. In particolare, i dati di indicizzazione e ordinamento set di risultati non è banale.
  • La modellazione dei dati si è dimostrato impegnativo pure. Come sviluppatore di database relazionale si arriva al tavolo con un sacco di bagagli ... è necessario essere disposti ad imparare come modellare i dati in modo molto diverso.

Queste cose disse, vi raccomando vivamente edificio qualcosa in Cassandra. Se siete come me, allora così facendo sarà una sfida per la vostra comprensione della memorizzazione dei dati e farà ripensare una prospettiva relazionale-Database-fits-all-situazioni che non ho nemmeno capito ho tenuto.

Alcune buone risorse che ho trovato sono:

Il Django-cassandra è una modalità beta. Inoltre Django non ha fatto per i database non-SQL. La chiave di Django ORM è basata su SQL (Django raccomanda di usare PostgreSQL). Se è necessario utilizzare SOLO no-SQL (potete mescolare sql e non-SQL in stessa applicazione) è necessario l'uso rischioso no-sql ORM (è notevolmente più lento di ORM SQL tradizionale o uso diretto di stoccaggio No-SQL). Oppure è necessario riscrivere completamente pieno Django ORM. Ma in questo caso non posso presumere, perché avete bisogno di Django. Forse è possibile utilizzare qualcos'altro, come Tornado?

Autorizzato sotto: CC-BY-SA insieme a attribuzione
Non affiliato a StackOverflow
scroll top