[
https://issues.apache.org/jira/browse/IGNITE-17318?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ivan Bessonov updated IGNITE-17318:
-----------------------------------
Labels: ignite-3 (was: )
> 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
> 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)
