I would be careful with anything per table for memory sizing. We used to have many caches and things that could be tuned per table, but they have all since changed to being per node, as it was a real PITA to get them right. Having to do per table heap/gc/memtable/cache tuning just sounds like a usability nightmare.
-Jeremiah On Feb 22, 2018, at 6: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). > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org For additional commands, e-mail: dev-h...@cassandra.apache.org
