[SERVER-44422] Allow findAndModify and delete one to target by query instead of extracted shard key Created: 05/Nov/19 Updated: 29/Oct/23 Resolved: 12/Jul/23 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Sharding |
| Affects Version/s: | None |
| Fix Version/s: | 7.1.0-rc0, 5.0.20, 6.0.9, 7.0.2 |
| Type: | Improvement | Priority: | Major - P3 |
| Reporter: | Jack Mulrow | Assignee: | Wenqin Ye |
| Resolution: | Fixed | Votes: | 1 |
| Labels: | ShardingRoughEdges | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||||||||||||||||||||||||||||||
| Assigned Teams: |
Sharding NYC
|
||||||||||||||||||||||||||||||||||||
| Backwards Compatibility: | Fully Compatible | ||||||||||||||||||||||||||||||||||||
| Backport Requested: |
v7.0, v6.0, v5.0
|
||||||||||||||||||||||||||||||||||||
| Sprint: | Sharding NYC 2023-06-26, Sharding NYC 2023-07-10, Sharding NYC 2023-07-24 | ||||||||||||||||||||||||||||||||||||
| Participants: | |||||||||||||||||||||||||||||||||||||
| Case: | (copied to CRM) | ||||||||||||||||||||||||||||||||||||
| Description |
|
findAndModify and delete with justOne=true must be targeted to a single shard which they check by extracting a shard key from their query and targeting the chunk that owns that key. This is done through ShardKeyPattern::extractShardKeyFromQuery() which requires a simple query that will exactly match some value, e.g. {skey: 5} or {skey; {$eq: 5}}. More complex queries that don't produce an exact match, but can still be targeted to a single shard are currently rejected. This could be improved by changing findAndModify and delete to target using ChunkManager::getShardIdsForQuery(), which returns the shards that own ranges that overlap with the shard key index bounds generated by the query (after checking for an exact shard key match first), and throwing if more than one shard is targeted. This is already how an update is targeted by its query . |
| Comments |
| Comment by Githook User [ 20/Sep/23 ] |
|
Author: {'name': 'Wenqin Ye', 'email': 'wenqin908@gmail.com', 'username': 'wenqinYe'}Message: |
| Comment by Githook User [ 20/Sep/23 ] |
|
Author: {'name': 'Wenqin Ye', 'email': 'wenqin908@gmail.com', 'username': 'wenqinYe'}Message: |
| Comment by Githook User [ 18/Sep/23 ] |
|
Author: {'name': 'wenqinYe', 'email': 'wenqin908@gmail.com', 'username': 'wenqinYe'}Message: |
| Comment by Githook User [ 02/Aug/23 ] |
|
Author: {'name': 'wenqinYe', 'email': 'wenqin908@gmail.com', 'username': 'wenqinYe'}Message: |
| Comment by Githook User [ 02/Aug/23 ] |
|
Author: {'name': 'wenqinYe', 'email': 'wenqin908@gmail.com', 'username': 'wenqinYe'}Message: |
| Comment by Githook User [ 12/Jul/23 ] |
|
Author: {'name': 'wenqinYe', 'email': 'wenqin908@gmail.com', 'username': 'wenqinYe'}Message: |
| Comment by Jack Mulrow [ 06/Nov/19 ] |
|
kaloian.manassiev, yes I'd say so. Previously a user would never want to use predicates like that though, since all documents needed to have the full shard key. Now that we've lifted that requirement, this might be a useful feature going forward. |
| Comment by Kaloian Manassiev [ 06/Nov/19 ] |
|
jack.mulrow, based on our discussion yesterday, since findAndModify never supported predicates which did not contain the complete shard key, this is technically not a regression, right? |
| Comment by Jack Mulrow [ 05/Nov/19 ] |
|
This is a little more important after |