Ivan Bessonov created IGNITE-17318:
--------------------------------------
Summary: 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
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)
