You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@ignite.apache.org by "Ivan Bessonov (Jira)" <ji...@apache.org> on 2022/04/13 14:06:00 UTC

[jira] [Updated] (IGNITE-16611) [Versioned Storage] Version chain data structure for RocksDB-based storage

     [ https://issues.apache.org/jira/browse/IGNITE-16611?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ivan Bessonov updated IGNITE-16611:
-----------------------------------
    Labels: iep-74 ignite-3  (was: ignite-3)

> [Versioned Storage]  Version chain data structure for RocksDB-based storage
> ---------------------------------------------------------------------------
>
>                 Key: IGNITE-16611
>                 URL: https://issues.apache.org/jira/browse/IGNITE-16611
>             Project: Ignite
>          Issue Type: Task
>          Components: persistence
>            Reporter: Sergey Chugunov
>            Assignee: Ivan Bessonov
>            Priority: Major
>              Labels: iep-74, ignite-3
>
> To support Concurrency Control and implement effective transactions capability to store multiple values of the same key is needed in existing storage.
> h3. Version chain
> Key component here is a special data structure called version chain: it is a list of all versions of a particular key, with the most recent version at the beginning (HEAD).
> Each entry in the chain contains value, reference to the next entry in the list, begin and end timestamps and id of active transaction that created this version.
> There are at least two approaches to implement this structure on top of RocksDB:
> * Combine original key and version into a new key which is put into a RocksDB tree. In that case to restore version chain we need to iterate over the tree using original key as a prefix.
> * Use original key as-is but make it pointing not to the value directly but to an array containing version and other metainformation (ts, id etc) and keys in some secondary tree.
> h3. New API to manage versions
> The following new API should be implemented to provide access to version chain:
> * Methods to manipulate versions: add new version to the chain, commit uncommited version, abort uncommited version.
> * Method to cleanup old versions from the chain.
> * Method to scan over keys up to provided timestamp.



--
This message was sent by Atlassian Jira
(v8.20.1#820001)