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 2DC1E9C05 for ; Fri, 7 Oct 2011 14:37:22 +0000 (UTC) Received: (qmail 42281 invoked by uid 500); 7 Oct 2011 14:37:20 -0000 Delivered-To: apmail-cassandra-user-archive@cassandra.apache.org Received: (qmail 42230 invoked by uid 500); 7 Oct 2011 14:37:20 -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 42222 invoked by uid 99); 7 Oct 2011 14:37:20 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 07 Oct 2011 14:37:19 +0000 X-ASF-Spam-Status: No, hits=2.2 required=5.0 tests=HTML_MESSAGE,RCVD_IN_DNSWL_LOW,SPF_NEUTRAL X-Spam-Check-By: apache.org Received-SPF: neutral (nike.apache.org: local policy) Received: from [74.125.82.172] (HELO mail-wy0-f172.google.com) (74.125.82.172) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 07 Oct 2011 14:37:12 +0000 Received: by wyg24 with SMTP id 24so974254wyg.31 for ; Fri, 07 Oct 2011 07:36:52 -0700 (PDT) MIME-Version: 1.0 Received: by 10.216.174.20 with SMTP id w20mr2845928wel.33.1317998211809; Fri, 07 Oct 2011 07:36:51 -0700 (PDT) Received: by 10.216.153.195 with HTTP; Fri, 7 Oct 2011 07:36:51 -0700 (PDT) In-Reply-To: References: Date: Fri, 7 Oct 2011 09:36:51 -0500 Message-ID: Subject: Re: For multi-tenant, is it good to have a key space for each tenant? From: David McNelis To: user@cassandra.apache.org Content-Type: multipart/alternative; boundary=0016364c70623ac0f904aeb65fcf X-Virus-Checked: Checked by ClamAV on apache.org --0016364c70623ac0f904aeb65fcf Content-Type: text/plain; charset=ISO-8859-1 Reviving this thread... Say you want to enable potentially thousands of tenants with their own sets of column families? In this situation a keyspace for each tenant wouldn't work it would seem...what issues would we likely see if we were to build out thousands of column families (where a column family name contains a unique identifier to the tenant)? In some documentation I've read it says that keyspace's take up the majority of the resources, in a couple of older threads they talked about getting the number of column families down. At the end of the day the best part of cassandra is not having to shard...but in this instance, it seems like multiple clusters would make the most sense, where you'd need to find the keyspace/column family sweet spot for your application. Ideally I'd think you'd want to be able to have a keyspace for each tenant, then as many column families as that tenant required, and be able to do it on a single cluster. Has anyone come up with a rule of thumb regarding number of keyspaces / column families? On Thu, Aug 25, 2011 at 1:13 PM, Nate McCall wrote: > We have a 'virtual keyspaces' feature baked into the Hector client > that might be of interest: > https://github.com/rantav/hector/wiki/Virtual-Keyspaces > > On Thu, Aug 25, 2011 at 8:23 AM, Terje Marthinussen > wrote: > > > > Depends of course a lot on how many tenants you have. > > Hopefully the new off heap memtables is 1.0 may help as well as java gc > on large heaps is getting a much bigger issue than memory cost. > > Regards, > > Terje > > On 25 Aug 2011, at 14:20, Himanshi Sharma > wrote: > > > > > > I am working on similar sort of stuff. As per my knowledge, creating > keyspace for each tenant would impose lot of memory constraints. > > > > Following Shared Keyspace and Shared Column families would be a better > approach. And each row in CF could be referred by tenant_id as row key. > > And again it depends on the type of application. > > > > Hey this is just a suggestion, m not completely sure.. :) > > > > > > Himanshi Sharma > > > > > > > > > > From: Guofeng Zhang > > To: user@cassandra.apache.org > > Date: 08/25/2011 10:38 AM > > Subject: For multi-tenant, is it good to have a key space for each > tenant? > > ________________________________ > > > > > > I wonder if it is a good practice to create a key space for each tenant. > Any advice is appreciated. > > > > Thanks > > > > > > =====-----=====-----===== > > Notice: The information contained in this e-mail > > message and/or attachments to it may contain > > confidential or privileged information. If you are > > not the intended recipient, any dissemination, use, > > review, distribution, printing or copying of the > > information contained in this e-mail message > > and/or attachments to it are strictly prohibited. If > > you have received this communication in error, > > please notify us by reply e-mail or telephone and > > immediately and permanently delete the message > > and any attachments. Thank you > > > > > -- *David McNelis* Lead Software Engineer Agentis Energy www.agentisenergy.com o: 630.359.6395 c: 219.384.5143 *A Smart Grid technology company focused on helping consumers of energy control an often under-managed resource.* --0016364c70623ac0f904aeb65fcf Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Reviving this thread...

Say you want to enable potential= ly thousands of tenants with their own sets of column families? =A0In this = situation a keyspace for each tenant wouldn't work it would seem...what= issues would we likely see if we were to build out thousands of column fam= ilies (where a column family name contains a unique identifier to the tenan= t)? =A0In some documentation I've read it says that keyspace's take= up the majority of the resources, in a couple of older threads they talked= about getting the number of column families down.

At the end of the day the best part of cassandra is not= having to shard...but in this =A0instance, it seems like multiple clusters= would make the most sense, where you'd need to find the keyspace/colum= n family sweet spot for your application. =A0

Ideally I'd think you'd want to be able to have= a keyspace for each tenant, then as many column families as that tenant re= quired, and be able to do it on a single cluster.

Has anyone come up with a rule of thumb regarding number of keyspaces / col= umn families?

On Thu, Aug 25, 2011= at 1:13 PM, Nate McCall <nate@datastax.com> wrote:
We have a 'virtual keyspaces' featu= re baked into the Hector client
that might be of interest:
https://github.com/rantav/hector/wiki/Virtual-Keyspaces

On Thu, Aug 25, 2011 at 8:23 AM, Terje Marthinussen
<tmarthinussen@gmail.com&= gt; wrote:
>
> Depends of course a lot on how many tenants you have.
> Hopefully the new off heap memtables is 1.0 may help as well as java g= c on large heaps is getting a much bigger issue than memory cost.
> Regards,
> Terje
> On 25 Aug 2011, at 14:20, Himanshi Sharma <himanshi.sharma@tcs.com> wrote:
>
>
> I am working on similar sort of stuff. As per my knowledge, creating k= eyspace for each tenant would impose lot of memory constraints.
>
> Following Shared Keyspace and Shared Column families would be a better= approach. And each row in CF could be referred by tenant_id as row key. > And again it depends on the type of application.
>
> Hey this is just a suggestion, m not completely sure.. :)
>
>
> Himanshi Sharma
>
>
>
>
> From: Guofeng Zhang <guofeng= zh@gmail.com>
> To: user@cassandra.apache= .org
> Date: 08/25/2011 10:38 AM
> Subject: For multi-tenant, is it good to have a key space for each ten= ant?
> ________________________________
>
>
> I wonder if it is a good practice to create a key space for each tenan= t. Any advice is appreciated.
>
> Thanks
>
>
> =3D=3D=3D=3D=3D-----=3D=3D=3D=3D=3D-----=3D=3D=3D=3D=3D
> Notice: The information contained in this e-mail
> message and/or attachments to it may contain
> confidential or privileged information. If you are
> not the intended recipient, any dissemination, use,
> review, distribution, printing or copying of the
> information contained in this e-mail message
> and/or attachments to it are strictly prohibited. If
> you have received this communication in error,
> please notify us by reply e-mail or telephone and
> immediately and permanently delete the message
> and any attachments. Thank you
>
>



--
= David McNelis
Lead Software E= ngineer
Agentis Energy<= /font>
o: 630.359.6395
c: 219.384.5143<= /span>

A Smart Grid technology company focused on helping consumers of = energy control an often under-managed resource.


--0016364c70623ac0f904aeb65fcf--