[ https://issues.apache.org/jira/browse/CASSANDRA-13508?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16749221#comment-16749221 ]
Ariel Weisberg commented on CASSANDRA-13508: -------------------------------------------- I once again forgot that the key already includes the table. My bad! Making storage of the existing state more efficient is totally reasonable. That means the rest of this is just a tangent, if you are only interested in this ticket you can skip it. bq. Keyspace level lwts would be cool, but I think they've always been more of a pony than a feature anyone was seriously considering implementing. Keyspace wouldn't make contention worse at the CAS level because you would still be CASing different tables so the coordinator can pack together multiple CAS operations for different tables into a single Paxos round. Multi-paxos or preferring a single coordinator means you won't have a problem with dueling proposers. Mostly people don't want CAS anyways. They have some other read/write logic they are trying to accomplish and that can frequently be expressed as a pure function with parameters. Once people are expressing these as pure functions contention isn't an issue because you can pack several of them into a single paxos round and then once the round is accepted commit them all back to back without running another round. This approach gets throughput up to point where the bottleneck is reading and writing to execute the transactions not agreeing on what those transactions are. The level beyond this is to try and execute transactions concurrently and in parallel, pessimistic locking, optimistic tracking of conflicts. Once you are able to run these things you also don't need pure functions and can support general transactions and just agree on commit order. Pure functions are just a quick way to increase expressiveness without having to go whole hog on being a transactional database. It's what a lot of successful systems (e.g. Spanner, DynamoDB) do. Cassandra is the odd one out even in that you are restricted to one tables worth of schema for any kind of strongly consistent operation. I imagine there are other people with similar ideas about how to support stronger consistency and more expressive transactions in a practical way. > Make system.paxos table compaction strategy configurable > -------------------------------------------------------- > > Key: CASSANDRA-13508 > URL: https://issues.apache.org/jira/browse/CASSANDRA-13508 > Project: Cassandra > Issue Type: Improvement > Components: Legacy/Coordination > Reporter: Jay Zhuang > Assignee: Jay Zhuang > Priority: Major > Labels: LWT, core, paxos > Fix For: 4.x > > Attachments: test11.png, test2.png > > > The default compaction strategy for {{system.paxos}} table is LCS for > performance reason: CASSANDRA-7753. But for CAS heavily used cluster, the > system is busy with {{system.paxos}} compaction. > As the data in {{paxos}} table are TTL'ed, TWCS might be a better fit. In our > test, it significantly reduced the number of compaction without impacting the > latency too much: > !test11.png! > The time window for TWCS is set to 2 minutes for the test. > Here is the p99 latency impact: > !test2.png! > the yellow one is LCS, the purple one is TWCS. Average p99 has about 10% > increase. -- This message was sent by Atlassian JIRA (v7.6.3#76005) --------------------------------------------------------------------- To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org