incubator-cassandra-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Edward Capriolo <>
Subject Re: How expensive are additional keyspaces?
Date Tue, 11 Mar 2014 15:05:55 GMT
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

On Tue, Mar 11, 2014 at 10:17 AM, Martin Meyer <>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

View raw message