Return-Path: X-Original-To: apmail-cassandra-user-archive@www.apache.org Delivered-To: apmail-cassandra-user-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 500B5D2F7 for ; Thu, 8 Nov 2012 23:36:03 +0000 (UTC) Received: (qmail 39089 invoked by uid 500); 8 Nov 2012 23:36:00 -0000 Delivered-To: apmail-cassandra-user-archive@cassandra.apache.org Received: (qmail 39070 invoked by uid 500); 8 Nov 2012 23:36:00 -0000 Mailing-List: contact user-help@cassandra.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: user@cassandra.apache.org Delivered-To: mailing list user@cassandra.apache.org Received: (qmail 39061 invoked by uid 99); 8 Nov 2012 23:36:00 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 08 Nov 2012 23:36:00 +0000 X-ASF-Spam-Status: No, hits=1.5 required=5.0 tests=HTML_MESSAGE,RCVD_IN_DNSWL_LOW,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of kohlisankalp@gmail.com designates 209.85.216.172 as permitted sender) Received: from [209.85.216.172] (HELO mail-qc0-f172.google.com) (209.85.216.172) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 08 Nov 2012 23:35:51 +0000 Received: by mail-qc0-f172.google.com with SMTP id b25so2472980qca.31 for ; Thu, 08 Nov 2012 15:35:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type; bh=e8aw9KqJq2eBHoKk5KeBAiyZ1T5gv3tO+NounHFijiM=; b=B9FmxivYK/11G5WZki9VSuK8MRFxMwH+UcWesl9/hcdNexnyKl2Z7OzFJ7i13P2HcR BVy7htBQ6ymNIeVH1jSnv9N0Bpvxij2k50v04N/Y37LwuwhcTopwMIevGQcxzZFfv7Jh hSYz3b7ZISjlIAmOcygUHtRBbafZ1SUpRJLQZqu/g/dhmLJl0MgNFGT2tMrIp2FmthBz yHkm2PbvQz1Fo67QmP83KxM7+MBokoT7f/mHMtj/NxEHSXyEzYRHpog8QWGpM4aYFA1I xAoeKuSd7oBFE9RV6cj6ei12hgkxzARnPUBHFNkCbNp7y3RyStfnu4f4rYbEkXtRCaOE YHPw== Received: by 10.224.116.12 with SMTP id k12mr14461140qaq.47.1352417731221; Thu, 08 Nov 2012 15:35:31 -0800 (PST) MIME-Version: 1.0 Received: by 10.49.96.168 with HTTP; Thu, 8 Nov 2012 15:35:10 -0800 (PST) In-Reply-To: References: From: sankalp kohli Date: Thu, 8 Nov 2012 15:35:10 -0800 Message-ID: Subject: Re: Multiple keyspaces vs Multiple CFs To: user@cassandra.apache.org Content-Type: multipart/alternative; boundary=20cf3074d7e07519f204ce044a5b X-Virus-Checked: Checked by ClamAV on apache.org --20cf3074d7e07519f204ce044a5b Content-Type: text/plain; charset=ISO-8859-1 I think this code is from the thrift part. I use hector. In hector, I can create multiple keyspace objects for each keyspace and use them when I want to talk to that keyspace. Why will it need to do a round trip to the server for each switch. On Thu, Nov 8, 2012 at 3:28 PM, Edward Capriolo wrote: > In the old days the API looked like this. > > client.insert("Keyspace1", > key_user_id, > new ColumnPath("Standard1", null, "name".getBytes("UTF-8")), > "Chris Goffinet".getBytes("UTF-8"), > timestamp, > ConsistencyLevel.ONE); > > but now it works like this > > /----pay attention to this below -------------/ > client.set_keyspace("keyspace1"); > /----pay attention to this above -------------/ > client.insert( > key_user_id, > new ColumnPath("Standard1", null, > "name".getBytes("UTF-8")), > "Chris Goffinet".getBytes("UTF-8"), > timestamp, > ConsistencyLevel.ONE); > > So each time you switch keyspaces you make a network round trip. > > On Thu, Nov 8, 2012 at 6:17 PM, sankalp kohli > wrote: > > I am a bit confused. One connection pool I know is the one which > > MessageService has to other nodes. Then there will be incoming > connections > > via thrift from clients. How are they affected by multiple keyspaces? > > > > > > On Thu, Nov 8, 2012 at 3:14 PM, Edward Capriolo > > wrote: > >> > >> Any connection pool. Imagine if you have 10 column families in 10 > >> keyspaces. You pull a connection off the pool and the odds are 1 in 10 > >> of it being connected to the keyspace you want. So 9 out of 10 times > >> you have to have a network round trip just to change the keyspace, or > >> you have to build a keyspace aware connection pool. > >> Edward > >> > >> On Thu, Nov 8, 2012 at 5:36 PM, sankalp kohli > >> wrote: > >> > Which connection pool are you talking about? > >> > > >> > > >> > On Thu, Nov 8, 2012 at 2:19 PM, Edward Capriolo < > edlinuxguru@gmail.com> > >> > wrote: > >> >> > >> >> it is better to have one keyspace unless you need to replicate the > >> >> keyspaces differently. The main reason for this is that changing > >> >> keyspaces requires an RPC operation. Having 10 keyspaces would mean > >> >> having 10 connection pools. > >> >> > >> >> On Thu, Nov 8, 2012 at 4:59 PM, sankalp kohli < > kohlisankalp@gmail.com> > >> >> wrote: > >> >> > Is it better to have 10 Keyspaces with 10 CF in each keyspace. or > 100 > >> >> > keyspaces with 1 CF each. > >> >> > I am talking in terms of memory footprint. > >> >> > Also I would be interested to know how much better one is over > other. > >> >> > > >> >> > Thanks, > >> >> > Sankalp > >> > > >> > > > > > > --20cf3074d7e07519f204ce044a5b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I think this code is from the thrift part. I use hector. In hector, I can c= reate multiple keyspace objects for each keyspace and use them when I want = to talk to that keyspace. Why will it need to do a round trip to the server= for each switch.=A0


On Thu, Nov 8, 2012 at 3:28 PM, Edward C= apriolo <edlinuxguru@gmail.com> wrote:
In the old days the API looked like this.

=A0 client.insert("Keyspace1",
=A0 =A0 =A0 =A0 =A0 =A0 =A0key_user_id,
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0new ColumnPath("Standard1", null, = "name".getBytes("UTF-8")),
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 "Chris Goffinet".getBytes(&qu= ot;UTF-8"),
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0timestamp,
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0ConsistencyLevel.ONE);

but now it works like this

/----pay attention to this below -------------/
client.set_keyspace("keyspace1");
/----pay attention to this above -------------/
=A0 client.insert(
=A0 =A0 =A0 =A0 =A0key_user_id,
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0new ColumnPath("Standard1&q= uot;, null,
"name".getBytes("UTF-8")),
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 "Chris Goffinet".getB= ytes("UTF-8"),
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 timestamp,
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 ConsistencyLevel.ONE);

So each time you switch keyspaces you make a network round trip.

On Thu, Nov 8, 2012 at 6:17 PM, sankalp kohli <kohlisankalp@gmail.com> wrote:
> I am a bit confused. One connection pool I know is the one which
> MessageService has to other nodes. Then there will be incoming connect= ions
> via thrift from clients. How are they affected by multiple keyspaces?<= br> >
>
> On Thu, Nov 8, 2012 at 3:14 PM, Edward Capriolo <edlinuxguru@gmail.com>
> wrote:
>>
>> Any connection pool. Imagine if you have 10 column families in 10<= br> >> keyspaces. You pull a connection off the pool and the odds are 1 i= n 10
>> of it being connected to the keyspace you want. So 9 out of 10 tim= es
>> you have to have a network round trip just to change the keyspace,= or
>> you have to build a keyspace aware connection pool.
>> Edward
>>
>> On Thu, Nov 8, 2012 at 5:36 PM, sankalp kohli <kohlisankalp@gmail.com>
>> wrote:
>> > Which connection pool are you talking about?
>> >
>> >
>> > On Thu, Nov 8, 2012 at 2:19 PM, Edward Capriolo <edlinuxguru@gmail.com>
>> > wrote:
>> >>
>> >> it is better to have one keyspace unless you need to repl= icate the
>> >> keyspaces differently. The main reason for this is that c= hanging
>> >> keyspaces requires an RPC operation. Having 10 keyspaces = would mean
>> >> having 10 connection pools.
>> >>
>> >> On Thu, Nov 8, 2012 at 4:59 PM, sankalp kohli <kohlisankalp@gmail.com>
>> >> wrote:
>> >> > Is it better to have 10 Keyspaces with 10 CF in each= keyspace. or 100
>> >> > keyspaces with 1 CF each.
>> >> > I am talking in terms of memory footprint.
>> >> > Also I would be interested to know how much better o= ne is over other.
>> >> >
>> >> > Thanks,
>> >> > Sankalp
>> >
>> >
>
>

--20cf3074d7e07519f204ce044a5b--