Upsert performance with sharding on MongoDB

user_2836603 0
Viewed 358

I am analyzing some performance issues that we have with our MongoDB cluster, and it led me to a question I'm not able to find an answer for at the moment.

Let's consider the collection MyCollection that is sharded on the index {myField:1} and contains the two indexes {_id:1} and {myField:1}

If I execute the following request:

db.MyCollection.update({_id: X}, {$set: {otherField: Y}, $setOnInsert: {myField: Z}}, {upsert:true});

Will it lead to performance issues as the query is made of only the id that is not part of the sharding key?

Would it be significantly better with the following query:

db.MyCollection.update({_id: X, myField: Z}, {$set: {otherField: Y}}, {upsert:true});

Or would it be the same?

My reasoning is that for the first query, as it doesn't have the sharding key in the query, it will ask all shards to find _id:X whereas with the second, it'll go directly to the appropriate shard.

However, I still have some doubts about the second one. Because even if a sharding key is immutable, won't it check on all other shards too to ensure that the id I provided is not present with a different sharding key?

Note: we're on version 4.0

mongodb sharding
1 Answers

If the query does not include the shard key, the mongos must send the query to all shards as a scatter/gather operation. Otherwise mongos will know what shard(s) to look.

UPDATE:

To determine if the query is a Targeted Operations or Broadcast Operations, use the .explain() method, look for the numbers of shards involved in the operation. "queryPlanner" > "winningPlan" > "shards"

user_49801410
Related