[SERVER-4914] avoid scanning a dummy shard for an unsatisfiable query Created: 08/Feb/12  Updated: 06/Dec/22  Resolved: 15/Nov/21

Status: Closed
Project: Core Server
Component/s: Sharding
Affects Version/s: None
Fix Version/s: None

Type: Improvement Priority: Major - P3
Reporter: Aaron Staple Assignee: [DO NOT USE] Backlog - Sharding Team
Resolution: Won't Fix Votes: 0
Labels: lamont-triage
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Related
is related to SERVER-4554 shard selection code asserts for cert... Closed
Assigned Teams:
Sharding
Participants:

 Description   

As part of the SERVER-4554 fix, ChunkManager::getShardsForQuery() returns a dummy shard for an unsatisfiable query (one that cannot match any documents). The reason for this is that some callers of getShardsForQuery() expect that at least one shard will be returned for any query.

I believe the current behavior is functionally correct, but we are querying the dummy shard unnecessarily for these unsatisfiable queries.

The current implementations of count and find have explicit assertions that the returned list of shards is not empty. It would make sense to ensure/check that all callers for getShardsForQuery() can handle an empty set of shards. Some of the tricky cases I can see are:

  • making sure the parallel cursor works correctly with zero shards (and zero connections)
  • making sure there are no issues relating to shard version information -> Greg suggested that he should look at this.

I will add some additional comments indicating which pieces of code will need to be touched to change the behavior of getShardsForQuery().



 Comments   
Comment by Aaron Staple [ 08/Feb/12 ]

It's just a logical check, in the sharding case independent of the data. There are two types of checks applied:

  • queries that can't match anything eg {x:{$in:[]}}
  • queries that can't match anything given a shard key (or non multi key index) eg {a:{$gt:5,$lt:5}} if shard key is {a:1}

    . If there is no such shard key or single key index, there might be a document like

    {a:[4,6]}

    which would match.

See above commit for relevant pointers in the code.

Comment by auto [ 08/Feb/12 ]

Author:

{u'login': u'astaple', u'name': u'Aaron', u'email': u'aaron@10gen.com'}

Message: SERVER-4914 identify relevant code points
Branch: master
https://github.com/mongodb/mongo/commit/831bbe7dbf18ecab0a3b805393fc7ff0a634668b

Comment by Greg Studer [ 08/Feb/12 ]

Is the "can be satisfied" test related at all to the actual distribution of documents, sharded or not, or is it just a logical check?

Generated at Thu Feb 08 03:07:20 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.