Yes, right now it's probably not technically possible, from a resource point of view, to run 4k keyspaces in a cassandra cluster.
Those management features you may have been able to do as meta data operations will prob become long running background tasks.
On 3 Sep 2010, at 21:28, Mike Peters <email@example.com
Very interesting. Thank you
So it sounds like other than being able to quickly truncate
customer-keyspaces, with Cassandra there's no real benefit in
keeping each customer data in a separate keyspace.
We'll suffer on the memory side with all the switching between
keyspaces and we're better off storing all customer data under the
On 9/2/2010 11:29 PM, Aaron Morton wrote:
Create one big happy love in keyspace. Use the key structure
to identify the different clients data.
The is more support for multi tenancy systems but a lot of
the memory configuration is per keyspace/column family, so you
cannot run that many keyspaces.
We're in the process of migrating 4,000 MySQL client
Cassandra. All database schemas are identical.
With MySQL, we used to provision a separate 'database' per
to make it easier to shard and move things around.
Does it make sense to migrate the 4,000 MySQL databases to
keyspaces in Cassandra? Or should we stick with a single
My concerns are -
#1. Will every single node end up with 4k folders under
#2. Performance: Will Cassandra work better with a single
lots of keys, or thousands of keyspaces?
Granted it's 'cleaner' to have a separate keyspace per
each client, but
maybe that's not the best approach with Cassandra.