if I have time this summer, I may work on that, since I like having thrift.
On Tue, Mar 11, 2014 at 12:05 PM, Edward Capriolo <edlinuxg...@gmail.com>wrote: > This mistake is not a thrift limitation. In 0.6.X you could switch > keyspaces without calling setKeyspace(String) methods specified the > keyspace in every operation. This is mirrors the StorageProxy class. In > 0.7.X setKeyspace() was created and the keyspace was removed from all these > thrift methods. I really dislike that change personally :) > > If someone was so motivated, they could pretty easily (a couple days work) > add new methods to thrift that do not have this limitation. > > > > > On Tue, Mar 11, 2014 at 11:39 AM, Jonathan Ellis <jbel...@gmail.com>wrote: > >> That is correct. Another place where the mistakes of Thrift informed >> our development of the native protocol. >> >> On Tue, Mar 11, 2014 at 10: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 >> > >> > >> >> >> >> -- >> Jonathan Ellis >> Project Chair, Apache Cassandra >> co-founder, http://www.datastax.com >> @spyced >> > >
