incubator-cassandra-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nate McCall <n...@datastax.com>
Subject Re: cluster size, several cluster on one node for multi-tenancy
Date Thu, 17 Feb 2011 20:30:51 GMT
Hector's virtual keyspaces would work well for what you describe. Ed
Anuff, who added this feature to Hector, showed me a working
multi-tennancy based app the other day and it worked quite well.

On Thu, Feb 17, 2011 at 1:44 PM, Norman Maurer <norman@apache.org> wrote:
> Maybe you could make use of "Virtual Keyspaces".
>
> See this wiki for the idea:
> https://github.com/rantav/hector/wiki/Virtual-Keyspaces
>
> Bye,
> Norman
>
> 2011/2/17 Frank LoVecchio <frank@isidorey.com>:
>> Why not just create some sort of ACL on the client side and use one
>> Keyspace?  It's a lot less management.
>>
>> On Thu, Feb 17, 2011 at 12:34 PM, Mimi Aluminium <mimi.aluminium@gmail.com>
>> wrote:
>>>
>>> Hi,
>>> I really need your help in this matter.
>>> I will try to simplify my problem and ask specific questions
>>>
>>> I am thinking of solving the multi-tenancy problem by providing a separate
>>> cluster per each tenant. Does it sound reasonable?
>>> I can end-up with one node belongs to several clusters.
>>> Does Cassandra support several clusters per node? Does it mean several
>>> Cassandra daemons on each node? Do you recommend doing that ? what is the
>>> overhead? is there any link that explain how to do that?
>>>
>>> Thanks a lot,
>>> Mimi
>>>
>>>
>>> On Wed, Feb 16, 2011 at 6:43 PM, Mimi Aluminium <mimi.aluminium@gmail.com>
>>> wrote:
>>>>
>>>> Hi,
>>>> We are interested in a multi-tenancy environment, that may consist of up
>>>> to hundreds of data centers. The current design requires cross rack and
>>>> cross DC replication. Specifically, the per-tenant CFs will be replicated 6
>>>> times: in three racks,  with 2 copies inside a rack, the racks will be
>>>> located in at least two different DCs. In the future other replication
>>>> policies will be considered. The application will decide where (which racks
>>>> and DC)  to place each tenant's replicas.  and it might be that one rack
can
>>>> hold more than one tenant.
>>>>
>>>> Separating each tenant in a different keyspace, as was suggested
>>>> in  previous mail thread in this subject, seems to be a good approach
>>>> (assuming the memtable problem will be solved somehow).
>>>> But then we had concern with regard to the cluster size.
>>>> and here are my questions:
>>>> 1) Given the above, should I define one Cassandra cluster that hold all
>>>> the DCs? sounds not reasonable  given hundreds DCs tens of servers in each
>>>> DC etc. Where is the bottleneck here? keep-alive messages, the gossip,
>>>> request routing? what is the largest number of servers a cluster can bear?
>>>> 2) Now assuming that I can create the per-tenant  keyspace only for
 the
>>>> servers that in the three racks where the replicas are held,  does such
>>>> definition reduces the messaging transfer among the other servers. Does
>>>> Cassandra optimizes the message transfer in such case?
>>>> 3) Additional possible solution was to create a separate clusters per
>>>> each tenant. But it can cause a situation where one server has to run two or
>>>> more Cassandra's clusters. Can we run more than one cluster in parallel,
>>>> does it means two cassandra daemons / instances on one server? what will
be
>>>> the overhead? do you have a link that explains how to deal with it?
>>>>
>>>> Please can you help me to decide which of these solution can work or you
>>>> are welcome to suggest something else.
>>>> Thanks a lot,
>>>> Mimi
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>
>>
>>
>> --
>> Frank LoVecchio
>> Senior Software Engineer | Isidorey, LLC
>> Google Voice +1.720.295.9179
>> isidorey.com | facebook.com/franklovecchio | franklovecchio.com
>>
>

Mime
View raw message