[jira] [Updated] (IGNITE-14699) Provide Index Queries API

["Andrey Mashenkov (Jira)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/IGNITE-14699?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Andrey Mashenkov updated IGNITE-14699:
--------------------------------------
    Fix Version/s: 2.12

> Provide Index Queries API
> -------------------------
>
>                 Key: IGNITE-14699
>                 URL: https://issues.apache.org/jira/browse/IGNITE-14699
>             Project: Ignite
>          Issue Type: New Feature
>            Reporter: Maksim Timonin
>            Assignee: Maksim Timonin
>            Priority: Major
>              Labels: IEP-71
>             Fix For: 2.12
>
>          Time Spent: 12h 40m
>  Remaining Estimate: 0h
>
> Phase 1 from:
> [https://cwiki.apache.org/confluence/display/IGNITE/IEP-71%3A+Public+API+for+secondary+index+search]
> Some notes about implementation:
> 1. MergeSort reducer of index queries isn't part of this ticket. So this ticket should provide queries for operations: lt, gt, lte, gte, between. See IGNITE-14703.
> 2. There is no lock on Index in moment of querying. So concurrent operations on index can affect result of query. SQL also doesn't lock index.
> 3. QueryParallelism doesn't affects IndexQuery. IndexQuery reuse infrastructure of CacheQuery, and it doesn't use info about segments. It  should be done in a separate ticket, providing parallelism by segments. Currently we initialize cursor over segments within same thread sequentially. Segments initialization is fast operation, so there is no much overhead.
> 4. By the same reason IndexQuery fetches index lazy. SQL fetches index when query is initialized, after that user iterates over prepared result. IndexQuery doesn't prepare result. In case of multiple segments, it will slow down IndexQuery while parallelism isn't implemented. From other side, it make result more sensitive for concurrent operations on an index.
>  
> After implementing query parallelism, we can will 3rd issue. 4th should be discussed after that, after some performance testing. 
>  
>  



--
This message was sent by Atlassian Jira
(v8.3.4#803005)