I think someone with more experience with Cassandra internals can provide the nitty-gritty differences for your three scenarios. My understanding is that with Cassandra 1.x (perhaps even with 0.8x) that the overhead in creating and maintaining a keyspace is fairly minimal, and that it should not weigh in in your deciding between your scenarios 1 and 2.
Also, there are keyspace specific attributes, most notably the placement strategy and other strategy options, including the replication factor and data centers. If metadata and the keyspace level is expected to be the same for all tenants, then you can still go with either option 1 or 2. But, a separate keyspace keeps things a little cleaner in my opinion instead incorporating a tenant's name or other ID into the naming of the column families.
For my current project, I like the cleanliness of a separate keyspace per tenant. Also, I intend to make use of keyspace level config. Perhaps a larger tenant would be better served with a higher replication factor? Or perhaps their content will be replicated to specific data centers. Another tenant may have, say, no presence in Asia, so why replicate their content there?
I did not even consider your scenario 3. In my case, tenant content is updated very infrequently. My plan is record for some time interval, whether or not an update was made in a particular tenant CF. If so, then it will be snapshot and backed up. If you have multiple tenants' content in a single CF, this gets complicated. Also, if you terminate your relationship with a tenant and want to delete their data, you will have to delete all tenant specific rows, rather than just drop some number of CFs or an entire keyspace.
Don't know if this is useful or not, but I wanted to explain some of my reasoning.
Good luck!
Jeff
