Something folks haven't raised, but would be another impediment here is that in Cassandra if you submit a batch (logged or unlogged) for two tables in the same keyspace with the same partition then Cassandra collapses them into the same Mutation and the two INSERTs are processed atomically. There are a few (maybe more than a few) things that take advantage of this fact.
If you move each table to its own JVM then you cannot really achieve this atomicity. So, at most you would want to consider a JVM per keyspace (or consider touching a lot of code or changing a pretty fundamental/deep contract in Cassandra). ---->Brian Sent from my iPhone > On Feb 22, 2018, at 7:10 PM, J. D. Jordan <jeremiah.jor...@gmail.com> wrote: > > 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 > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org For additional commands, e-mail: dev-h...@cassandra.apache.org
