The biggest expense of them is that you need to be authenticated to a keyspace to perform and operation. Thus connection pools are bound to keyspaces. Switching a keyspace is an RPC operation. In the thrift client, If you have 100 keyspaces you need 100 connection pools that starts to be a pain very quickly.
I suggest keeping everything in one keyspace unless you really need different replication factors and or network replication settings per keyspace. On Tue, Mar 11, 2014 at 10:17 AM, Martin Meyer <elreydet...@gmail.com>wrote: > Hey all - > > My company is working on introducing a configuration service system to > provide cofig data to several of our applications, to be backed by > Cassandra. We're already using Cassandra for other services, and at > the moment our pending design just puts all the new tables (9 of them, > I believe) in one of our pre-existing keyspaces. > > I've got a few questions about keyspaces that I'm hoping for input on. > Some Google hunting didn't turn up obvious answers, at least not for > recent versions of Cassandra. > > 1) What trade offs are being made by using a new keyspace versus > re-purposing an existing one (that is in active use by another > application)? Organization is the obvious answer, I'm looking for any > technical reasons. > > 2) Is there any per-keyspace overhead incurred by the cluster? > > 3) Does it impact on-disk layout at all for tables to be in a > different keyspace from others? Is any sort of file fragmentation > potentially introduced just by doing this in a new keyspace as opposed > to an exiting one? > > 4) Does it add any metadata overhead to the system keyspace? > > 5) Why might we *not* want to make a separate keyspace for this? > > 6) Does anyone have experience with creating additional keyspaces to > the point that Cassandra can no longer handle it? Note that we're > *not* planning to do this, I'm just curious. > > Cheers, > Martin >
