[
https://issues.apache.org/jira/browse/SOLR-6810?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Shalin Shekhar Mangar updated SOLR-6810:
----------------------------------------
Attachment: SOLR-6810-trunk.patch
Latest patch.
The DistributedDebugComponentTest collects the filter_queries for every
GET_FIELD requests. The existing DQA makes GET_FIELD requests only to those
shards which contribute some documents to the results. However, the new DQA
implementation makes a request to each shard regardless of whether it
contributes a document or not. IMO, this is a bug (the extra request to every
shard) but it is a bit tricky to solve for the following reasons:
# A user can make a request with rows=0 in order to get just the facet
responses. In such cases, we must make the
STAGE_EXECUTE_QUERY/PURPOSE_GET_FIELDS requests to each shard. In fact many
tests such as TestJsonFacets and some pivot facet tests do this.
# Secondly, we must record things like numFound and maxScore from the results
of the STAGE_LIMIT_ROWS itself if we are to skip requests to shards in the 2nd
phase.
At this stage, all tests pass and I am working on removing the nocommits (the
biggest of which I detailed above).
> Faster searching limited but high rows across many shards all with many hits
> ----------------------------------------------------------------------------
>
> Key: SOLR-6810
> URL: https://issues.apache.org/jira/browse/SOLR-6810
> Project: Solr
> Issue Type: Improvement
> Components: search
> Reporter: Per Steffensen
> Assignee: Shalin Shekhar Mangar
> Labels: distributed_search, performance
> Attachments: SOLR-6810-trunk.patch, SOLR-6810-trunk.patch,
> SOLR-6810-trunk.patch, branch_5x_rev1642874.patch,
> branch_5x_rev1642874.patch, branch_5x_rev1645549.patch
>
>
> Searching "limited but high rows across many shards all with many hits" is
> slow
> E.g.
> * Query from outside client: q=something&rows=1000
> * Resulting in sub-requests to each shard something a-la this
> ** 1) q=something&rows=1000&fl=id,score
> ** 2) Request the full documents with ids in the global-top-1000 found among
> the top-1000 from each shard
> What does the subject mean
> * "limited but high rows" means 1000 in the example above
> * "many shards" means 200-1000 in our case
> * "all with many hits" means that each of the shards have a significant
> number of hits on the query
> The problem grows on all three factors above
> Doing such a query on our system takes between 5 min to 1 hour - depending on
> a lot of things. It ought to be much faster, so lets make it.
> Profiling show that the problem is that it takes lots of time to access the
> store to get id’s for (up to) 1000 docs (value of rows parameter) per shard.
> Having 1000 shards its up to 1 mio ids that has to be fetched. There is
> really no good reason to ever read information from store for more than the
> overall top-1000 documents, that has to be returned to the client.
> For further detail see mail-thread "Slow searching limited but high rows
> across many shards all with high hits" started 13/11-2014 on
> [email protected]
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
