[
https://issues.apache.org/jira/browse/IGNITE-27438?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexey Scherbakov updated IGNITE-27438:
---------------------------------------
Description:
Currently each expicit tx operation is executed on a primary replica and adds
an RTT to transaction latency for each operation.
This can be optimized by buffering "blind" (unconditinal) writes in a client's
storage (both thin and embedded) until commit.
Similar optimization works in AI2 and makes it faster in specific scenarios.
This gives several benefits:
1. Only read operation causes network round trips.
2. Subsequent reads and writes can be served locally. For example
{code:java}
int val = table.get(tx, key); // Enlists on primary replica and buffered locally
table.put(tx, key, val + 1);
int val2 = table.get(tx, key);
{code}
will produce only one RT.
3. Single partition transactions can be committed in one phase (determined on
commit), greatly improving latency. Great for colocated use cases.
There are also drawbacks:
1. We need additional memory to store tx data, so this is applicable only to
"small" transactions.
2. Doesn't work with SQL.
3. Adds additional complexity to a client.
was:
Currently each expicit tx operation is executed on a primary replica and adds
an RTT to transaction latency for each operation.
This can be optimized by storing"blind" writes (unconditinal puts) in a tx
coordinator storage until commit.
Similar optimization exists in AI2 (except it stores data in the heap and not
applicable to large transactions).
This gives several benefits:
1. Only read operation causes network round trips.
2. Subsequent reads and writes can be served locally. For example
{code:java}
int val = table.get(tx, key); // Enlists on primary replica and buffered locally
table.put(tx, key, val + 1);
int val2 = table.get(tx, key);
{code}
will produce only one RT.
3. Single partition transactions can be committed in one phase, greatly
improving latency.
There are also drawbacks:
1. We need additional space to store tx data in a coordinator storage.
2. Seems difficult to apply to mixed KV + SQL use case.
Another option is to store temporary data in memory, but this limits the
transactio size due to memory restrictions.
> Delay writes until expicit transaction commit
> ---------------------------------------------
>
> Key: IGNITE-27438
> URL: https://issues.apache.org/jira/browse/IGNITE-27438
> Project: Ignite
> Issue Type: Improvement
> Affects Versions: 3.3
> Reporter: Alexey Scherbakov
> Priority: Major
> Labels: ignite-3
>
> Currently each expicit tx operation is executed on a primary replica and adds
> an RTT to transaction latency for each operation.
> This can be optimized by buffering "blind" (unconditinal) writes in a
> client's storage (both thin and embedded) until commit.
> Similar optimization works in AI2 and makes it faster in specific scenarios.
> This gives several benefits:
> 1. Only read operation causes network round trips.
> 2. Subsequent reads and writes can be served locally. For example
> {code:java}
> int val = table.get(tx, key); // Enlists on primary replica and buffered
> locally
> table.put(tx, key, val + 1);
> int val2 = table.get(tx, key);
> {code}
> will produce only one RT.
> 3. Single partition transactions can be committed in one phase (determined on
> commit), greatly improving latency. Great for colocated use cases.
> There are also drawbacks:
> 1. We need additional memory to store tx data, so this is applicable only to
> "small" transactions.
> 2. Doesn't work with SQL.
> 3. Adds additional complexity to a client.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
