For posterity, our wiki page from many moons ago was https://wiki.apache.org/cassandra/MultiTenant <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, Jason Brown <jasedbr...@gmail.com> wrote: > > 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 other systems are currently offering > multitenancy and if there's something to be learned there. If not, we could > at least explore the topic more seriously and then document for posterity > the well-informed pros/cons of why we as a community choose to not do it, > postpone for later, or actually do it. Of course, it would be great for a > motivated individual to lead the effort if we really want to entertain it. > > On Friday, September 9, 2016, Jeremy Hanna <jeremy.hanna1...@gmail.com> > wrote: > >> 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 shelved. >> >> Unless it's just multiple clients with the same general use case, I think >> multi tenant is going to be quite difficult to tune and diagnose problems >> for. I would steer clear and have a cluster per logical app if at all >> possible. >> >>> On Sep 9, 2016, at 6:43 PM, Mick Semb Wever <m...@thelastpickle.com >> <javascript:;>> wrote: >>> >>> On 15 July 2016 at 16:38, jason zhao yang <zhaoyangsingap...@gmail.com >> <javascript:;>> >>> 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 done more at the >>> resource level. There is a variety of ways a bad datamodel or client can >>> bring a cluster down, not just at request time. >>> >>> There was some thoughts IIRC around a resource scheduler somewhere >> post-3.0 >>> but i don't think that ever eventuated (someone more knowledgable please >>> correct me). >>> >>> Otherwise you could look into using tiered storage so that you had at >> least >>> disk isolation per keyspace. Solves some things, but won't help with >>> overhead and memtable impact from number of keyspaces/tables and lack of >>> heap/throughput isolation/scheduling. >>> >>> The approach of doing this at the driver level, prefixing the partition >>> key, is as good as any approach for now. >>> >>> Could be an idea to remove/deprecate the request_scheduler from code and >>> yaml. >>> >>> ~mck >>
