[
https://issues.apache.org/jira/browse/IGNITE-14699?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maksim Timonin updated IGNITE-14699:
------------------------------------
Description:
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.
was:
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.
2.
> 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
> Time Spent: 10m
> 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)
