Heh, nice find, Jeremy. Thanks for digging it up On Friday, September 9, 2016, Jeremy Hanna <jeremy.hanna1...@gmail.com> wrote:
> 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 > <javascript:;>> 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 > <javascript:;>> > > 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:;> > >> <javascript:;>> wrote: > >>> > >>> On 15 July 2016 at 16:38, jason zhao yang <zhaoyangsingap...@gmail.com > <javascript:;> > >> <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 > >> > >
