[
https://issues.apache.org/jira/browse/IGNITE-7027?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Ozerov updated IGNITE-7027:
------------------------------------
Description:
Currently we have per-partition primary index. This gives us easy and effective
rebalance/recovery capabilities and efficient lookup in key-value mode.
However, this doesn't work well for SQL case. We cannot use this index for
range scans. Neither we can use it for PK lookups (it is possible to implement,
but will be less then optimal due to necessity to build the whole key object).
The following change is suggested as optional storage mode:
1) Single index data structure for all partitions
2) Only single key type is allowed (i.e. no mess in the cache and no cache
groups)
3) Additional SQL PK index will not be needed in this case
Advantage:
- No overhead on the second PK index
Disadvantage:
- Less efficient rebalance and recovery
was:
Currently we have per-partition primary index. This gives us easy and effective
rebalance/recovery capabilities and efficient lookup in key-value mode.
However, this doesn't work well for SQL case. We cannot use this index for
range scans. Neither we can use it for PK lookups (it is possible to implement,
but will be less then optimal due to necessity to build the whole key object).
The following change is suggested as optional storage mode:
1) Single index data structure for all partitions
2) Only single key type is allowed (i.e. no mess in the cache and no cache
groups)
3) Additional SQL PK index will not be needed in this case
> Single primary index instead of mulitple per-partition indexes
> --------------------------------------------------------------
>
> Key: IGNITE-7027
> URL: https://issues.apache.org/jira/browse/IGNITE-7027
> Project: Ignite
> Issue Type: Task
> Components: cache, sql
> Reporter: Vladimir Ozerov
> Labels: iep-10
>
> Currently we have per-partition primary index. This gives us easy and
> effective rebalance/recovery capabilities and efficient lookup in key-value
> mode.
> However, this doesn't work well for SQL case. We cannot use this index for
> range scans. Neither we can use it for PK lookups (it is possible to
> implement, but will be less then optimal due to necessity to build the whole
> key object).
> The following change is suggested as optional storage mode:
> 1) Single index data structure for all partitions
> 2) Only single key type is allowed (i.e. no mess in the cache and no cache
> groups)
> 3) Additional SQL PK index will not be needed in this case
> Advantage:
> - No overhead on the second PK index
> Disadvantage:
> - Less efficient rebalance and recovery
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
