incubator-cassandra-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Toru Inoko <in...@ms.scsk.jp>
Subject Re: about multitenant datamodel
Date Fri, 08 Jun 2012 09:20:17 GMT
> 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 <aaron@thelastpickle.com>  
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 with  
> 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 how  
>> 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 you  
>> can store practically anything in Cassandra.
>>
>> 2012/6/5 Toru Inoko <inoko@ms.scsk.jp>
>> 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  
>> <aaron@thelastpickle.com> wrote:
>>
>> - Do a lot of keyspaces cause some problems? (If I have 1,000 users,  
>> cassandra creates 1,000 keyspaces…)
>> It's not keyspaces, but the number of column families.
>>
>> Without storing any data each CF uses about 1MB of ram. When they start  
>> 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 do  
>> 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 space.
>>
>> | 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 and  
>> 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-mail.  
>> 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
-----------------------------------


Mime
View raw message