[
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
memory (both thin and embedded) until commit.
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), improving latency. This shines for colocated use cases.
Similar optimization works in AI2 and makes it faster in specific scenarios.
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" (unconditional) writes in a client's
memory (both thin and embedded) until commit.
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), improving latency. This is great for colocated use cases.
Similar optimization works in AI2 and makes it faster in specific scenarios.
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 memory (both thin and embedded) until commit.
> 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), improving latency. This shines for colocated use cases.
> Similar optimization works in AI2 and makes it faster in specific scenarios.
> 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)
