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