cassandra-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mike Peters <cassan...@softwareprojects.com>
Subject Re: 4k keyspaces... Maybe we're doing it wrong?
Date Fri, 03 Sep 2010 09:28:12 GMT
  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 same keyspace?


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.
>
> This page has some more information 
> http://wiki.apache.org/cassandra/MultiTenant
>
> Aaron
>
>
> On 03 Sep, 2010,at 01:25 PM, Mike Peters 
> <cassandra@softwareprojects.com> wrote:
>
>> Hi,
>>
>> We're in the process of migrating 4,000 MySQL client databases to
>> Cassandra. All database schemas are identical.
>>
>> With MySQL, we used to provision a separate 'database' per each client,
>> to make it easier to shard and move things around.
>>
>> Does it make sense to migrate the 4,000 MySQL databases to 4,000
>> keyspaces in Cassandra? Or should we stick with a single keyspace?
>>
>> My concerns are -
>> #1. Will every single node end up with 4k folders under /cassandra/data/?
>>
>> #2. Performance: Will Cassandra work better with a single keyspace +
>> 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.
>>
>> Thoughts?


Mime
View raw message