Your design should be around how you want to query. If you are only querying
by user, then having a user as part of the row key makes sense. To manage row
size, you should think of a row as being a bucket of time. Cassandra supports a
large (but not without bounds) row size. To manage row size you might say that
this row is for user fred for the month of april, or if that's too much perhaps
the row is for user fred for the day 4/18/12. To do this you can use composite
keys to hold both pieces of information in the key. (user, bucketpos)The nice
thing is that once the time period has come and gone, that row is complete, and
you can perform background jobs against that row and store summary information
for that time period. ----- Original Message -----From: "Trevor
Francis" >;trevor.fran...@tgrahamcapital.com
