We're using 0.7
On 9/3/2010 6:48 AM, vineet daniel wrote:
If I am correct than you need to restart cassandra whenever you adding
a new KeySpace. Thats another concern.
Vineet Daniel
Cell : +91-8106217121
Websites :
Blog <http://vinetedaniel.blogspot.com> | Linkedin
<http://in.linkedin.com/in/vineetdaniel> | Twitter
<https://twitter.com/vineetdaniel>
On Fri, Sep 3, 2010 at 2:58 PM, Mike Peters
<[email protected]
<mailto:[email protected]>> wrote:
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
<[email protected]>
<mailto:[email protected]> 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?
