You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@cassandra.apache.org by David Boxenhorn <da...@lookin2.com> on 2010/04/27 15:57:16 UTC

Multiple keyspaces per application?

I just saw this note from storage-conf.xml:

"Except in very unusual circumstances you will have one Keyspace per
application."

Why is that?

I was thinking of putting our "normal data" and "indexes" in separate
keyspaces so they could be maintained separately.

What are the disadvantages of multiple keyspaces?

Re: Multiple keyspaces per application?

Posted by Miguel Verde <mi...@gmail.com>.
Replication Factor, the number of copies (replicas) of the data that
Cassandra will store and an important number for quorum consistency
calculations.
On Tue, Apr 27, 2010 at 11:14 AM, David Boxenhorn <da...@lookin2.com> wrote:

> Thanks!..... er, what is RF?
>
>
> On Tue, Apr 27, 2010 at 6:50 PM, banks <ba...@gmail.com> wrote:
>
>> The only advantage is the RF is per keyspace
>>
>>
>> On Tue, Apr 27, 2010 at 6:57 AM, David Boxenhorn <da...@lookin2.com>wrote:
>>
>>>  I just saw this note from storage-conf.xml:
>>>
>>> "Except in very unusual circumstances you will have one Keyspace per
>>> application."
>>>
>>> Why is that?
>>>
>>> I was thinking of putting our "normal data" and "indexes" in separate
>>> keyspaces so they could be maintained separately.
>>>
>>> What are the disadvantages of multiple keyspaces?
>>>
>>
>>
>

Re: Multiple keyspaces per application?

Posted by David Boxenhorn <da...@lookin2.com>.
Thanks!..... er, what is RF?

On Tue, Apr 27, 2010 at 6:50 PM, banks <ba...@gmail.com> wrote:

> The only advantage is the RF is per keyspace
>
>
> On Tue, Apr 27, 2010 at 6:57 AM, David Boxenhorn <da...@lookin2.com>wrote:
>
>>  I just saw this note from storage-conf.xml:
>>
>> "Except in very unusual circumstances you will have one Keyspace per
>> application."
>>
>> Why is that?
>>
>> I was thinking of putting our "normal data" and "indexes" in separate
>> keyspaces so they could be maintained separately.
>>
>> What are the disadvantages of multiple keyspaces?
>>
>
>

Re: Multiple keyspaces per application?

Posted by banks <ba...@gmail.com>.
The only advantage is the RF is per keyspace

On Tue, Apr 27, 2010 at 6:57 AM, David Boxenhorn <da...@lookin2.com> wrote:

> I just saw this note from storage-conf.xml:
>
> "Except in very unusual circumstances you will have one Keyspace per
> application."
>
> Why is that?
>
> I was thinking of putting our "normal data" and "indexes" in separate
> keyspaces so they could be maintained separately.
>
> What are the disadvantages of multiple keyspaces?
>

Re: Multiple keyspaces per application?

Posted by Sylvain Lebresne <sy...@yakaz.com>.
> From what you've all said, it doesn't seem like it's worth it.

No. But you will want to follow that
https://issues.apache.org/jira/browse/CASSANDRA-1007


>
> On Wed, Apr 28, 2010 at 1:13 AM, Mark Robson <ma...@gmail.com> wrote:
>>
>> I can't see any advantage in using multiple keyspaces. It is highly
>> unlikely that several applications would share the same Cassandra cluster in
>> any nontrivial deployment.
>> Things more important than replication-factor, such as partitioner and
>> ring token distribution would be compromised by several apps sharing the
>> same cluster. Moreover, an application which was using Cassandra is likely
>> to have so much data to store that it can usefully benefit from many
>> dedicated nodes.
>> If you did decide that multiple keyspaces was the right thing to do, your
>> client tasks can simply maintain several connections to them (if they
>> individually need >1); this should not be a problem.
>> Mark
>

Re: Multiple keyspaces per application?

Posted by David Boxenhorn <da...@lookin2.com>.
Thanks all!

The reason I was thinking of having two keyspaces is that I expect them to
evolve at different rates. Our normal column families will change rarely
(hopefully never) but our index column families will change whenever we want
to query the data in a new way, that isn't supported by the current indexes.


>From what you've all said, it doesn't seem like it's worth it.


On Wed, Apr 28, 2010 at 1:13 AM, Mark Robson <ma...@gmail.com> wrote:

> I can't see any advantage in using multiple keyspaces. It is highly
> unlikely that several applications would share the same Cassandra cluster in
> any nontrivial deployment.
>
> Things more important than replication-factor, such as partitioner and ring
> token distribution would be compromised by several apps sharing the same
> cluster. Moreover, an application which was using Cassandra is likely to
> have so much data to store that it can usefully benefit from many dedicated
> nodes.
>
> If you did decide that multiple keyspaces was the right thing to do, your
> client tasks can simply maintain several connections to them (if they
> individually need >1); this should not be a problem.
>
> Mark
>

Re: Multiple keyspaces per application?

Posted by Mark Robson <ma...@gmail.com>.
I can't see any advantage in using multiple keyspaces. It is highly unlikely
that several applications would share the same Cassandra cluster in any
nontrivial deployment.

Things more important than replication-factor, such as partitioner and ring
token distribution would be compromised by several apps sharing the same
cluster. Moreover, an application which was using Cassandra is likely to
have so much data to store that it can usefully benefit from many dedicated
nodes.

If you did decide that multiple keyspaces was the right thing to do, your
client tasks can simply maintain several connections to them (if they
individually need >1); this should not be a problem.

Mark

Re: Multiple keyspaces per application?

Posted by Sylvain Lebresne <sy...@yakaz.com>.
I think the idea behind this sentence in storage-conf.xml is just to
say that, unless you're
doing something specific (like not have the same replication factor
for all your data), there
is no reason you would want more than one keyspace by application.

As for disadvantages, you may want to know that in the next cassandra
release (the 0.7 one),
a login will be introduced. With that, the choice of the keyspace will
move from every request
(as it is right now) to the login part. The following request will
then use the keyspace set at login.
It may make it a little bit more painful to use multiple keyspace in
the same application, so that
may be one reason why not to unless you have good reason.

--
Sylvain


On Tue, Apr 27, 2010 at 3:57 PM, David Boxenhorn <da...@lookin2.com> wrote:
> I just saw this note from storage-conf.xml:
>
> "Except in very unusual circumstances you will have one Keyspace per
> application."
>
> Why is that?
>
> I was thinking of putting our "normal data" and "indexes" in separate
> keyspaces so they could be maintained separately.
>
> What are the disadvantages of multiple keyspaces?