[
https://issues.apache.org/jira/browse/IGNITE-17318?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17607249#comment-17607249
]
Semyon Danilov commented on IGNITE-17318:
-----------------------------------------
Looks good to me!
> 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
> Fix For: 3.0.0-alpha6
>
> Time Spent: 3.5h
> Remaining Estimate: 0h
>
> 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)
