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 >
