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,
obviously 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;trevor.fran...@tgrahamcapital.com
