Devo utilizzare un datamodel relazionale o Cassandra con indici basati su ColumnFamily?

Puoi rimanere relazionale e essere noSQL allo stesso tempo se puoi partizionare i dati (forse per tempo) con playOrm / cassandra in modo da poter fare "scalabile JQL" in questo modo

@NoSqlQuery (name="findJoinOnNullPartition", query="PARTITION t (: partId) seleziona t FROM TABLE as t INNER JOIN t.security as s where s.securityType =: type e t.numShares =: shares")

Supporta, naturalmente, anche ManyToOne, OneToMany, ecc. ecc., ma funzionano in modo leggermente diverso rispetto all'ibernazione, dato che questo non è affatto SQL.

Hadoop gioca bene con i negozi NoSQL come Cassandra. Sto facendo lo sviluppo su un progetto collaterale che usa Cassandra e Hadoop. È stato un po 'difficile da configurare, poiché ci sono alcuni barattoli in più necessari nell'installazione di Hadoop per supportare Cassandra e non molta documentazione su come farlo. L'API di Thrift è un po 'scomoda ma gestibile ancora una volta che stai scrivendo il codice di riduzione della mappa.

Penso che la decisione dipenda dalle domande che devi eseguire e dal volume di dati elaborati che stai cercando di archiviare. Le query complesse su piccoli volumi di dati spingono maggiormente verso MySQL. Query semplici o volumi più grandi di dati spingono più verso Cassandra o HBase.

Se tutto quello che stai per fare è cercare i record una volta archiviati, quindi non credo che ci sarà molta differenza. Se è necessario rielaborarli (o una grande parte di essi) si potrebbe vedere qualche vantaggio dall'approccio NoSQL. Se sai quali campi stai cercando, ti consiglio di comprimere i dati in un BLOB e di archiviarli insieme ai campi ricercabili in una tabella relazionale, al fine di ridurre i requisiti di archiviazione (I don ' so se è possibile con Cassandra).

Se solo sta per memorizzare i registri, sei passato in una delle poche posizioni in cui i database relazionali non hanno molto senso.

SQL non sarà sicuramente il mezzo ideale per eseguire il tuo lavoro- nessun join, non molte tabelle diverse, ecc. Transazioni e UPDATE s probabilmente non saranno necessarie.

Sceglierei qualcosa che mi consenta di eseguire facilmente i lavori di ridimensionamento della mappa: potrebbe essere il caso che un algoritmo a thread singolo sia tutto ciò di cui hai bisogno, ma se diventa troppo lento per i tuoi scopi, essere in grado di lanciare i core al problema sarà utile.

Se stai cercando molto (cioè esegui calcoli su piccoli sottoinsiemi di dati), l'indicizzazione sarà un altro fattore determinante: avere un negozio che supporti l'indicizzazione che gestisce bene le tue ricerche farà risparmiare un sacco di tempo.

D'altro canto, a seconda di ciò che si fa, potrebbe avere senso "riepilogare" i registri utilizzando un archivio dati non relazionale, ma inserire i dati massaggiati in un RDBMS. Se ci sono dati strutturati / relazionali nascosti nei tuoi registri, la capacità di eseguire query ad-hoc usando SQL è inestimabile: aggregati, funzioni della finestra, ecc. Possono essere eseguiti in modo abbastanza rapido in un RDBMS decente, forse anche più efficientemente che con la mappa -reduce e algoritmi altamente paralleli; sicuramente, se conosci il tuo SQL, l'implementazione è di solito molto più veloce.

Ad esempio, supponi che i log che ti interessano siano tutti simili:

[timestamp] add student xxxxx
[timestamp] create class yyyy at [date-time] with professor zzzz
[timestamp] student xxxx books class yyyy
[timestamp] student xxxx cancels class yyyy

quindi scaricali in student , class , student_booking e esegui gli aggregati su di essi ha molto senso.

(ovviamente, direi che non stai analizzando i log allora ...)

Hadoop, hbase, hive / pig è generalmente usato per questo tipo di analisi del registro o per gestire enormi dati produce log & messaggi. Questo argomento può darti ulteriori dettagli link . Ma questo ha un'enorme curva di apprendimento.