[
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: [email protected]
For additional commands, e-mail: [email protected]
