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