La memorizzazione di 86k super colonne (con 1-10 piccole colonne ciascuna) per riga è una buona idea in Cassandra?

Question

TLDR: ~ 90.000 super colonne con 1 a 10 colonne ciascuna troppe in una riga? Che ne dici di ~ 1500? I valori della colonna sono di circa 6 byte ciascuno.

Domanda completa:

Sto ricercando vari negozi di dati per i dati delle serie temporali. I database orientati alle colonne come Cassandra e HBase sembrano adattarsi molto.

I requisiti sono archiviare milioni di serie di dati che lo arrivano a (minimo) un intervallo di 1 minuto. Idealmente saremmo in grado di supportare un intervallo di 1 secondo se l'azienda necessita di richiederlo (loro potrebbe probabilmente lo farà).

Il consiglio offerto in questo post sul blog così come usato da Opentsdb ha un sacco di senso.

Essenzialmente le chiavi sono la serie ID concatenata al primo timbro temporale del giorno, le colonne vengono create per ciascuna misurazione del giorno. Sono circa 86400 colonne per riga.

Tuttavia, l'immutabilità/versioning dei dati è abbastanza importante. Le esigenze aziendali determinano la possibilità di aggiornare i valori delle serie mantenendo la storia completa dei dati.

Esplorare le super colonne di Cassandra per fornire un'altra dimensione per versione i valori si traducono in 86400 super colonne. Ogni colonna Super conterrebbe quindi una colonna quando il valore viene creato per la prima volta (possibilmente un timeuuid), quindi avere un'altra colonna aggiunta su ogni "aggiornamento". Gli aggiornamenti si verificheranno regolarmente a sottoinsiemi limitati di serie e valori. Sotto condizioni ideali Non ci saranno aggiornamenti. Idealmente questo significa che ogni super colonna non ha un'enorme quantità di dati da caricare e la maggior parte dell'accesso sarà solo al valore più recente.

Quindi tornare alla domanda:

C'è un successo o un problema che sto cercando di usare tante colonne (86k) per riga?