[
https://issues.apache.org/jira/browse/IGNITE-11433?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Igor Seliverstov updated IGNITE-11433:
--------------------------------------
Description:
At now all entry versions are placed inside index trees. CacheDataTree is used
to link versions each to other (using their order inside a data page).
Despite the fact that this approach is easy to implement and preferable at the
first point, it brings several disadvantages:
1) We need to iterate over versions at update time under a read (or even write)
lock on an index page which blocks other write (read) operations for a
relatively long period of time.
2) We hold all versions of row in all indexes which makes them use much more
space than needed
3) We cannot implement several important improvements (data streamer
optimizations) because having several versions of one key in an index page
doesn't allow using of Invoke operations.
3) Write amplification suffers not only Data Store layer, but indexes as well,
which makes read/lookup ops into indexes much slower.
Using versions linking at the Data Store only (like it do other vendors) solves
or decreases impact of that issues.
So, the proposed changes:
1) Change data page layout adding two fields into its header: {{link}} (a link
to the next entry in the versions chain) and {{lock}} (a tx, which holds a
write lock on the entry) There are several possible optimizations: 1) leave
lock as is (in index leaf item) 2) use max version as lock version as well
was:
At now all entry versions are placed inside index trees. CacheDataTree is used
to link versions each to other (using their order inside a data page).
Despite the fact that this approach is easy to implement and preferable at the
first point, it brings several disadvantages:
1) We need to iterate over versions at update time under a read (or even write)
lock on an index page which blocks other write (read) operations for a
relatively long period of time.
2) We hold all versions of row in all indexes which makes them use much more
space than needed
3) We cannot implement several important improvements (data streamer
optimizations) because having several versions of one key in an index page
doesn't allow using of Invoke operations.
3) Write amplification suffers not only Data Store layer, but indexes as well,
which makes read/lookup ops into indexes much slower.
> MVCC: Link entry versions at the Data Store layer.
> --------------------------------------------------
>
> Key: IGNITE-11433
> URL: https://issues.apache.org/jira/browse/IGNITE-11433
> Project: Ignite
> Issue Type: Improvement
> Components: mvcc, sql
> Reporter: Igor Seliverstov
> Priority: Major
>
> At now all entry versions are placed inside index trees. CacheDataTree is
> used to link versions each to other (using their order inside a data page).
> Despite the fact that this approach is easy to implement and preferable at
> the first point, it brings several disadvantages:
> 1) We need to iterate over versions at update time under a read (or even
> write) lock on an index page which blocks other write (read) operations for a
> relatively long period of time.
> 2) We hold all versions of row in all indexes which makes them use much more
> space than needed
> 3) We cannot implement several important improvements (data streamer
> optimizations) because having several versions of one key in an index page
> doesn't allow using of Invoke operations.
> 3) Write amplification suffers not only Data Store layer, but indexes as
> well, which makes read/lookup ops into indexes much slower.
> Using versions linking at the Data Store only (like it do other vendors)
> solves or decreases impact of that issues.
> So, the proposed changes:
> 1) Change data page layout adding two fields into its header: {{link}} (a
> link to the next entry in the versions chain) and {{lock}} (a tx, which holds
> a write lock on the entry) There are several possible optimizations: 1) leave
> lock as is (in index leaf item) 2) use max version as lock version as well
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
