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 F1F2911340 for ; Tue, 5 Aug 2014 12:43:48 +0000 (UTC) Received: (qmail 30582 invoked by uid 500); 5 Aug 2014 12:43:46 -0000 Delivered-To: apmail-cassandra-user-archive@cassandra.apache.org Received: (qmail 30543 invoked by uid 500); 5 Aug 2014 12:43:46 -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 30529 invoked by uid 99); 5 Aug 2014 12:43:46 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 05 Aug 2014 12:43:46 +0000 X-ASF-Spam-Status: No, hits=3.5 required=5.0 tests=HTML_MESSAGE,RCVD_IN_DNSWL_LOW,SPF_NEUTRAL,URI_HEX X-Spam-Check-By: apache.org Received-SPF: neutral (nike.apache.org: local policy) Received: from [209.85.213.170] (HELO mail-ig0-f170.google.com) (209.85.213.170) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 05 Aug 2014 12:43:44 +0000 Received: by mail-ig0-f170.google.com with SMTP id h3so8726716igd.5 for ; Tue, 05 Aug 2014 05:43:18 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=RG3kWDLs/c8RFcrNzusSzm5T4j+kNJJrL1A12e4FnXc=; b=Y17qQOunzmxttdq9ZX6P/2cxhoGXOmOJaV66kVX4xSThp83MYgIH6tUSuCWzC+2ujs Ndj3N9ci4IP1eXPOgHIahHvLaS2KfUqew2FYP1sQnLQb8dtcReA1sgiSpQaaTDkJ660+ fnEzjCSCfR5ZqFOr5e3RsQC14z6ac4uCrEj+vvCboSnV84MIekJTmdlssdwpKgNY0jsT Rok/spDlr1npVFY3mu5bvqSt1Xute4uZiQj+iwUGsP8pc4nhuu7tdNtgP4Jj7jkdwvs6 PbtxMFEdlYK8MH+8tntfg4MxxD7nO9faiiRupFC3JmvTQbGUeaT3T2UsQNtifYoP5zwT An8g== X-Gm-Message-State: ALoCoQmAa324UX6biuSW0tGTjJmRTgi89YJHN778Zu3MTUE6uOhVbk6cphept6HfhnbHkD1OjUql MIME-Version: 1.0 X-Received: by 10.50.6.36 with SMTP id x4mr46363699igx.47.1407242598588; Tue, 05 Aug 2014 05:43:18 -0700 (PDT) Received: by 10.64.130.170 with HTTP; Tue, 5 Aug 2014 05:43:18 -0700 (PDT) X-Originating-IP: [89.101.207.179] In-Reply-To: <1407238578145-7596119.post@n2.nabble.com> References: <1407226178633-7596106.post@n2.nabble.com> <1407238578145-7596119.post@n2.nabble.com> Date: Tue, 5 Aug 2014 13:43:18 +0100 Message-ID: Subject: Re: Reasonable range for the max number of tables? From: Michal Michalski To: user@cassandra.apache.org Content-Type: multipart/alternative; boundary=047d7bdc174233c03d04ffe13398 X-Virus-Checked: Checked by ClamAV on apache.org --047d7bdc174233c03d04ffe13398 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable >> - Use a keyspace per customer > These effectively amount to the same thing and they both fall foul to the > limit in the number of column families so do not scale. But then you can scale by moving some of the customers to a new cluster easily. If you keep everything in a single keyspace or - worse - if you do your multitenancy by prefixing row keys with customer ids of some kind, it won't be that easy, as you wrote later in your e-mail. M. Kind regards, Micha=C5=82 Michalski, michal.michalski@boxever.com On 5 August 2014 12:36, Phil Luckhurst wrote: > Hi Mark, > > Mark Reddy wrote > > To segregate customer data, you could: > > - Use customer specific column families under a single keyspace > > - Use a keyspace per customer > > These effectively amount to the same thing and they both fall foul to the > limit in the number of column families so do not scale. > > > Mark Reddy wrote > > - Use the same column families and have a column that identifies the > > customer. On the application layer ensure that there are sufficient > checks > > so one customer can't read another customers data > > And while this gets around the column family limit it does not allow the > same level of data segregation. For example with a separate keyspace or > column families it is trivial to remove a single customer's data or move > that data to another system. With one set of column families for all > customers these types of actions become much more difficult as any change > impacts all customers but perhaps that's the price we have to pay to scal= e. > > And I still think this needs to be made more prominent in the > documentation. > > Thanks > Phil > > > > -- > View this message in context: > http://cassandra-user-incubator-apache-org.3065146.n2.nabble.com/Reasonab= le-range-for-the-max-number-of-tables-tp7596094p7596119.html > Sent from the cassandra-user@incubator.apache.org mailing list archive at > Nabble.com. > --047d7bdc174233c03d04ffe13398 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
>> - Use a keyspace per customer
> These effectively amount to the same thing and they b= oth fall foul to the
> limi= t in the number of column families so do not scale.

But then you can scale by moving some of the customers to a new cluster = easily. If you keep everything in a single keyspace or - worse - if you do = your multitenancy by prefixing row keys with customer ids of some kind, it = won't be that easy, as you wrote later in your e-mail.

M.<= /span>

=C2=A0

Kind regards,
Micha=C5=82 Michalski,


On 5 August 2014 12:36, Phil Luckhurst <= span dir=3D"ltr"><phil.luckhurst@powerassure.com> wrote:
Hi Mark,

Mark Reddy wrote
> To segregate customer data, you could:
> - Use customer specific column families under a single keyspace
> - Use a keyspace per customer

These effectively amount to the same thing and they both fall foul to= the
limit in the number of column families so do not scale.


Mark Reddy wrote
> - Use the same column families and have a column that = identifies the
> customer. On the application layer ensure that there are sufficient ch= ecks
> so one customer can't read another customers data

And while this gets around the column family limit it does not allow = the
same level of data segregation. For example with a separate keyspace or
column families it is trivial to remove a single customer's data or mov= e
that data to another system. With one set of column families for all
customers these types of actions become much more difficult as any change impacts all customers but perhaps that's the price we have to pay to sc= ale.

And I still think this needs to be made more prominent in the documentation= .

Thanks
Phil



--
View this message in context: http://cassandra-user-incubator= -apache-org.3065146.n2.nabble.com/Reasonable-range-for-the-max-number-of-ta= bles-tp7596094p7596119.html
Sent from the cassandra-user@incubator.apache.org m= ailing list archive at Nabble.com.

--047d7bdc174233c03d04ffe13398--