You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@cassandra.apache.org by "David Capwell (Jira)" <ji...@apache.org> on 2023/05/10 16:51:00 UTC

[jira] [Created] (CASSANDRA-18519) CEP-15: (C*) Add notion of CommandsForRanges and make this durable in C*

David Capwell created CASSANDRA-18519:
-----------------------------------------

             Summary: CEP-15: (C*) Add notion of CommandsForRanges and make this durable in C*
                 Key: CASSANDRA-18519
                 URL: https://issues.apache.org/jira/browse/CASSANDRA-18519
             Project: Cassandra
          Issue Type: Task
          Components: Accord
            Reporter: David Capwell
            Assignee: David Capwell


To add support for range transactions in C* we need to make sure

1) their state is durable and can be recovered on restart
2) have some way to find all CommandsForKey that are contained in the range transaction range
3) have some way to find all CommandsForRange that intersect this range

To do this, I propose the following

1) Create a new commands_for_range table that stores: (store, range) -> list<accord_timestamp_tuple> — this is byId, not sure if repair needs byExecuteId as well
2) For C*, store a in-memory mapping of Range -> List<TxnId>, and on-boot repopulate this cache.  This then can be used to construct the CommandsForRange needed by the transaction. This makes an assumption that many ranges will not exist, at least for the time being.
3) Change commands_for_keys to use LocalPartitioner, and order the table by (store, key)
4) When C* sees a range transaction, find all keys that are contained by the range by running the logical query "SELECT key FROM commands_for_keys WHERE key BETWEEN range.start AND range.end". Implementation has to make sure to handle many keys (may need to partition the range to increase parallel access, and may need to page through the table to see all keys (aka multiple ReadCommands)).  Once all keys are found, then must load into the CommandsForKeys cache

For #4, https://github.com/apache/cassandra-accord/pull/27 maybe able to optimize the logic to lazy load only what is actually needed rather than load the whole world



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscribe@cassandra.apache.org
For additional commands, e-mail: commits-help@cassandra.apache.org