Also, in terms of overhead, server side the overhead is pretty much all at the Column Family (CF)/Table level, so 100 keyspaces, 1 CF each, is the same as 1 keyspace, 100 CF's.
-Jeremiah On Mar 11, 2014, at 10:36 AM, Jeremiah D Jordan <jeremiah.jor...@gmail.com> wrote: > The use of more than one keyspace is not uncommon. Using 100's of them is. > That being said, different keyspaces let you specify different replication > and different authentication. If you are not going to be doing one of those > things, then there really is no point to multiple keyspaces. If you do want > to do one of those things, then go for it, make multiple keyspaces. > > > -Jeremiah > > On Mar 11, 2014, at 10:17 AM, Edward Capriolo <edlinuxg...@gmail.com> wrote: > >> I am not sure. As stated the only benefit of multiple keyspaces is if you >> need: >> >> 1) different replication per keyspace >> 2) different multiple data center configurations per keyspace >> >> Unless you have one of these cases you do not need to do this. I would >> always tackle this problem at the application level using something like: >> >> http://hector-client.github.io/hector/build/html/content/virtual_keyspaces.html >> >> Client issues aside, it is not a very common case and I would advice against >> uncommon set ups. >> >> >> >> On Tue, Mar 11, 2014 at 11:08 AM, Keith Wright <kwri...@nanigans.com> wrote: >> Does this whole true for the native protocol? I’ve noticed that you can >> create a session object in the datastax driver without specifying a keyspace >> and so long as you include the keyspace in all queries instead of just table >> name, it works fine. In that case, I assume there’s only one connection >> pool for all keyspaces. >> >> From: Edward Capriolo <edlinuxg...@gmail.com> >> Reply-To: "user@cassandra.apache.org" <user@cassandra.apache.org> >> Date: Tuesday, March 11, 2014 at 11:05 AM >> To: "user@cassandra.apache.org" <user@cassandra.apache.org> >> Subject: Re: How expensive are additional keyspaces? >> >> 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 >> >> >
