[
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.
> 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.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
