[jira] [Updated] (IGNITE-11433) MVCC: Link entry versions at the Data Store layer.

["Igor Seliverstov (JIRA)" <ji...@apache.org>]

     [ 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)