[prev in list] [next in list] [prev in thread] [next in thread] 

List:       cassandra-dev
Subject:    Re: Support Multi-Tenant in Cassandra
From:       Oleksandr Petrov <oleksandr.petrov () gmail ! com>
Date:       2016-07-15 8:27:57
Message-ID: CAA1qPbYji25gOJJ=AZQwWNMW5ZWS9z6HBys-b2dNUzfnbgd7HQ () mail ! gmail ! com
[Download RAW message or body]


There's a ticket on filtering (#11031), although I would not count on
filtering in production.

As it was already mentioned in the ticket itself, filtering is a highly
inefficient operation. it was thought as aid for people who're exploring
data and/or can structure query in such a way that it will at least be
local (for example, with IN or EQ query on the partition key and filtering
out results from the small partition). However, filtering on the Partition
Key assumes that _every_ replica has to be queried for the results, as we
do not know which partitions are going to be holding the data. Having every
query in your system to rely on filtering, big amount of data and high load
will eventually have substantial negative impact on performance.

I'm not sure what's the amount of tenants you're working with, although
I've seen setups where tenancy was solved by using multiple keyspaces,
which helps to completely isolate the data, avoid filtering. Given that
you've tried splitting sstables on tenant_id, that might be solved by using
multiple keyspaces. This will also help with server resource isolation and
most of the issues you've raised.


On Fri, Jul 15, 2016 at 10:10 AM Romain Hardouin
<romainh_ml@yahoo.fr.invalid> wrote:

> I don't use C* in such a context but out of curiosity did you set
> the request_scheduler to RoundRobin or did you implement your own scheduler?
> Romain
>     Le Vendredi 15 juillet 2016 8h39, jason zhao yang <
> zhaoyangsingapore@gmail.com> a écrit :
>
>
>  Hi,
>
> May I ask is there any plan of extending functionalities related to
> Multi-Tenant?
>
> Our current approach is to define an extra PartitionKey called "tenant_id".
> In my use cases, all tenants will have the same table schemas.
>
> * For security isolation: we customized GRANT statement to be able to
> restrict user query based on the "tenant_id" partition.
>
> * For getting all data of single tenant, we customized SELECT statement to
> support allow filtering on "tenant_id" partition key.
>
> * For server resource isolation, I have no idea how to.
>
> * For per-tenant backup restore, I was trying a
> tenant_base_compaction_strategy to split sstables based on tenant_id. it
> turned out to be very inefficient.
>
> What's community's opinion about submitting those patches to Cassandra? It
> will be great if you guys can share the ideal Multi-Tenant architecture for
> Cassandra?
>
> jasonstack
>
>
>

-- 
Alex Petrov


[prev in list] [next in list] [prev in thread] [next in thread]