[
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" (unconditional) 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.
We can consider implementing this optimization only for embedded transactions.
In this case temporaty data can be stored in a coordinator's local storage and
work with SQL.
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 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.
We can consider implementing this optimization only for embedded transactions.
In this case temporaty data can be stored in a coordinator's local storage and
work with SQL.
> 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
> Fix For: 3.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" (unconditional) 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.
> We can consider implementing this optimization only for embedded
> transactions. In this case temporaty data can be stored in a coordinator's
> local storage and work with SQL.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
