There's an incredible amount of work that would need to be done in order to make any of this happen. Basically a full rewrite of the entire codebase. Years of effort.
The codebase would have to move to a shared-nothing actor & message based communication mechanism before any of this is possible. Fun in theory, but considering removing singletons has been a multi-year, many failure effort, I suspect we might need 10 years to refactor Cassandra to use multiple JVMs. By then maybe we'll have a pauseless / low pause collector and it won't matter. On Thu, Feb 22, 2018 at 3:59 PM kurt greaves <k...@instaclustr.com> wrote: > > > > ... compaction on its own jvm was also something I was thinking about, > but > > then I realized even more JVM sharding could be done at the table level. > > > Compaction in it's own JVM makes sense. At the table level I'm not so sure > about. Gotta be some serious overheads from running that many JVM's. > Keyspace might be reasonable purely to isolate bad tables, but for the most > part I'd think isolating every table isn't that beneficial and pretty > complicated. In most cases people just fix their modelling so that they > don't generate large amounts of GC, and hopefully test enough so they know > how it will behave in production. > > If we did at the table level we would inevitable have to make each > individual table incredibly tune-able which would be a bit tedious IMO. > There's no way for us to smartly decide how much heap/memtable space/etc > each table should use (not without some decent AI, anyway). > >
