Se le colonne dinamiche sono scoraggiate in cassandra 1.2/Cql3, allora come è meglio di Mysql in funzionalità?

Question

Inizialmente ho iniziato a studiare Cassandra perché le colonne dinamiche catturavano la mia attenzione. Quando ho iniziato a imparare di più, ho imparato che le chiavi primarie composite sono preferite alle colonne dinamiche e Cassandra si sta spostando su uno schema basato (lo schema è facoltativo e non obbligatorio ma raccomandato). In cql3, è obbligatorio e leggo cql3 è l'approccio migliore per le nuove applicazioni in cassandra.

Ecco dove mi trovo di fronte a una domanda interessante. Stavo leggendo una diapositiva particolare (Mysql vs Casssandra) - http://lanyrd.com/2012/austin-mysql-meetup-january/spdrx/ (Vai a 31 slide) dove si parla del caso d'uso di rilevamento frodi.

"In FraudDetection per calcolare il rischio, è comune ad avere bisogno di conoscere tutti i messaggi di posta elettronica, le destinazioni, le origini, i dispositivi, località, phonenumbers, eccetera mai utilizzati per l'account in questione."

E 'stato spiegato come dobbiamo mantenere una tabella individuale per e-mail, destinazioni, origini, ecc. in un mondo relazionale e quanto sia facile essere nel mondo di cassandra con chiavi e valori di colonna dinamici. (31-34 diapositive).

Ora che le chiavi e i valori delle colonne dinamiche sono scoraggiati, come possiamo risolvere questo problema? Dovremmo mantenere singole famiglie di colonne per ogni e-mail, destinazione ecc.? Allora, come è diverso dal mondo relazionale? Si tratta solo di scalabilità? Possiamo ancora andare avanti con l'approccio schema less? È questa la regola d'oro "Lo schema è opzionale e raccomandato ma non obbligatorio?"

Grazie

Answer 1

Ci scusiamo per la confusione qui. Come si è scoperto, non ho capito bene i concetti di base. Ecco la risposta

Le colonne dinamiche sono il cuore di Cassandra. Sono ancora supportati ed è ancora il core :) E 'solo che in parsimonia si fa direttamente e in CQL si fa in modo diverso (attraverso il modo schema). Ma ancora lo si fa :) - Leggi questo - http://www.datastax.com/dev/blog/thrift-to-cql3

E per quanto riguarda come Cassandra è meglio di Mysql - Da leggere http://lanyrd.com/2012/austin-mysql-meetup-january/spdrx/ (16-24 slides)

Grazie :) colonne

Answer 2

È comunque possibile utilizzare un approccio schema-di meno se si utilizza l'API Thrift invece di CQL. Come utente Cassandra di lunga data, trovo anche discutibile la spinta verso la definizione anticipata dello schema. Ma fortunatamente il meccanismo di archiviazione sottostante è lo stesso e tutti i client che sono a conoscenza del supporto che utilizzano le chiamate basate su Thrift.

Answer 3

Invece dinamici, ci stanno supportando materiale di raccolta come set, elenchi, mappe. Non è abbastanza per la dinamicità