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 88892CD65 for ; Fri, 8 Jun 2012 09:30:36 +0000 (UTC) Received: (qmail 71113 invoked by uid 500); 8 Jun 2012 09:30:34 -0000 Delivered-To: apmail-cassandra-user-archive@cassandra.apache.org Received: (qmail 70698 invoked by uid 500); 8 Jun 2012 09:30:33 -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 70674 invoked by uid 99); 8 Jun 2012 09:30:32 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 08 Jun 2012 09:30:32 +0000 X-ASF-Spam-Status: No, hits=0.7 required=5.0 tests=FSL_RCVD_USER,SPF_NEUTRAL X-Spam-Check-By: apache.org Received-SPF: neutral (nike.apache.org: local policy) Received: from [61.213.57.180] (HELO ff8gtw2.as.netxdc.ne.jp) (61.213.57.180) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 08 Jun 2012 09:30:27 +0000 Received: from ff8arl3.as.netxdc.ne.jp ([10.100.8.163]) by ff8gtw2.as.netxdc.ne.jp (scs mail gateway) with ESMTP id <0M5A00KCYL0Q2JB0@ff8gtw2.as.netxdc.ne.jp> for user@cassandra.apache.org; Fri, 08 Jun 2012 18:29:14 +0900 (JST) Received: from 10.100.41.27 (10.100.41.27) by with ESMTP; Fri, 08 Jun 2012 18:29:14 +0900 Received: from ff8pbm1.as.netxdc.ne.jp ([10.100.41.42]) by ff8vws3.as.netxdc.ne.jp (scs mail proxy) with ESMTP id <0M5A00KM2L0IOI70@ff8vws3.as.netxdc.ne.jp> for user@cassandra.apache.org; Fri, 08 Jun 2012 18:29:06 +0900 (JST) Received: from ff8pbm1.as.netxdc.ne.jp (localhost [127.0.0.1]) by ff8pbm1.as.netxdc.ne.jp (Switch-3.3.4/Switch-3.3.4) with ESMTP id q589T6pX019111 for ; Fri, 08 Jun 2012 18:29:06 +0900 Received: (from root@localhost) by ff8pbm1.as.netxdc.ne.jp (Switch-3.3.4/Switch-3.3.0/Submit) id q589T6d2019106 for user@cassandra.apache.org; Fri, 08 Jun 2012 18:29:06 +0900 Content-type: text/plain; charset=utf-8; format=flowed; delsp=yes To: user@cassandra.apache.org Subject: Re: about multitenant datamodel References: <2D3EB9AA-2CE4-409E-9443-5B9BA21798A0@thelastpickle.com> Date: Fri, 08 Jun 2012 18:20:17 +0900 MIME-version: 1.0 Content-transfer-encoding: Quoted-Printable From: Toru Inoko Organization: =?utf-8?B?5YWI56uv5oqA6KGT6Kqy?= Message-id: In-reply-to: <2D3EB9AA-2CE4-409E-9443-5B9BA21798A0@thelastpickle.com> User-Agent: Opera Mail/11.64 (Win32) X-PlayBackID: q589IwWX0032691339147141454 > See virtual keyspaces in Hector. Yes, at first, I tried to desigen data model like POD architecture = (http://goo.gl/Uw1yD) with this. But, it is problem for me that strong consistency isn't guaranteed among= = metadata schemas. > Every CF has a certain amount of overhead in memory. It's just not how= = > Cassandra is designed to be used. Thanks. I'll try to design meta schma data model again which has strong = = consistency. Thank you for your advices! On Wed, 06 Jun 2012 03:35:40 +0900, aaron morton = wrote: >> With an abstraction layer you can store practically anything in = >> Cassandra. > See virtual keyspaces in Hector. > >> why do you think so? I'll let users create ristricted CFs, and limit = a = >> number of CFs which users create. >> is it still a bad one? > Depends what your limits are, but in general still yes. > > If someone creates a CF with 10 secondary indexes they will use more = > resources than someone who creates a CF with none. Same thing would = > happen in a multitenant RDBMS server. > > If you have 200 CF's in a cluster it will use more memory than one wit= h = > 20 CF's. The extra memory use will result in more disk IO. > > Cheers > > > ----------------- > Aaron Morton > Freelance Developer > @aaronmorton > http://www.thelastpickle.com > > On 5/06/2012, at 7:52 PM, R. Verlangen wrote: > >> Every CF has a certain amount of overhead in memory. It's just not ho= w = >> Cassandra is designed to be used. Maybe you could think of a way to = >> smash data down to indices and entities. With an abstraction layer yo= u = >> can store practically anything in Cassandra. >> >> 2012/6/5 Toru Inoko >> IMHO a model that allows external users to create CF's is a bad one. >> >> why do you think so? I'll let users create ristricted CFs, and limit = a = >> number of CFs which users create. >> is it still a bad one? >> >> >> On Thu, 31 May 2012 06:44:05 +0900, aaron morton = >> wrote: >> >> - Do a lot of keyspaces cause some problems? (If I have 1,000 users, = = >> cassandra creates 1,000 keyspaces=E2=80=A6) >> It's not keyspaces, but the number of column families. >> >> Without storing any data each CF uses about 1MB of ram. When they sta= rt = >> storing and reading data they use more. >> >> IMHO a model that allows external users to create CF's is a bad one. >> >> Hope that helps. >> ----------------- >> Aaron Morton >> Freelance Developer >> @aaronmorton >> http://www.thelastpickle.com >> >> On 25/05/2012, at 12:52 PM, Toru Inoko wrote: >> >> Hi, all. >> >> I'm designing data api service(like cassandra.io but not using = >> dedicated server for each user) on cassandra 1.1 on which users can d= o = >> DML/DDL method like cql. >> Followings are api which users can use( almost same to cassandra api)= . >> - create/read/delete ColumnFamilies/Rows/Columns >> >> Now I'm thinking about multitenant datamodel on that. >> My data model like the following. >> I'm going to prepare a keyspace for each user as a user's tenant spac= e. >> >> | keyspace1 | --- | column family | >> |(for user1)| | >> ... >> >> | keyspace2 | --- | column family | >> |(for user2)| | >> ... >> >> Followings are my question! >> - Is this data model a good for multitenant? >> - Do a lot of keyspaces cause some problems? (If I have 1,000 users, = = >> cassandra creates 1,000 keyspaces...) >> >> please, help. >> thank you in advance. >> >> Toru Inoko. >> >> >> >> >> >> >> >> >> -- >> With kind regards, >> >> Robin Verlangen >> Software engineer >> >> W http://www.robinverlangen.nl >> E robin@us2.nl >> >> Disclaimer: The information contained in this message and attachments= = >> is intended solely for the attention and use of the named addressee a= nd = >> may be confidential. If you are not the intended recipient, you are = >> reminded that the information remains the property of the sender. You= = >> must not use, disclose, distribute, copy, print or rely on this e-mai= l. = >> If you have received this message in error, please contact the sender= = >> immediately and irrevocably delete this message and any copies. >> > -- = ----------------------------------- SCSK Corp. Toru Inoko tel : 03-6438-3544 mail : inoko@ms.scsk.jp -----------------------------------