Return-Path: 
 <user-return-5081-apmail-cassandra-user-archive=cassandra.apache.org@cassandra.apache.org>
Delivered-To: apmail-cassandra-user-archive@www.apache.org
Received: (qmail 78528 invoked from network); 28 Apr 2010 08:15:42 -0000
Received: from unknown (HELO mail.apache.org) (140.211.11.3)
  by 140.211.11.9 with SMTP; 28 Apr 2010 08:15:42 -0000
Received: (qmail 82011 invoked by uid 500); 28 Apr 2010 08:15:41 -0000
Delivered-To: apmail-cassandra-user-archive@cassandra.apache.org
Received: (qmail 81946 invoked by uid 500); 28 Apr 2010 08:15:39 -0000
Mailing-List: contact user-help@cassandra.apache.org; run by ezmlm
Precedence: bulk
List-Help: <mailto:user-help@cassandra.apache.org>
List-Unsubscribe: <mailto:user-unsubscribe@cassandra.apache.org>
List-Post: <mailto:user@cassandra.apache.org>
List-Id: <user.cassandra.apache.org>
Reply-To: user@cassandra.apache.org
Delivered-To: mailing list user@cassandra.apache.org
Received: (qmail 81938 invoked by uid 99); 28 Apr 2010 08:15:39 -0000
Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136)
    by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 28 Apr 2010 08:15:39 +0000
X-ASF-Spam-Status: No, hits=2.6 required=10.0
	tests=AWL,HTML_MESSAGE,RCVD_IN_DNSWL_NONE,SPF_NEUTRAL
X-Spam-Check-By: apache.org
Received-SPF: neutral (athena.apache.org: local policy)
Received: from [209.85.218.222] (HELO mail-bw0-f222.google.com)
 (209.85.218.222)
    by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 28 Apr 2010 08:15:31 +0000
Received: by bwz22 with SMTP id 22so13115921bwz.25
        for <user@cassandra.apache.org>; Wed, 28 Apr 2010 01:15:10 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.103.78.31 with SMTP id f31mr3811400mul.79.1272442509754; Wed,
	28 Apr 2010 01:15:09 -0700 (PDT)
Received: by 10.102.228.18 with HTTP; Wed, 28 Apr 2010 01:15:09 -0700 (PDT)
X-Originating-IP: [80.179.102.198]
In-Reply-To: <o2xff1a07b81004271513g9a5f2a9dl9e6ea478731bd6d@mail.gmail.com>
References: <h2k36a14751004270657s362d435eg7bd5679ef3dce3dd@mail.gmail.com>
	 <p2wac68ab851004270927rea44f1bfq9453b99c0f1cd3fd@mail.gmail.com>
	 <o2xff1a07b81004271513g9a5f2a9dl9e6ea478731bd6d@mail.gmail.com>
Date: Wed, 28 Apr 2010 11:15:09 +0300
Message-ID: <y2o36a14751004280115yd0355d5cx530b4869b9dc91d2@mail.gmail.com>
Subject: Re: Multiple keyspaces per application?
From: David Boxenhorn <david@lookin2.com>
To: user@cassandra.apache.org
Content-Type: multipart/alternative; boundary=0016e65b6292ca83d50485479b77

--0016e65b6292ca83d50485479b77
Content-Type: text/plain; charset=ISO-8859-1

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 <markxr@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
>

--0016e65b6292ca83d50485479b77
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>Thanks all!</div>
<div>=A0</div>
<div>The reason I was thinking of having two keyspaces is that I expect the=
m to evolve at different rates. Our normal column families will change rare=
ly (hopefully never) but our index column families will change whenever we =
want to query the data in a new way, that isn&#39;t supported by the curren=
t indexes. </div>

<div>=A0</div>
<div>From what you&#39;ve all said, it doesn&#39;t seem like it&#39;s worth=
 it.</div>
<div><br><br></div>
<div class=3D"gmail_quote">On Wed, Apr 28, 2010 at 1:13 AM, Mark Robson <sp=
an dir=3D"ltr">&lt;<a href=3D"mailto:markxr@gmail.com">markxr@gmail.com</a>=
&gt;</span> wrote:<br>
<blockquote style=3D"BORDER-LEFT: #ccc 1px solid; MARGIN: 0px 0px 0px 0.8ex=
; PADDING-LEFT: 1ex" class=3D"gmail_quote">
<div class=3D"gmail_quote">I can&#39;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.</div>
<div class=3D"gmail_quote"><br></div>
<div class=3D"gmail_quote">Things more important than replication-factor, s=
uch as partitioner and ring token distribution would be compromised by seve=
ral 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 ben=
efit from many dedicated nodes.</div>

<div class=3D"gmail_quote"><br></div>
<div class=3D"gmail_quote">If you did decide that multiple keyspaces was th=
e right thing to do, your client tasks can simply maintain several connecti=
ons to them (if they individually need &gt;1); this should not be a problem=
.</div>

<div class=3D"gmail_quote"><br></div><font color=3D"#888888">
<div class=3D"gmail_quote">Mark</div></font></blockquote></div><br></div>

--0016e65b6292ca83d50485479b77--