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?
>>
> Ok, get it, you want to limit the cf user can create (assume) 2, what
about 10k shared users creating 2 cf each=> 20k CF ~~20GB memory used with
no data in it. Do you think it is good one?
I can think of your data model like , S3 or shared hosting is limit
Keysapce and cf to fixed number.
In Cassandra key and column name is very powerful, you can do anything you
want, design DM anyway you want.
Here is the approach I probably will take.
- Limit the user to key, user cannot create/delete cf,
- All user will share same cf.
- Give unique signature (which MUST NOT clash) to each user like
"*username<==>anyothermarker::[[actual
key name].....n]*" utf8 only
- Each user will always prefix this signature in all cf when inserting
and reading data.
- Like S3 bucket check signature before creating new one for new user.
- Each key for user will be like bucket, all columns can be bucket data.
Eg
1)
profileCF{
*user1<==>123456::*profile{
/* user1 profile*/
} ,
*user2<==>4444444::*profile{
/* user2 profile*/
} ,
}
2)
actvityCF{
*user1<==>123456::*activity{
/* user1 activity columns here*/
} ,
*user2<==>**4444444**::*activity{
/* user2 activity columns here*/
} ,
}
marker cf that will keep all unique signature fro users. So it can be
queried while creating new one.
bucketMarkerCF{
*user2<==>**4444444*:{
username:"
}
*user1<==>2323*:{
username:"
}
}
problem with this approach is user may not have liberty to define their own
data model. Good for fixed pattern data: logger, hits, geodata.
/Samal
>>
>>
>
>> On Thu, 31 May 2012 06:44:05 +0900, aaron morton <aa...@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.
>>>>
>>>>
>>>
>>
>> --
>> ------------------------------**-----
>> SCSK株式会社
>> 技術・品質・情報グループ 技術開発部
>> 先端技術課
>>
>> 猪子 徹(Toru Inoko)
>> tel : 03-6438-3544
>> mail : in...@ms.scsk.jp
>> ------------------------------**-----
>>
>>
>
>
> --
> With kind regards,
>
> Robin Verlangen
> *Software engineer*
> *
> *
> W http://www.robinverlangen.nl
> E ro...@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.
>
>
