[jira] [Assigned] (IGNITE-17318) Implement RocksDB based sorted index storage

["Aleksandr Polovtcev (Jira)" <ji...@apache.org>]

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

Aleksandr Polovtcev reassigned IGNITE-17318:
--------------------------------------------

    Assignee: Aleksandr Polovtcev

> Implement RocksDB based sorted index storage
> --------------------------------------------
>
>                 Key: IGNITE-17318
>                 URL: https://issues.apache.org/jira/browse/IGNITE-17318
>             Project: Ignite
>          Issue Type: Improvement
>            Reporter: Ivan Bessonov
>            Assignee: Aleksandr Polovtcev
>            Priority: Major
>              Labels: ignite-3
>
> Pretty straightforward. Complicated places are:
>  * Binary tuples comparator: should be as fast as possible. Some optimizations might be moved to other issues.
>  * Thorough testing is required. We have both Java and native comparators planned. They should behave identically. This means a specific way of writing tests, to account for this in advance.
>  * Bounds checking on range scan:
> by default, comparator should include the lower bound and exclude the upper bound. This is how prefix search works. This means that exclusion of the lower bound (if needed) and inclusion of the upper bound (if needed) +must be performed manually+ inside of the scan method.
> The question is, do we use separate column families for indexes? At one hand, this increases the number of files and potentially even increases time of the flush, but on the other, it looks easy (or is it).
> Currently, every index has only a UUID id. Just like for tables, we could create an integer identifier, because why not. This way we could store all indexes in a single column family without too much overhead.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)