[jira] [Updated] (IGNITE-27438) Delay writes until expicit transaction commit
[
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 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.
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), greatly improving latency. 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 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.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-27438) Delay writes until expicit transaction commit
[
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)
[jira] [Updated] (IGNITE-27438) Delay writes until expicit transaction commit
[
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), greatly improving latency. 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.
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
storage (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), greatly improving latency. 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), greatly improving latency. 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.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-27438) Delay writes until expicit transaction commit
[
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.
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.
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
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.
> 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.
> 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)
[jira] [Updated] (IGNITE-27438) Delay writes until expicit transaction commit
[
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)
[jira] [Updated] (IGNITE-27438) Delay writes until expicit transaction commit
[
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.
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.
> 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" (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.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-27438) Delay writes until expicit transaction commit
[
https://issues.apache.org/jira/browse/IGNITE-27438?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexey Scherbakov updated IGNITE-27438:
---
Fix Version/s: 3.3
> 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" (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)
[jira] [Updated] (IGNITE-27438) Delay writes until expicit transaction commit
[
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)
[jira] [Updated] (IGNITE-27438) Delay writes until expicit transaction commit
[
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 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.
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" writes (unconditinal puts) on a tx
coordinator until commit.
Similar optimization exists in AI2.
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 additionaly memory to buffer tuples: the optimization is applicable
to only small transactions.
2. Not applicable to 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
>
> 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.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-27438) Delay writes until expicit transaction commit
[
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" writes (unconditinal puts) on a tx
coordinator until commit.
Similar optimization exists in AI2.
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 additionaly memory to buffer tuples: the optimization is applicable
to only small transactions.
2. Not applicable to 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" writes (unconditinal puts) on a tx
coordinator until commit.
Similar optimization exists in AI2.
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 additionaly memory to buffer tuples: the optimization is applicable
to only small transactions.
2. Mixed KV + SQL case stops working: only KV transactions are applicable.
> 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" writes (unconditinal puts) on a tx
> coordinator until commit.
> Similar optimization exists in AI2.
> 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 additionaly memory to buffer tuples: the optimization is
> applicable to only small transactions.
> 2. Not applicable to SQL.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-27438) Delay writes until expicit transaction commit
[
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" writes (unconditinal puts) on a tx
coordinator until commit.
Similar optimization exists in AI2.
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 additionaly memory to buffer tuples: the optimization is applicable
to only small transactions.
2. Mixed KV + SQL case stops working: only KV transactions are applicable.
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" writes (unconditinal puts) on a tx
coordinator until commit.
Similar optimization exists in AI3.
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 additionaly memory to buffer tuples: the optimization is applicable
to only small transactions.
2. Mixed KV + SQL case stops working: only KV transactions are applicable.
> 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" writes (unconditinal puts) on a tx
> coordinator until commit.
> Similar optimization exists in AI2.
> 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 additionaly memory to buffer tuples: the optimization is
> applicable to only small transactions.
> 2. Mixed KV + SQL case stops working: only KV transactions are applicable.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-27438) Delay writes until expicit transaction commit
[
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" writes (unconditinal puts) on a tx
coordinator until commit.
Similar optimization exists in AI3.
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
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 additionaly memory to buffer tuples: the optimization is applicable
to only small transactions.
2. Mixed KV + SQL case stops working: only KV transactions are applicable.
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" writes (unconditinal puts) on a tx
coordinator until commit.
Similar optimization exists in AI3.
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);
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 additionaly memory to buffer tuples: the optimization is applicable
to only small transactions.
2. Mixed KV + SQL case stops working: only KV transactions are applicable.
> 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" writes (unconditinal puts) on a tx
> coordinator until commit.
> Similar optimization exists in AI3.
> 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
> 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 additionaly memory to buffer tuples: the optimization is
> applicable to only small transactions.
> 2. Mixed KV + SQL case stops working: only KV transactions are applicable.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-27438) Delay writes until expicit transaction commit
[
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" writes (unconditinal puts) on a tx
coordinator until commit.
Similar optimization exists in AI3.
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 additionaly memory to buffer tuples: the optimization is applicable
to only small transactions.
2. Mixed KV + SQL case stops working: only KV transactions are applicable.
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" writes (unconditinal puts) on a tx
coordinator until commit.
Similar optimization exists in AI3.
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
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 additionaly memory to buffer tuples: the optimization is applicable
to only small transactions.
2. Mixed KV + SQL case stops working: only KV transactions are applicable.
> 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" writes (unconditinal puts) on a tx
> coordinator until commit.
> Similar optimization exists in AI3.
> 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 additionaly memory to buffer tuples: the optimization is
> applicable to only small transactions.
> 2. Mixed KV + SQL case stops working: only KV transactions are applicable.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-27438) Delay writes until expicit transaction commit
[
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" writes (unconditinal puts) on a tx
coordinator until commit.
Similar optimization exists in AI3.
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);
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 additionaly memory to buffer tuples: the optimization is applicable
to only small transactions.
2. Mixed KV + SQL case stops working: only KV transactions are applicable.
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" writes (unconditinal puts) on a tx
coordinator until commit.
Similar optimization exists in AI3.
This gives several benefits:
1. Only read operation causes network round trips.
2. Subsequent reads can be served locally. For example
{code:java}
int val = table.get(tx, key);
table.put(tx, key, val + 1);
{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 additionaly memory to buffer tuples: the optimization is applicable
to only small transactions.
2. Mixed KV + SQL case stops working: only KV transactions are applicable.
> 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" writes (unconditinal puts) on a tx
> coordinator until commit.
> Similar optimization exists in AI3.
> 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);
> 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 additionaly memory to buffer tuples: the optimization is
> applicable to only small transactions.
> 2. Mixed KV + SQL case stops working: only KV transactions are applicable.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-27438) Delay writes until expicit transaction commit
[
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" writes (unconditinal puts) on a tx
coordinator until commit.
Similar optimization exists in AI3.
This gives several benefits:
1. Only read operation causes network round trips.
2. Subsequent reads can be served locally. For example
{code:java}
int val = table.get(tx, key);
table.put(tx, key, val + 1);
{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 additionaly memory to buffer tuples: the optimization is applicable
to only small transactions.
2. Mixed KV + SQL case stops working: only KV transactions are applicable.
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" writes (unconditinal puts) on a tx
coordinator until commit.
Similar optimization exists in AI3.
This gives several benefits:
1. Only read operation causes network round trips.
2. Subsequent reads can be served locally. For example
{code:java}
int val = table.get(tx, key);
table.put(tx, key, val + 1);
{code}
will produce only one RT.
3. Single partition transactions can be committed in one phase, greatly
reducing latency.
There are also drawbacks:
1. We need additionaly memory to buffer tuples: the optimization is applicable
to only small transactions.
2. Mixed KV + SQL case stops working: only KV transactions are applicable.
> 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" writes (unconditinal puts) on a tx
> coordinator until commit.
> Similar optimization exists in AI3.
> This gives several benefits:
> 1. Only read operation causes network round trips.
> 2. Subsequent reads can be served locally. For example
> {code:java}
> int val = table.get(tx, key);
> table.put(tx, key, val + 1);
> {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 additionaly memory to buffer tuples: the optimization is
> applicable to only small transactions.
> 2. Mixed KV + SQL case stops working: only KV transactions are applicable.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-27438) Delay writes until expicit transaction commit
[
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" writes (unconditinal puts) on a tx
coordinator until commit.
Similar optimization exists in AI3.
This gives several benefits:
1. Only read operation causes network round trips.
2. Subsequent reads can be served locally. For example
{code:java}
int val = table.get(tx, key);
table.put(tx, key, val + 1);
{code}
will produce only one RT.
3. Single partition transactions can be committed in one phase, greatly
reducing latency.
There are also drawbacks:
1. We need additionaly memory to buffer tuples: the optimization is applicable
to only small transactions.
2. Mixed KV + SQL case stops working: only KV transactions are applicable.
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" writes (unconditinal puts) on a tx
coordinator until commit.
Similar optimization exists in AI3.
This gives several benefits:
1. Only read operation causes network round trips.
2. Subsequent reads can be served locally. For example
{code:java}
int val = table.get(tx, key);
table.put(tx, key, val + 1);
{code}
will produce only one RT.
3. Single partition transactions can be committed in one phase, greatly
reducing latency.
There are also drawbacks:
1. We need additionaly memory to buffer tuples. The optimization is applicable
to only small transactions.
2. Mixed KV + SQL case stops working. Only KV transactions are affected.
> 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" writes (unconditinal puts) on a tx
> coordinator until commit.
> Similar optimization exists in AI3.
> This gives several benefits:
> 1. Only read operation causes network round trips.
> 2. Subsequent reads can be served locally. For example
> {code:java}
> int val = table.get(tx, key);
> table.put(tx, key, val + 1);
> {code}
> will produce only one RT.
> 3. Single partition transactions can be committed in one phase, greatly
> reducing latency.
> There are also drawbacks:
> 1. We need additionaly memory to buffer tuples: the optimization is
> applicable to only small transactions.
> 2. Mixed KV + SQL case stops working: only KV transactions are applicable.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-27438) Delay writes until expicit transaction commit
[
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" writes (unconditinal puts) on a tx
coordinator until commit.
Similar optimization exists in AI3.
This gives several benefits:
1. Only read operation causes network round trips.
2. Subsequent reads can be served locally. For example
{code:java}
int val = table.get(tx, key);
table.put(tx, key, val + 1);
{code}
will produce only one RT.
3. Single partition transactions can be committed in one phase, greatly
reducing latency.
There are also drawbacks:
1. We need additionaly memory to buffer tuples. The optimization is applicable
to only small transactions.
2. Mixed KV + SQL case stops working. Only KV transactions are affected.
was:
Currently each expicit tx operations is executed on a primary replica.
This causes additional RTTs and add latency to a transaction.
This can be optimized by buffering "blind" writes (unconditinal puts) on a tx
coordinator until commit.
Similar optimization exists in AI3.
This gives several benefits:
1. Only read operations cause network round trips.
2. Subsequent reads can be served locally. For example
{code:java}
int val = table.get(tx, key);
table.put(tx, key, val + 1);
{code}
will produce only one RT.
3. Single partition transactions can be committed in one phase, greatly
reducing latency.
There are also drawbacks:
1. We need additionaly memory to buffer tuples. So, the optimization is
applicable to only small transactions.
2. Mixed KV + SQL case stops working.
> 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" writes (unconditinal puts) on a tx
> coordinator until commit.
> Similar optimization exists in AI3.
> This gives several benefits:
> 1. Only read operation causes network round trips.
> 2. Subsequent reads can be served locally. For example
> {code:java}
> int val = table.get(tx, key);
> table.put(tx, key, val + 1);
> {code}
> will produce only one RT.
> 3. Single partition transactions can be committed in one phase, greatly
> reducing latency.
> There are also drawbacks:
> 1. We need additionaly memory to buffer tuples. The optimization is
> applicable to only small transactions.
> 2. Mixed KV + SQL case stops working. Only KV transactions are affected.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
