Re: Support Multi-Tenant in Cassandra

I think the resource constraining aspects are one of the most important things we are missing. Actually doing resource constraints in SEDA is hard. In TPC it should be easier, so we put off some discussions we were having about it until we have TPC in place such that tracking resource use of a

Re: Support Multi-Tenant in Cassandra

Heh, nice find, Jeremy. Thanks for digging it up On Friday, September 9, 2016, Jeremy Hanna wrote: > For posterity, our wiki page from many moons ago was > https://wiki.apache.org/cassandra/MultiTenant cassandra/MultiTenant>. It was a

Re: Support Multi-Tenant in Cassandra

For posterity, our wiki page from many moons ago was https://wiki.apache.org/cassandra/MultiTenant . It was a different era of the project but there might be some useful bits in there for anyone interested in MT. > On Sep 9, 2016, at 9:28 PM,

Re: Support Multi-Tenant in Cassandra

The current implementation will probably be yanked when thrift as a whole is removed for 4.0. And I'm ok with that. That being said, there has been an undercurrent of interest over time about multitenancy, and I'm willing to entertain a renewed discussion. It might be instructive to see if any

Re: Support Multi-Tenant in Cassandra

I agree that the request scheduler should probably be deprecated and removed unless someone wants to put in something that's usable from the non thrift request processor. We added it for prioritization and QoS but I don't know of anyone ever using it. Our project we thought of using it for got

Re: Support Multi-Tenant in Cassandra

On 15 July 2016 at 16:38, jason zhao yang wrote: > > May I ask is there any plan of extending functionalities related to > Multi-Tenant? I had needs for this in the past and my questioning always seemed to eventuate to answers along the lines of this should be

Re: Support Multi-Tenant in Cassandra

Hi Romain, Thanks for the reply. > request_scheduler it is a legacy feature which only works for thrift api.. It will be great to have some sort of scheduling per user/role, but scheduling on the request will only provide limit isolation..if JVM crashes due to one tenant's invalid request(eg.

Re: Support Multi-Tenant in Cassandra

We consider splitting by Keypspace or tables before, but Cassandra's table is a costly structure(more cpu, flush, memory..). In our use case, it's expected to have more than 50 tenants on same cluster. > As it was already mentioned in the ticket itself, filtering is a highly > inefficient

Re: Support Multi-Tenant in Cassandra

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 a écrit : Hi, May I ask is there any plan of extending

Support Multi-Tenant in Cassandra

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