I agree with Jon. The actor based model would be the logical approach to get to be more “efficient.” Until then fault tolerance has to be built into the driver to contact another node if in the middle and then reconcile the commitlog later.
I’ve seen many people combine an external queue to deal with the GC issues by adding yet another layer of asynchronicity. (If it’s not a word it is now) Even in systems like SQL servers there are internal queues that get locked up due to memory, storage, or cpu pressures. It’s not a GC pause but it may as well be. Even with all the tweaking the only way to get beyond is distributed asynchronous systems that are self healing. -- Rahul Singh rahul.si...@anant.us Anant Corporation On Feb 23, 2018, 4:34 AM -0500, Brian Hess <brianmh...@gmail.com>, wrote: > 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 >
