Yes in this cassandra model, time wouldn't be a column value, it would be part 
of the column name. Depending on how you want to access your data (give me all 
data points for time X) and how many separate datapoints you have for time X, 
you might consider packing all the data for a time in one column thru composite 
columnscolumn name: 2012-04-12T12:22:23.293/55/45/10 (where / is a human 
readable representation of the composite separator) in this case there wouldn't 
actually be a value, the data is just encoded in the column name.Obviously if 
you are storing dozens of separate datapoints for a timestamp than this gets 
out of hand quickly, and perhaps you need to go back to column names with 
time/fieldname format with a real value.the advantage tho of the composite key 
is that you eliminate all that constant blather about 'Wind' 'Rain' 'Sunshine' 
in your data and only hold real data. (granted compression will probably help 
here, but not having it all is even better).as for row size, obv
 iously that takes some experimentation on you part. You can bucket a row to be 
any time frame you want. If you feel that 15 minutes is the correct length of 
time given the amount of data you will write, then use 15 minutes. It it's 1 
hour, use 1 hour. The only thing you have to figure out is a 'bucket time' 
definition that you understand, likely it's the timestamp of when that time 
period starts.As for 'rotating the row', perhaps it's just semantics, but there 
really is no such concept. You are at some point in time, and you want to write 
some data to the database.The steps are1) get the user2) get the timestamp of 
the current bucket based on 'now'3) build a composite key4) insert the data 
with that keyWhether that row existed before or is a new row has no bearing on 
your client code.  ----- Original Message -----From: "Trevor Francis" 
>;trevor.fran...@tgrahamcapital.com 

Reply via email to